架构师第九周作业

设计一个秒杀系统，主要的挑战和问题有哪些？核心的架构方案或者思路有哪些？

1、挑战和问题

秒杀系统是一种营销和推广的手段，意于用低价商品或稀缺资源吸引用户眼球，提升应用访问量、推广应用。由于秒杀的商品有限，因此对后端数据库架构基本没有多大影响。在营销层面：如何推广和造势，用最小的代价吸引更多的用户眼球；如何选择商品和数量，达到预期效果；最终目的是要通过秒杀活动，产生后续影响，提升用户流量和活跃度，达到预期效果。在技术层面：如何让前端应用顶住用户访问压力不宕机；如何识别羊毛党、反欺诈、秒杀机器人；如何做到对所有用户公平，杜绝内鬼；实现细节考虑周到，杜绝程序漏洞、bug。

这里有一个前提条件：应用的知名度有多大？也就是说平时应用的访问量有多少，注册用户量是多少等，在营销推后，能达到的注册用户量有多少？这些是考虑如何设计系统的首要前提。如果没有这些数据，那么设计出来的秒杀系统可能会存在过度设计或设计不足的情况。

这里我们假设应用是一个才起步一年的在线购物网站，注册用户数为20W，日活跃用户量为4W，在此次营销推广后，预计注册用户量可以突破50W，秒杀活动期间的在线用户预计会突破30W。

2、核心架构及思路

1、活动涉及的所有图片、文本等静态资源通过CDN进行缓存

2、通过反向代理(比如nginx)，进行负载均衡，这里采用容器进行部署，可以根据流量进行动态伸缩

3、应用采用容器技术实现弹性伸缩

4、采用消息中间件对接后端数据库，进行异步处理

架构图如下图所示：

说明：

1、秒杀商品相关信息提前缓存

2、秒杀商品库存提前锁定好，这样只需设置队列长度即可，队列满即代表秒完

3、反向代理采用容器化部署，且能根据设好的安全流量阈值，超过即自动扩展，实现弹性伸缩

4、应用也采用容器化部署，根据负载情况自动弹性伸缩

5、只要到应用层不跨掉，那秒杀活动对于后端存储的影响基本没有

6、针对不同流量级的用户量，前端实现了弹性伸缩，后端存储只需监控其性能，手动起集群节点即可，可满足不同场景需求