Java架构师进阶（四）RocketMq应用实战|企业级MQ实战（中篇）

如果你已经能在项目里把 RabbitMQ 的收发跑通，却说不清 RocketMQ 的 Topic 和 Queue 到底谁管顺序、谁管并发，那这篇中篇就是冲你来的。它不打算从零讲消息队列是什么，而是默认你碰过 MQ、写过 Producer 和 Consumer，再往企业里真实要用的那几个点上压。

先确认你缺的是哪一块

上篇通常停在「消息能发出去、能收回来」这一步。可一旦上线，问题就变成另外几类：消息发出去 Broker 没落盘怎么办，消费失败是重试还是进死信，同一笔订单的两条消息会不会被两个消费者抢着处理，堆积了几百万条之后怎么排查。这些不是 API 会不会用的问题，是语义和边界的问题。

这门课瞄准的正是这段落差。它假设你已经知道 NameServer、Broker、Producer、Consumer 这几个角色的存在，重点讲它们之间的配合在什么条件下会出岔子。所以看之前，先问自己三个问题：普通消息、顺序消息、事务消息分别用在什么业务上；消息重试的次数和间隔在哪里配、配错了会怎样；消费位点是怎么提交的。这三个答不上来，就属于这门课要补的缺口。

顺序、事务、延时，别混着用

实际业务里最容易翻车的是顺序消息。全局有序和分区有序是两种完全不同的实现代价，前者几乎等于放弃吞吐，后者要求你把同一业务维度的消息投到同一个队列。课上会把「怎么保证同一订单的消息进同一队列」这类具体做法拆开，而不是丢一句「用顺序消息就行」。

事务消息则常被误解成「消息和数据库在同一个事务里」。它解决的其实是本地事务和消息发送的一致性问题，中间要经过半消息、回查这些步骤。哪一步失败会留下什么状态，回查逻辑该写什么，都是要落到代码里的。延时消息的精度边界也值得提前知道，免得拿它当定时任务用。

消费端才是事故高发区

生产端出问题往往很快暴露，消费端的问题则会安静地攒着。重复消费几乎是必然的，所以幂等要做在哪一层、用什么做键，得结合业务讲。消费失败之后的 retry topic 和死信队列，机制清楚了才敢决定是让它重试还是直接捞出来人工处理。

还有消费模式的选择：集群消费和广播消费的差别不只是「收几份」，它直接影响位点管理和扩容行为。消费者组增减机器时，队列怎么重新分配、重分配期间消息会不会卡住，这些在压测里不一定出得来，但在真实流量下会。课里会带实际案例走一遍监控和堆积排查，这部分对排查线上问题最有用。

看完你应该能回答

• 同一笔业务的两条消息，怎么保证被同一个消费者按顺序处理？
• 事务消息的回查逻辑如果一直失败，消息最终会怎样？
• 消息堆积了，你按什么顺序去查：Broker、消费组、还是业务代码？
• 幂等键该由生产端生成还是消费端自己算？
• 什么情况下你会主动选择广播消费？

配套练习建议别只看：自己搭一套单机 Broker，把顺序消息和事务消息各写一个最小可跑的例子，再人为让消费端抛异常，观察重试和死信的实际走向。这些现象亲眼见过一次，比看十遍概念都记得住。中篇的价值不在覆盖多少 API，而在把「能跑」和「敢上线」之间的那段距离量出来。缺哪块补哪块，不用假装全都会。