“秒杀”这个词在电商行业中出现的频率较高，如京东或者淘宝平台的各种“秒杀”活动，最典型的就是“双11抢购”。
“秒杀”是指在有限的时间内对有限的商品数量进行抢购的一种行为，这是商家以“低价量少”的商品来获取用户的一种营销手段。
需求分析
- 功能性需求
其实，整个秒杀的业务场景并不复杂，可即查看参与秒杀的商品信息，加上购买和支付的动作，如下图所示。
秒杀业务场景最大的挑战在于3点：
- 瞬时
- 流量巨大
- 数量有限
同时，在保证高并发流量承接的前提下，为了增强用户的体验和活动规则的公平性，以及防止遭到恶意破坏等，特此增加如下需求：
（1）用户在秒杀页面无需一直刷新“抢购”按钮，待秒杀活动开始时，按钮自动点亮。
（2）在公平以及防止恶意破坏的原则下，在下单之前增加验证码的录入，或者答题的相关环节。
（3）库存不能出现问题，即不多扣也不少扣。
（4）整个秒杀活动过程持续10分钟。
- 性能指标预估
通过秒杀的需求描述可得出，当前秒杀活动主要需要预估三块的性能指标：存储容量、并发量、网络带宽。
- 存储容量
由于是秒杀活动，且参与的商品基本都是低价高性价比的，数量是非常有限的。所以，在订单存储上基本不用去过多考虑。 - 并发量
针对5000万用户平均每人访问2次，则并发量为每秒16.7万左右（5000w2/1060）,在预留一部分，可以预估到每秒25万左右（也可以进行double下）。 - 网络带宽
在带宽方面，需要进行相关优化，采取数据传输越少越好，假设单条传输在0.5KB，则根据并发量预估网络带宽为：977Mb左右（25w0.5KB=122MB8bit=977Mb）。
- 非功能性需求
做任何系统都要考虑非功能性需求，特别是公司的核心系统，当前秒杀业务系统非功能性需求
主要体现在如下几点：
高可用，在秒杀活动的整个持续期间内，都能对用户提供服务。
高性能，让每个用户都能感受到极快的秒杀响应，不能出现大批量用户延迟较高的现象。
可扩展，当流量比预期更高时，有平滑扩展的策略（也有部分产品设计成友好的拒绝策略）。
概要设计
通过对秒杀业务的本身认知以及上面提到的秒杀业务需求，本次秒杀系统需要着重设计如下几点：
（1）动静分离：如何保证用户在不刷新页面的情况下，依然能进行秒杀相关数据的获取且不会耽误秒杀活动的开始。
（2）流量分层，针对巨大流量，如何进行有效的防控，以免造成后台服务的不堪重负，以及如何避免前端页面的卡死。
（3）高可用：如何确保后台持续提供服务。
（4）扣减库存：如何有效扣减库存。
（5）系统架构设计
详细设计
- 动静分离
实施动静分离架构可以采用“分而治之”的办法，即将动态数据和静态数据解耦，分别使用各自的架构系统来承载对应的流量：
对于静态数据，推荐缩短用户请求路径，因为路径越短，访问速度也就越快。另外，即尽可能将静态数据缓存起来。
对于动态数据，一般用户端需要和服务端进行交互才能获取，所以，请求路径较长，访问速度会慢一点。下图展示了动静分离方案。
静态数据访问速度很快，而动态数据访问速度较慢。那么试想下，可以将需要动态获取的数据给提前生成好，然后使用静态页面加速技术来访问吗？如果这样可以，那动态数据访问的速度就变快了。
这样是可以的，需要用到比较流行的“页面静态化”技术。页面静态化技术是指，直接缓存HTTP连接，而不仅是缓存数据。如下图所示，代理服务器根据请求的URL直接将HTTP对应的响应头及响应消息体返回，流程简洁且高效。
- 流量分层设计
流量分层主要体现在对于CDN层、反向代理层、后端服务层以及数据层流量进行控制。
1）CDN层流量控制
由动静分离技术可以想到：应尽量将尽可能多的数据提前生成，然后将其放入CDN节点缓存中（因为CDN层在物理架构上离用户比较近）。
所以，如果绝大部分的流量都在这一层获取数据，则到达后端的流量会减少很多，如下图所示。
图片
2）反向代理层流量控制
在动静分离方案中，讲到通过“页面静态化技术”加速动态数据的获取，即提前将动态数据生成好，然后对其进行静态化处理。
所以，这里就可以依据页面静态化加速技术，通过后端服务Job的方式定时提前生成前端需要静态的数据；然后，将其发送到内容分发服务上；最后，分发服务会将这些静态化页面数据分发到所有的反向代理服务器上，如下图所示。
图片
在“秒杀”业务中，活动详情页上有一个倒计时的模块，用户可以看到当前“秒杀”活动还剩余多少时间开始。
这种逻辑简单的功能可以直接使用Nginx来实现：利用nginx-lua插件，使用lua脚本获取当前Nginx服务器的时间进行计算倒计时。
另外，商品库存数据也可以通过Nginx直接访问分布式缓存来获取，如下图所示。
图片
“秒杀”业务中的商品价格很低，对于用户有很大的吸引力，所以可能会有人利用“秒杀器”进行不公平竞争，且有可能存在竞争对手恶意刷请求的情况。
如果存在这样的情况，那本次活动就是有风险的，万一被恶意流量独占了库存，则会导致正常用户不能抢购商品，也有可能这种恶意的请求会对后端系统造成严重冲击，甚至造成后端系统瘫痪。
对于这种恶意请求，最好有一套机制能提前感知，并将恶意请求提前封存。可以在Nginx层中控制；也可以在Nginx中配置用户的访问频率（例如每分钟只能访问10次）；还可以使用Lua脚本编写一些简单业务逻辑的接口，例如，通过调用接口直接封掉指定IP地址或UserAgent的请求。
3）后端服务层流量控制
对于服务层的流量控制，有以下几点建议：
在程序开发上，代码独立，不要与平台其他项目一起。
在部署时，应用独立部署，分散流量，避免不合适的流量影响主体业务。
使用独立域名，或者按照一定的URL规则在反向代理层进行路由。
做好系统保护和限流，进一步减少不必要的流量。
当“到达系统中的请求数”明显大于“系统能够处理的最大请求数”时，可以直接拒绝这些多余的请求，直接返回“秒杀”活动结束的信息。例如，活动开始时的商品库存是100，目前库存只剩50了，如果“每台服务器待处理的请求数”已经超过“商品总库存数（100）”了，则可以直接终止掉多余的请求。
4）数据库层流量控制
对于请求到数据中的流量，写入的流量就是真正下单成功的流量，即需要扣减库存的动作。有如下建议：
如果不是临时的活动，则建议使用独立的数据库作为“秒杀”活动的数据库。
将数据库配置成读写分离。
尝试去除行锁。
对于数据库行锁的优化，可以通过将商品进行拆分来实现——增加ID，如下图所示。对于单一的“秒杀”活动这会得到显著效果。
从流量分层控制方案可看出，瞬时流量就像被漏斗过滤了似的，应尽量将数据和请求量一层一层地过滤掉。这种流量分层控制核心思想：在不同的层级中尽可能地过滤掉无效的请求，到达“倒三角”最末端的请求才是有效的请求。
5）高可用
在系统设计时想要做到高可用，避免单节点的一个小妙招：将服务无状态化。如果无法完全无状态化（如存储系统），则可以通过冗余多个备份节点的方案来避免单节点。
由于篇幅原因，高可用此处就不再赘述，大家可以查看《高并发系统实战派》一书里面针对高并发系统的真实设计案例，毫无保留的分享出了企业级高并发系统实战。
- 扣减库存设计
由于在“秒杀”场景中商品一般优惠力度很大，对用户很具有吸引力，所以，在这种场景中使用“下单扣库存”方式更为合适。
在“秒杀”场景中，大部分用户抱着“抢到就是赚到”的想法，基本都会去付款的，但如果真有竞争对手恶意下单不付款，那我们该怎么办？前面在流量管控中已经说到，可以对请求日志进行实时分析，让风控系统选择出恶意用户，然后将其封停。
在“秒杀”场景中，通过流量分层控制可以分层管控大量的“读”请求。但是，依然会有很大的流量进入真正的下单逻辑。对于这么大的流量，除前面说的数据库隔离外，还需要进一步优化库存，否则数据库读/写依然是系统的瓶颈。
接下来看看如何优化大流量“秒杀”场景中的库存数量扣减操作。
1）利用缓存技术
在“秒杀”场景中，如果只是一个扣减库存数量这样的简单流程，则可以先将库存数量直接放在缓存中，然后用分布式缓存（如Redis）的超高性能去应对这种瞬时流量洪峰下的系统挑战。
使用缓存是存在一定风险的，比如，缓存节点出现了异常，那库存数量该怎么算？
使用缓存，不仅要考虑分布式缓存高可用（如何设计可以查看我的新书“高并发系统实战派”），还要考虑各种限流容错机制，以确保分布式缓存对外提供服务。
2）异步处理技术
如果是复杂的扣减库存（如涉及商品信息本身或牵连其他系统），则建议使用数据库进行库存数量的扣减，可以使用异步的方式来应对这种高并发的库存的更新。
①在用户下单时，不立刻生成订单，而是将所有订单依次放入队列。
②下单模块依据自身的处理速度，从队列中依次获取订单进行“下单扣库存”操作。
③在订单生成成功后，用户即可进行支付操作了。
这种方式是针对“秒杀”场景的，依据“先到先得”原则来保证公平公正，所有用户都可以抢购，然后等待订单处理，最后生成订单（如果库存不足，则生成订单失败）。
这样的逻辑，对用户来说体验不是很差。
那些技术
（1）数据的静态化的技术
用来应对高并发读的请求，主要涉及以下内容，这些在《高并发系统实战派》一书中详细分享了真实使用场景已经技术方案：
各层级缓存的处理（即多级缓存的技术）
分布式缓存技术
（2）负载均衡反向代理技术
LVS
Nginx
（3）异步处理技术
消息队列技术
排队系统技术
（4）系统架构设计技术
系统模块化划分
微服务架构思想
（5）系统监控技术
日志监控
服务监控