架构师训练营第九周作业



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