一、前言：
结合上一章节的单机版的秒杀系统设计，当一个实例的线程处理达到瓶颈时，可以尝试考虑增加一个实例，来做流量分担，但是问题又来了，增加实例，我们的处理速度就一定提升了呢？其实未必，我们需要找出流程的关键路径；
二、集群架构：
咱们抛开页面的CDN加速提升性能，以及集群前置的负载均衡策略，keeplive如何保障高可用。咱们还是集中研究后端系统的升级演绎，架构图如下：
数据预热
从上面的架构图，留意到，已经悄悄去掉了分布式锁，利用redis做数据预热，缓存库存数据，秒杀过程中的下单数据，恶意下单数据，秒杀的时间段，各个秒杀服务实例可以利用jvm锁，控制秒杀逻辑；
无效流量过滤
校验规则模块，通过系统预热加载的数据，可以做如下判断处理：
1）秒杀时间段的控制；
2）重复秒杀请求的控制；
3）恶意秒杀黑名单的控制，如果某个账号恶意下单，可以直接将登录账号拉黑，限制后续的秒杀请求，当然不排除误杀，根据投诉反馈，可以拉白操作；
4）秒杀进度，数据库库存告罄，可以关闭秒杀；
5）存放秒杀的订单数据，限制用户秒杀商品的数量；
.......................此处省略一万个字...............欢迎功夫大侠，来补充。。。
针对上面不满足要求的秒杀请求，可以直接拒绝秒杀请求，可以根据识别的秒杀异常类型，定义对应的错误码，前端根据错误码做对应的文案提示。
预扣库存
可以使用redis串行写的特征，来预扣库存，如果库存预扣完，redis中的库存数量小于等于0，表示当前库存数量已经预锁完，后续如果有下单未支付超时的订单，可以释放库存，继续秒杀。
创建订单，调整支付页面
针对已经成功预锁的订单，创建订单，返回线程结果为秒杀成功，前台页面引导用户跳转支付页面，页面提示支付时限；
支付成功，回调订单，扣减数据库库存
成功支付完订单，支付系统回调订单，订单正式通知库存扣减，扣减库存这一块可以采用异步的操作，库存扣减成功，异步回调订单，扣减结果；如果扣减失败，需要触发后续退款操作；
超时未支付订单，释放预锁库存
针对超时未支付的订单，系统需要释放预锁的库存；
