架构师训练营第九周作业
请简述 JVM 垃圾回收原理。
主要是通过可达性分析算法对垃圾对象的识别。标识完成后,会经历 清理->压缩->复制三个步骤,将垃圾清理,将整出一段连续可用的内存空间。
下图为几种不同的垃圾回收算法的执行逻辑。现在常用的是G1回收器,利用多线程、分区域的分配内存空间和垃圾回收,减少因为垃圾回收造成的虚拟机阻塞影响。
设计一个秒杀系统,主要的挑战和问题有哪些?核心的架构方案或者思路有哪些?
挑战和问题
1、对现有业务系统造成冲击,甚至瘫痪。
秒杀这样一个营销活动,具有营销时间短,瞬时高并发。如果将秒杀业务与网站其他业务部署在一起,由于瞬时巨大的流量冲击,必然会对现有的业务系统造成重大影响。
2、高并发下的应用、数据库负载
在秒杀开始前,用户或者羊毛党,会不断的刷新浏览器,或者用工具不断的刷新秒杀页面。按照每一个请求都到达应用服务器->数据库 这样一个过程。必然会对应用服务器、数据库造成巨大的负载压力。
3、突然增加的网络及服务器带宽
假如,商品页面10张图片,每张图片200K,1000个并发;所需要的网络和服务器带宽将达到2G(200K*10000)。
4、直接下单的安全问题
1)在活动未开始前,通过预先知道了秒杀的URL,提前下单成交。
2)羊毛党通过工具,在秒杀开始时由于是机器操作比普通用户操作快,导致商品不能到达,真正的消费者手中,失去了活动的意义。
5、超卖的问题
由于数量有限,这么多用户并发去抢,很有可能会出现超卖的问题。
核心的架构方案或者思路有哪些
一、静态化
利用前端技术,在活动开始前将活动商品列表,活动商品数据、商品列表页模板JS、活动商品页模板JS等信息,通过发布系统生成静态json、js文件,发布到CDN服务器中。用户打开商品列表页或者商品详情页,直接利用用户浏览器端渲染相关界面。
二、并发控制、防秒杀器
设计多重阀门,只放最前面的一部份人进入到秒杀系统。
1、一重:如果有(用户分析系统),可以提前将羊毛党注册的僵死用户筛选出来,直接挡在门外。同时也需要限制单个IP请求N秒内请求【获取秒杀界面的地址静态文件】次数(防止机器人不断的通过程序提前获取进入秒杀界面的概率)。
2、二重:限制进入秒杀页面的人数(1000人)
1)用户要进入秒杀界面(只在秒杀开始前2秒开放,由服务器端生成秒杀界面的地址【地址是随机产生的只有在秒杀开始前生成】,秒杀开始后将秒杀地址更新为秒杀结束界面,阻挡后面人进入);
2)用户进入秒杀界面必须是先通过列表界面进入(防止机器人通过获取秒杀界面地址直接进入)。
3、三重:限制进入下单页面的人数(100人)
1)下单界面,商品ID随机,并且下单界面地址也是随机生成,只能下单界面中可以获得,并且不能跳过秒杀界面进入下单界面。
2)只放小部分人(商品库存数+10)进入下单界面。
4、四重:限制进入支付系统的人数(56人)
1)提交订单采用MQ,顺序消息机制(防止出现超卖)。用户在下单界面提交秒杀订单时。直接将消息放入MQ,直接返回一个token给用户,并在前端界面显示(订单提交中。。。),前端每1秒轮询。
2)当轮询返回 订单创建成功状态后,引导用户进入支付界面。否则提示秒杀结束(也可以推入排队捡漏环节,如某个用户在15分钟内未完成支付,由后续队列中用户依次进入支付界面)。
三、简化流程
1、将下单界面所有需要查询数据库的操作,全部干掉,换成只从缓存中获取。
2、选择收货地址、积分抵扣、余额支付这些操作,全部干掉,换成在支付的时候去操作。
四、前端优化
采用YSlow原则,对前端进行优化。
例如:秒杀活动列表中的商品缩略图采用(CSS Sprites)化,减少网络请求。JS合并请求,图片、JS设置相关的浏览器端缓存策略。从而可以减少CDN的带宽输出。
五、独立部署、服务化、容器化
例如:
style.xxx.com 为静态资源【JS、JSON、HTML】,部署在独立的CDN或者集群上。
img.xxx.com 为图片资源,部署在独立的CDN或者集群上。
token.xxx.com 为静态参数资源服务器【获取秒杀界面地址】
seckill.xxx.com 为秒杀应用服务器。
同时为了防止活动时出现其他问题,可以将。秒杀相关的应用服务器,利用Docker等服务编排机制,在必要时瞬时上线相关备用服务,保证秒杀活动的高可用。
评论