RocketMQ4.X现存问题

• 消费能力不能随POD增加而增加。
  理想情况下，POD数量小于QUEUE的数量，增加机器是能提高消能力的。
  现实情况下，如果POD数量大于QUEUE的数量，那么多的POD机器就不会处理消费，是一种资源的浪费。

• 单节点HANG住影响整个TOPIC

• 云原生支持较差。4.x的架构如下图所示，Producer和Broker都是有状态的，所以需要抽取一部分无状态的模块，所以5.x新增了Proxy。
  

• 富客户端需要优化，接入协议需要支持
  重平衡的业务逻辑是在客户端做的，当然还有其他的，轻量级的API客户端是5版本的发力点。要做大做强，还要支持更多的协议。

5.X的pop消费模式

结论先行

先插入一个结论，Cousumer请求broker消费消息的时候，带的queueId = -1,在源码中表示的就是全部QUEUE

所以逻辑上一个Conumser能拿到所有的队列消息。

场景分析

以场景为例，假设有2台POD，一个TOPIC只有一个队列，在设置了POP拉取模式下，批量拉取的上限为2，整个消费过程如下图所示。

【POD1】步骤1：请求broker获取消息，此时有4/5的流量会打到目标TOPIC上，先关注一下还有与目标TOPIC一一对应的RETRY_TOPIC。

步骤2：【POD1】此时会把取到的两条消息，封装为一个PopCheckPoint （CK），叫到CK集合里。
步骤3：【POD1】broker把MSG12给pod1。
步骤4：【POD2】此时也请求Broker获取两条消息，此时获取的是MSG3和MSG4。
步骤5：【POD1】broker把MSG34封装为一个CK，并返回MSG34给pod6
步骤6：【POD1】服务HANG主，即没有返回返回ACK。
步骤7：【POD2】返回MSG34的ACK,但是此时是被封装为一个ACK消息存储到revive-TOPIC中。
步骤8和9：定时任务PopReviveService定期会处理ACK的消息，和CK集合做合并，从而提交位点。此时MSG12的位点并没有确认，也不知道是否成功消费。
步骤10：定时任务PopReviveService#reviveMsgFromCk会把未确认的消息重放到target-RETRY-TOPIC中，等待消费者概率触发重新消费。

总结

失败的需要落盘，5.x版本是存到一个RETRY-TOPIC上，如果我们使用4.0版本可以落MySQL。
落盘失败的消息怎么能再次被消费？5.x版本使得不同的消费者的入口逻辑是一样的，所以别的消费者是有概率获得这条消息的。如果我们使用4.0版本，则可以@ScheduleX注解，任何一台机器都有概率获取。注意消费的幂等性。

参考

https://blog.csdn.net/qq_32099833/article/details/135370847