秒杀重点(后端)

① ⭐协程(不带返回值的函数调用)：比线程更加轻量级，一个线程可以拥有多个协程；完全在用户态被管理，阻塞不会像线程切换一样消耗资源，阻塞时可以调用其他协程，性能大大提升
② 在 nginx 指定挂载点插入 lua 脚本，执行一些业务逻辑，减少后端直接访问
③ 使用 openresty 的 share dic(内存中，LRU淘汰策略)，或者操作 redis(只读不写)

6. 消息中间件（抢单）

① 交易真正开始前，将库存放入缓存
② 消息队列异步更新数据库
③ 采用事务性消息；订单创建成功，才能消费减库存消息(光靠事务无法控制消费消息)
④ 记录库存流水状态，方便消息队列定期检测(事务可能已经成功，但是在返回时卡死或者数据库压力大，事务很久才提交；记录流水方便检测事务提交状态)
⑤ 罄销做标记
⑥ 不建议异步下单，前端需要等待支付信息返回才能支付(同步)

7.流量削峰

① 秒杀令牌：防止非法下单
② 秒杀大闸：根据库存量，限制令牌数量
③ ⭐队列泄洪(小容灾)：流量极大时，对redis与MySQL的压力巨大(下游压力)；本地设置一个阻塞窗口(线程池；最好是外部集中式队列不可用后，降级到本地)，限制对下游的最大压力；redis 本来就是单线程排队处理，所以无需担心性能

8.防刷限流

① 秒杀前获取验证码
② 直接限制并发(不建议)
③ ⭐令牌桶算法(guava)：初始化一定数量令牌，每秒填充一定数量令牌，拿到令牌的用户可以执行操作(适于突发流量；因为有初始令牌量)
④ 漏桶算法：初始沾满所有位置，每秒清空一定数量位置，占到位置的用户可以执行操作(适于平滑网络流量，固定速率流入；因为没有初始的资源)
⑤ 限流维度：接口维度 & 总维度(总维度一般小于所有接口维度相加)
⑥ ⭐防刷：排队、限流、令牌都只能限制总流量(难做)