异步秒杀的可靠性重构升级
plus 版本专属
此章节是黑马点评 Plus 版本中专有的内容，而在整套文档中将普通版本和 Plus 版本都融合在了一起，让大家更方便的学习。
前提概要
在 秒杀优化 章节中，讲到了使用异步秒杀的思路来优化秒杀：
- 先在 Redis 中扣减库存，然后将信息发送到 Redis 的 Streams 中
- 当项目启动时，会有个线程不断地从 Redis 的 Streams 中取出消息然后在数据中生成订单
这种异步执行的设计确实比之前全都同步执行的效率要搞得多，但是带来的问题也会不少
一、背景与旧方案问题
请求侧用 Redis + Lua 判断资格并扣减库存，异步侧用 Redis Streams 拉取消息、创建订单。存在隐患
1.1 Redis 宕机/主从切换
- 复制滞后： 最近一次扣减在主库完成，但从库未复制；主从切换后该次扣减丢失，造成库存回跳与“一人一单”集合不一致
- stream backlog 丢失： failover 或重建 group 导致 backlog 消息不可达
1.2 消费与确认的脆弱性
- 消费后宕机丢单： 从 streams 取出消息、尚未入库时服务宕机，如果没有完备的 pending 恢复与重放策略，订单就丢失；同时在故障窗口内发生 trim/切换也会放大丢失概率
- pending 恢复不完善： 启动后未先处理 pending 队列，异常路径才补偿，导致积压消息长期未落库
1.3 线程与事务问题
- 阻塞队列驻内存、不持久；跨线程执行导致 Spring 事务上下文失效
1.4 一致性与对账不足
- Redis 与 DB 的扣减与订单状态缺少一致性与补偿闭环
二、Plus 版本对异步秒杀完全重构
升级使用 Kafka 作为消息管道，资格判定仍由 Redis+Lua 原子完成，但引入双重一致性、记录操作、幂等、对账，显著提升可靠性：
1）消息可靠性
Kafka 持久化日志与副本，支持重放与监控生态；消费成功后再提交位点，避免“消费后宕机丢单”
2）原子资格判定
Lua 在同槽位键上原子执行库存与一人一单校验与扣减，并记录 trace 日志
3）最终一致性与幂等
消费端以消息 UUID 幂等，数据库扣减与订单落库失败会触发 Redis 回滚，保持 Redis 与 DB 最终一致
4）对账与观察性
扣减/恢复统一写入对账日志，便于核对与补偿，避免丢单与库存错乱
5）自动补发
取消成功后，从订阅 ZSET 中选取“最早未购用户”自动补发资格，提升资源利用率
6）生命周期管理
缓存 TTL 按活动结束时间动态计算，清理临时键与日志
三、秒杀重构后的详细分析
3.1 流程概要
3.2 实现的代码
付费内容提示
该文档的全部内容仅对「JavaUp项目实战&技术讲解」知识星球用户开放
加入星球后，你可以获得：
- 超级八股文：100万+字的全栈技术知识库，涵盖技术核心、数据库、中间件、分布式等深度剖析的讲解
- 讲解文档：黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的从0到1的550+详细文档
- 讲解视频：黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的核心业务详细讲解
- 1 对 1 解答：可以对我进行1对1的问题提问，而不仅仅只限于项目
- 针对性服务：有没理解的地方，文档或者视频还没有讲到可以提出，本人会补充
- 面试与简历指导：提供面试回答技巧，项目怎样写才能在简历中具有独特的亮点
- 中间件环境：对于项目中需要使用的中间件，可直接替换成我提供的云环境
- 面试后复盘：小伙伴去面试后，如果哪里被面试官问住了，可以再找我解答
- 远程的解决：如果在启动项目遇到问题，本人可以帮你远程解决
进入星球后，即可享受上述所有服务，保证不会再有其他隐藏费用。
