场景
特价商品如茅台，在8月1日22点10分0秒开始秒杀
平台用户量：几千万，预计几十万用户感兴趣
需求
临时性的活动，不要太大技术改动
原则
- 商品不能超卖
- 下单成功的订单不能丢失
- 服务器和数据库不能崩溃
- 尽量不让机器人抢走商品
整体思路
其实设计方案就是不断过滤请求的过程。
浏览器-负载均衡-网关-后台服务器-缓存-数据库
- 浏览页面 尽可能将静态资源放入CDN， 防止占用过多出口带宽
- 下单
- 付款
- 成功
动态请求
- 评论、商品详情、购买数量等相关请求，在秒杀场景可以把重要商品的详情页变成静态页面，当然如果实在不行，放入redis也行
- 秒杀前端需要获取秒杀开始的时间，根据时间开启秒杀的标志，将下单设置为可用。这个获取开始时间的请求，可以放到负载均衡层
- 判断秒杀结束，将秒杀结束的标志放入cookie，没有结束标志再请求后台服务，后台服务判断本地内存没有结束标志，再请求缓存，缓存也没有，说明秒杀没结束
下单页面如何拦截
为防爬虫，下单页面做两层防护
- 页面url后台动态获取，秒杀时间一到，就通过另一个请求获取该url
- 用户点击下单按钮后，就设置为diable，防止不断点击
提交订单
这是核心环节
网关层面的过滤
- 限定每个用户的访问频率，比如每5秒下单一次
- 限定每个IP的访问频率，避免机器人下单，错失真实用户
- 一个时间段内的请求拦截掉一定比例，或者只允许特定数量的请求进入后台服务器，如限流的漏桶或令牌桶算法
后台服务：保证特价商品不超卖，保证订单的准确性
- 商品库存放入缓存Redis中，decr操作扣减库存，库存扣减后小于0，说明秒杀失败，将库存用incr操作恢复；如果Redis的库存扣减后不小于0，说明秒杀成功，开始创建订单
- 如果有别的服务修改db的库存？通过业务流程保证，具体操作：在秒杀活动开始前，明确规定一个操作窗口，在这个时间内完成所有上架、库存修改和其他准备工作，在秒杀期间，对相关的业务操作（如上架和库存修改）进行冻结
- 订单写缓存 先写缓存，每隔一段时间(100ms)批量落库。用户下单，进入等待页面，向后台定时轮询查订单，如果落库成功，弹出成功提示并跳转
批量落库失败的处理：
查缓存-落库-删对应缓存数据，落库用事务包裹，失败回滚，其他不用处理，落库需要支持幂等性，根据手机号作为唯一索引
付款页面
订单未及时付款而被取消需要把数据库和redis的库存加回去
MQ
服务间触发通知需要使用
