秒杀设计方案

[iralance]

原则

• 读数据： 不做强一致性校验，数据通过分层校验来修正。
• 写数据： 写数据进行强一致性校验，通过限流保护来保证写数据的成功性。

  技术难点

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

  准备

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

  架构设计

  前端的设计

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

  服务层的设计

• 确保所有服务的缓存是独立分开，相互不影响。
• 检查用户的身份和条件，将无效的用户请求阻止在业务层之前。
• 所有读请求全部走缓存，Redis or MemCached, 也可以考虑走读库，请注意流量的分配。
• 预热。秒杀开始前，所有产品的属性和库存预加载到缓存中，秒杀过程中不主动更新数据库，库存数据延迟异步更新。
• 对于订单的写请求，加缓存，并做请求队列，每次只透过有限的写请求去数据层，扣除库存成功均成功再进行下一批订单数据的更新，如果库存不够则队列里的写请求全部直接返回，尽可能阻止无效的请求穿透到数据层；
• 当瞬间秒杀产品库存太大，造成的Redis写暴增，可能造成线程阻塞最后写超时对于如上的异常，添加一个秒杀开关，大量异常时开关关闭停止一切秒杀活动，以免造成更大的损失。

  监控

• 监控Redis调用性能，主要是看读和写的性能两个指标。
• 监控各个关键接口的运行情况，特别是下单接口的状态，看是否有大量请求timeout或者异常的情况出现，关注失败的订单数，设置预警阈值。如果超过阈值，报警并采取紧急处理措施，例如关闭秒杀，进行服务降级。
• 监控数据库的性能，密切关注订单写库的执行状态和读库的同步情况。

  实现

• redis的list+setnx
• redis的multi+watch
• nginx+lua+redis