架构师训练营第九周作业

用户头像
Bruce Xiong
关注
发布于: 2020 年 08 月 05 日



请简述 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等服务编排机制,在必要时瞬时上线相关备用服务,保证秒杀活动的高可用。



用户头像

Bruce Xiong

关注

熊大 2017.10.18 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第九周作业