秒杀系统的设计

一，秒杀系统要解决的技术挑战

1，短时间内的超高访问量对后台服务的冲击。秒杀期间，来自外部请求产生的QPS会是平时的10~100倍。
2，数据库的读写压力陡增。大量的并发写，会造成数据库的行锁处于无法释放的状态，大量的线程排队进而造成服务请求超时失败。
3，网络带宽资源会因为秒杀被大量占据掉。假设秒杀页面的大小为150K，如果最大并发连接数为20000，那么应用服务器至少需要支持的带宽>3G。

---

二，秒杀系统开发前的准备

1，将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素，所有页面的静态资源走CDN，CSS， JS和图片放入CDN后，利用遍布全国的CDN节点，降低带宽和静态服务器的压力，避免网络带宽成为业务瓶颈。
2，准备独立的服务器，秒杀系统单独部署，包括使用单独域名，避免秒杀业务对正常业务的系统的冲击和影响。
3，建立性能测试的环境，上线前根据本次秒杀的业务目标和流量预估，制定性能测试计划，只有通过性能测试后，才能真正上线。

---

三，秒杀系统的架构设计

1，前端的设计

在整个活动过程中，前端页面应该是如下状态：
1，秒杀开始前，秒杀按钮灰掉为“未开始”，不可点击。
2，秒杀进行中，秒杀按钮可以点击下单。
3，秒杀结束后，秒杀按钮灰掉为“已结束”，不可点击。

所以我们需要做以下几件事：
1，秒杀产品的介绍，详情，参数等等，全部静态化，切勿通过后台API查询更新，减轻后端的压力。
2，用户点击“下单”后，按钮置灰，禁止用户重复提交请求，限制用户在60秒之内只能提交一次请求。
3，“下单”的URL在活动开始前不可露出或者生效，否则容易被使用工具绕过浏览器提前下单。导致活动还未开始，已经开始下单这个大黑洞。正确的做法是活动开始前，通过更新JS文件露出下单的URL。
4，下单过程中，涉及到订单参数的修改全部关掉，比如，购买的金额，产品的份额等等，降低订单服务的压力。

2，服务层的设计

服务层的设计，如下图所示：

1，确保所有服务的缓存是独立分开，相互不影响，通过nginx负载均衡+集群部署，提高整体系统的承受能力。
2，检查用户的身份和条件，将无效的用户请求阻止在业务层之前，即限流。
3，所有读请求全部走缓存Redis, 并发量很大的时候一般不建议直接读数据库。
4，秒杀开始前，所有产品的属性和库存预加载到缓存中，即数据预热，秒杀过程中不主动更新数据库，库存数据延迟异步更新，例如12306的余票，有时候显示有票，但实际上是没有票的，这是缓存没有及时更新而已，但是这是在能接受的范围内。
5，削峰和异步处理：对于订单的写请求，加缓存，并做请求队列，加入请求队列后返回操作成功，不让用户一直等待，每次只透过有限的写请求去数据层，扣除库存成功均成功再进行下一批订单数据的更新，如果库存不够则队列里的写请求全部直接返回，尽可能阻止无效的请求穿透到数据层；
6，当瞬间秒杀产品库存太大，造成的Redis写暴增，可能造成线程阻塞最后写超时对于如上的异常，添加一个秒杀开关，大量异常时开关关闭停止一切秒杀活动，以免造成更大的损失。

---

四，建立秒杀系统的监控

为了应对秒杀过程中的各种突发情况，我们还需要建立有效的监控手段来保障秒杀的过程。
1，监控Redis调用性能，主要是看读和写的性能两个指标。
2，监控各个关键接口的运行情况，特别是下单接口的状态，看是否有大量请求timeout或者异常的情况出现，关注失败的订单数，设置预警阈值。如果超过阈值，报警并采取紧急处理措施，例如关闭秒杀，进行服务降级。
3，监控数据库的性能，密切关注订单写库的执行状态和读库的同步情况。
4，监控消息队列的情况。

---

五，参考资料

https://mp.weixin.qq.com/s?__biz=MzI3OTUwMjM4MA==&mid=2247483818&idx=1&sn=47b79c7c976981c660cbaad32322435a&chksm=eb478ae9dc3003ff82c2a92946f9815e9b300869129320d8810051507de70f72089f364643ec&scene=21#wechat_redirect