双11秒杀场景设计，一看就懂！-技术圈

秒杀这个话题到现在来说已经是一个老生常谈的话题了，不过因为又临近一年一度的双11，而且发现前段时间无论是阿里还是腾讯一些大厂其实还是在频繁的问到这个场景题，所以还是准备拿出来说说。

秒杀从规模上来说可以分为大秒和小秒。大秒指的是比如双11这种特定的节日，商品规模超大、价格超低、流量超大的这种类型活动，小秒一般指的是商家自己配置的一些时段类型的活动，由商家自己指定时间上架。从形式来说还可以分为单时段秒杀和多时段秒杀。但是在这个场景里，我们一般就是指的单时段大型秒杀。

秒杀设计要面对的压力和难度有几点：

怎么保证超高的流量和并发下系统的稳定性？如果峰值的QPS达到几十万，面对巨大的流量的压力系统怎么设计保证不被打崩？
怎么保证数据最终一致性？比如库存不能超卖，超卖了那亏本的要么就是商家要么就是平台，用户反正不背这个锅，超卖了就今年325预订。

当然，涉及到这种大型的活动，还需要考虑到数据统计分析，总不能活动做完了，效果不知道怎么样。

系统架构

假设今年的双11预估峰值QPS将会有50万(我随便扯的)，而根据我们平时的经验单机8C8G的机器可以达到1000左右的QPS，那么从理论上来说我们只要500台机器就可以抗住了，就有钱任性不行？这么设计的话只能出门右转不送了。

流量过滤

本质上，参与秒杀的用户很多，但是商品的数量是有限的，真正能抢到的用户并不多，那么第一步就是要过滤掉大部分无效的流量。

活动开始前前端页面的Button置灰，防止活动未开始无效的点击产生流量
前端添加验证码或者答题，防止瞬间产生超高的流量，可以很好的起到错峰的效果，现在的验证码花样繁多，题库有的还要做个小学题，而且题库更新频繁，想暴力破解怕是很难。当然我知道的还有一种人工打码的方式，不过这个也是需要时间的，不像机器无限刷你的接口。
活动校验，既然是活动，那么活动的参与用户，参加条件，用户白名单之类的要首先做一层校验拦截，还有其他的比如用户终端、IP地址、参与活动次数、黑名单用户的校验。比如活动主要针对APP端的用户校验，那么根据参数其他端的用户将被拦截，针对IP、mac地址、设备ID和用户ID可以对用户参与活动的次数做校验，黑名单根据平时的活动经验拦截掉一部分羊毛党等异常用户。
非法请求拦截，做了以上拦截如果还有用户能绕过限制，那不得不说太牛X了。比如双11零点开始还做了答题限制，那么正常人怎么也需要1秒的时间来答题吧，就算单身30年手速我想也不能超过0.5秒了，那么针对刚好0点或者在0.5秒以内的请求就可以完全拦截掉。
限流，假设秒杀10000件商品，我们有10台服务器，单机的QPS在1000，那么理论上1秒就可以抢完，针对微服务就可以做限流配置，避免后续无效的流量打到数据库造成不必要的压力。针对限流还有另外一种栅栏方式限流，这是一种纯靠运气的限流方式，就是在系统约定的请求开始的时间内随机偏移一段时间，针对每个请求的偏移量不同，如果在偏移时间之内就会被拦截，反之通过。

性能优化

做完无效流量的过滤，那么可能你的无效请求已经过滤掉了90%，剩下的有效流量会大大的降低系统的压力。之后就是需要针对系统的性能做出优化了。

页面静态化，参与秒杀活动的商品一般都是已知的，可以针对活动页面做静态化处理，缓存到CDN。假设我们一个页面300K大小，1千万用户的流量是多少？这些请求要请求后端服务器、数据库，压力可想而知，缓存到CDN用户请求不经过服务器，大大减小了服务器的压力。
活动预热，针对活动的活动库存可以独立出来，不和普通的商品库存共享服务，活动库存活动开始前提前加载到redis，查询全部走缓存，最后扣减库存再视情况而定。
独立部署，资源充足的情况下可以考虑针对秒杀活动单独部署一套环境，这套环境中可以剥离一些可能无用的逻辑，比如不用考虑使用优惠券、红包、下单后赠送积分的一些场景，或者这些场景可以活动结束后异步的统一发放。这只是一个举例，实际上单独针对秒杀活动的话你肯定有很多无用的业务代码是可以剥离的，这样可以提高不少性能。

经过这两步之后，最终我们的流量应该是呈漏斗状。

超卖

秒杀除开高并发高流量下的服务稳定性之外，剩下的核心大概就是怎么保证库存不超卖了，也可以说要保证的是最终一致性。一般来说，针对下单和库存有两种方式:

下单即扣库存，这是最常规的大部分的做法。但是可能在活动中会碰到第二点说到的情况。
支付完成扣库存，这种设计我碰到过就是酒店行业，廉价房放出来之后被黄牛下单抢占库存导致正常用户无法下单，然后黄牛可以用稍高的价格再售卖给用户从中牟利，所以会有在一些活动的时候采取支付成功后才占用库存的做法。不过这种方式实现起来比较复杂，可能造成大量的无效订单，在秒杀的场景中不太适用。

针对秒杀建议选择下单扣库存的方式，实现相对简单而且是常规做法。

方案

首先查询redis缓存库存是否充足
先扣库存再落订单数据，可以防止订单生成了没有库存的超卖问题
扣库存的时候先扣数据库库存，再扣减redis库存，保证在同一个事务里，无论两者哪一个发生了异常都会回滚。有一个问题是可能redis扣成功了由于网络问题返回失败，事务回滚，导致数据库和缓存不一致，这样实际少卖了，可以放到下轮秒杀去。

这种做法能一定程度上解决问题，但是也有可能会有其他问题。比如当大量请求落在同一条库存记录上去做update时，行锁导致大量的锁竞争会使得数据库的tps急剧下降，性能无法满足要求。

另外一种做法就是排队，在服务层进行排队，针对同一个商品ID的也就是数据库是一条库存记录的做一个内存队列，串行化去扣减库存，可以一定程度上缓解数据库的并发压力。