秒杀系统的场景特点
- 秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增；
- 秒杀一般是访问请求量远远大于库存数量，只有少部分用户能够秒杀成功；
- 秒杀业务流程比较简单，一般就是下订单操作；
秒杀架构设计理念
- 限流：鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端（暂未处理）；
- 削峰：对于秒杀系统瞬时的大量用户涌入，所以在抢购开始会有很高的瞬时峰值。实现削峰的常用方法有利用缓存或者消息中间件等技术；
- 异步处理：对于高并发系统，采用异步处理模式可以极大地提高系统并发量，异步处理就是削峰的一种实现方式；
- 内存缓存：秒杀系统最大的瓶颈最终都可能会是数据库的读写，主要体现在的磁盘的I/O，性能会很低，如果能把大部分的业务逻辑都搬到缓存来处理，效率会有极大的提升；
- 可拓展：如果需要支持更多的用户或者更大的并发，将系统设计为弹性可拓展的，如果流量来了，拓展机器就好；
秒杀设计思路
-如果前端是属于小程序端，所以不存在前端部分的访问压力，所以前端的访问压力就无从谈起；
- 1、秒杀相关的活动页面相关的接口，所有查询能加缓存的，全部添加redis的缓存；
- 2、活动相关真实库存、锁定库存、限购、下单处理状态等全放redis；
- 3、当有请求进来时，进入活动ID为粒度的分布式锁，第一步进行用户购买的重复性校验，满足条件进入下一步，否则返回已下单的提示；
- 4、第二步，判断当前可锁定的库存是否大于购买的数量，满足条件进入下一步，否则返回已售罄的提示；
- 5、第三步，锁定当前请求的购买库存，从锁定库存中减除，并将下单的请求放入kafka消息队列；
- 6、第四步，在redis中标记一个polling的key（用于轮询的请求接口判断用户是否下订单成功），在kafka消费端消费完成创建订单之后需要删除该key，并且维护一个活动id+用户id的key，防止重复购买；
- 7、第五步，消息队列消费，创建订单，创建订单成功则扣减redis中的真实库存，并且删除polling的key。如果下单过程出现异常，则删除限购的key，返还锁定库存，提示用户下单失败；
- 8、第六步，提供一个轮询接口，给前端在完成抢购动作后，检查最终下订单操作是否成功，主要判断依据是redis中的polling的key的状态；
- 9、整个流程会将所有到后端的请求拦截的在redis的缓存层面，除了最终能下订单的库存限制订单会与数据库存在交互外，基本上无其他的交互，将数据库I/O压力降到了最低；