秒杀设计

防止库存超卖

用户少，并发少：

直接使用商品上下架的功能来实现秒杀。（直接读库）

用户量大，并发高：

1. redis设置一定的量（库存100，设置redis200）
2. 异步下单，redis扣减成功，放入消息队列。前端显示排队中
3. 消息队列消费（判断数据库的真实库存，之前是判断的redis的数量，消费消息）
4. 前端轮训到结果显示秒杀成功或者失败。

redis的数量不是库存,他的作用仅仅只是为了阻挡多余的请求透穿到DB，起到一个保护的作用

redis 预减成功，DB扣减库存失败怎么办

其实我们可以不用太在意，对用户而言，秒杀不中是正常现象，秒杀中才是意外，单个用户秒杀中

1. 本来就是小概率事件，出现这种情况对于用户而言没有任何影响
2. 对于商户而言，本来就是为了活动拉流量人气的，卖不完还可以省一部分费用，但是活动还参与了，也就没有了任何影响
3. 对网站而言，最重要的是体验，只要网站不崩溃，对用户而言没有任何影响

高可用

一定要做到服务的稳定，不能因为秒杀活动而影响了正常的流程。如果活动力度比较大，做好评估，或者是单独为秒杀设置单独的接口，以及单独的服务等策略。一定要保证正常流程的稳定。

服务保护

对相应的服务降级，限流。保证服务的稳定性。

降级

故障降级

做一些兜底的方案

人工降级

1. 暴力降级 服务全部降级
2. 接口等级降级，根据接口重要性进行降级

自动降级

根据请求的阈值进行限流。

保证不崩的情况下，开发需要做相应的异常兼容。