谈谈秒杀系统的落地方案

Posted 2021-05-02 架构栈

昨天的给秒杀系列开了一个头，今天会集中讲一下实现一个秒杀系统的思路和方案，不代表这就是最好的方案或者最佳实践，而是希望通过这篇文章，能起到抛砖引玉的作用，希望有更佳的思路提供出来。

    

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

    

    1. 短时间内的超高访问量对后台服务的冲击。秒杀期间，来自外部请求产生的QPS会是平时的10~100倍。

    2.  数据库的读写压力陡增。大量的并发写，会造成数据库的行锁处于无法释放的状态，大量的线程排队进而造成服务请求超时失败。

    3.  网络带宽资源会因为秒杀被大量占据掉。假设秒杀页面的大小为150K，如果最大并发连接数为20000，那么应用服务器至少需要支持的带宽>3G。

   

     秒杀系统开发前的准备

    

    1. 所有页面的静态资源走CDN，CSS， JS和图片放入CDN后，利用遍布全国的CDN节点，降低带宽和静态服务器的压力，避免网络带宽成为业务瓶颈。

    2. 准备独立的服务器，秒杀系统单独部署，包括使用单独域名，避免秒杀业务对正常业务的系统的冲击和影响。

    3. 建立性能测试的环境，上线前根据本次秒杀的业务目标和流量预估，制定性能测试计划，只有通过性能测试后，才能真正上线。

        秒杀系统的架构设计

       1.  前端的设计

    

        在整个活动过程中，前端页面应该是如下状态：

秒杀开始前，秒杀按钮灰掉为“未开始”，不可点击。

秒杀进行中，秒杀按钮可以点击下单。

秒杀结束后，秒杀按钮灰掉为“已结束”，不可点击。

所以我们需要做以下几件事：

    1.  秒杀产品的介绍，详情，参数等等，全部静态化，切勿通过后台API查询更新，减轻后端的压力。

    2.  用户点击“下单”后，按钮置灰，禁止用户重复提交请求，限制用户在60秒之内只能提交一次请求。

    3.  “下单”的URL在活动开始前不可露出或者生效，否则容易被使用工具绕过浏览器提前下单。导致活动还未开始，已经开始下单这个大黑洞。正确的做法是活动开始前，通过更新JS文件露出下单的URL。

    4. 下单过程中，涉及到订单参数的修改全部关掉，比如，购买的金额，产品的份额等等，降低订单服务的压力。

        2. 服务层的设计

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

1. 确保所有服务的缓存是独立分开，相互不影响。

2. 按照昨天文章写到的那样，检查用户的身份和条件，将无效的用户请求阻止在业务层之前。
   

3. 所有读请求全部走缓存，Redis or MemCached,  也可以考虑走读库，请注意流量的分配。
   

4. 秒杀开始前，所有产品的属性和库存预加载到缓存中，秒杀过程中不主动更新数据库，库存数据延迟异步更新。

5. 对于订单的写请求，加缓存，并做请求队列，每次只透过有限的写请求去数据层，扣除库存成功均成功再进行下一批订单数据的更新，如果库存不够则队列里的写请求全部直接返回，尽可能阻止无效的请求穿透到数据层；

6. 当瞬间秒杀产品库存太大，造成的Redis写暴增，可能造成线程阻塞最后写超时对于如上的异常，添加一个秒杀开关，大量异常时开关关闭停止一切秒杀活动，以免造成更大的损失。

   
   

建立秒杀系统的监控

    为了应对秒杀过程中的各种突发情况，我们还需要建立有效的监控手段来保障秒杀的过程。

1. 监控Redis调用性能，主要是看读和写的性能两个指标。

2. 监控各个关键接口的运行情况，特别是下单接口的状态，看是否有大量请求timeout或者异常的情况出现，关注失败的订单数，设置预警阈值。如果超过阈值，报警并采取紧急处理措施，例如关闭秒杀，进行服务降级。

3. 监控数据库的性能，密切关注订单写库的执行状态和读库的同步情况。

欢迎转载，带上以下二维码即可

                          

点击“阅读原文”，所有【架构栈】近期的架构文章汇总

↓↓↓