很多人理解的MQ就是「生产者发消息，消费者收消息」，但在秒杀场景下，光把消息发出去远远不够。
同一个活动的库存扣减必须串行执行，否则就会超卖。怎么做到的？
- 用RocketMQ的有序消息
- 以活动编号作为hashKey做哈希路由
- 同一个活动的请求全部落到同一个队列，消费端再按队列维度顺序消费。
消费端的顺序保证不是靠业务代码里加分布式锁，而是RocketMQ自身的两层锁机制：
- Broker端的分布式锁保证集群内只有一个消费者实例能锁定某个队列
- 本地synchronized锁保证同一实例内不会多线程并发消费同一队列。
两层锁配合，库存扣减就天然串行化了。
另一个实际问题是支付超时关单。用户下单后有10分钟的支付窗口，超时未支付要自动关闭订单释放库存。这个用延迟消息来做，比定时任务扫表干净很多。每个订单的超时是独立的，不需要批量扫描。
还有一个容易踩的坑：顺序消费模式下，maxReconsumeTimes的默认值是Integer.MAX_VALUE，相当于无限重试。一条消息卡住了，整个队列后面的消息全部排队等着。
秒杀系统里我们设成3，3次消费失败就进死信队列，由人工介入。这个细节不注意，线上一出问题整个队列就堵死了。
且内容里还覆盖了Topic和消费者组的命名规范、消息体字段的设计考虑（traceId怎么贯穿全链路、token怎么做幂等校验）、生产端和消费端的配置参数怎么设。不是泛泛地讲RocketMQ怎么用，而是在秒杀这个具体场景下，每个配置为什么这么选，背后的考量是什么。
我写这个秒杀专栏的目标就一个：每一篇你看完就能直接拿去用，不需要再翻别人的文章。如果你正在做秒杀系统或者高并发场景的技术选型，这个专栏从需求分析、架构设计到每一行核心代码，全链路都覆盖了。订阅专栏，少走弯路。
最近在知乎出了秒杀专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：
- 老码头的技术浮生录
它是一个能实际帮你解决难题的星球。有问题的，找知心的Sam哥，支持无限次语音一对一解决你遇到的难题。另外后续我新写的所有对外的付费专栏，在星球内都是免费的，且可以拿到所有源代码。
我的知乎账号:
- SamDeepThinking
