RocketMQ 最佳实践之坑

最新推荐文章于 2025-12-28 16:49:38 发布

转载最新推荐文章于 2025-12-28 16:49:38 发布 · 246 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247573670&idx=2&sn=0f3b7915744d0418144aac8fd51359d1&chksm=fa4bdf17cd3c56012b7107b2ccad12ea636e5b831c849cec11962acd8825f6407b86d2f9d9b5&scene=126&sessionid=0

文章标签：

#java-rocketmq #rocketmq #java #开发语言

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

来源：yes的练级攻略

前不久踩了个坑，而这个坑跟 RocketMQ 推荐的一个最佳实践有关。

看下我从官网的截图，官方推荐一个应用尽可能只用一个 topic，然后用 tags 来标识子类型。

从订单角度来看，可以用一个 Topic-Order，然后再用不同的 tag 来区分这是 3C 类的订单，还是母婴类的订单等，然后下游应用根据不同的需求过滤不同的 tag。

这样的实现方式从业务上来看关系更清晰（有点树状的感觉），但是在实践上有点问题。

问题和起因

一般而言，生产上同一个服务至少会部署两台机器，不仅仅是为了负载均衡，也是为了系统的可靠性，当一台机器意外挂了，另一台可以扛起大旗。

我们在发服务的时候，都是分批发布。

这是为了验证新功能的正确性，不让其一次性影响所有实例，我们会先发布一批，然后观察下日志，确保无误后继续发布后续几台机器。

而这个操作再结合 RocketMQ 一个 Topic 多 tag 就会出现订阅消息不一致的情况，导致丢消息。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/

原理分析

我们借用官网的图来分析一下。

一般我们都用集群模式，以下描述默认使用集群模式

从使用层来看，发送和消费消息给我们最直观的感受如下：

生产者往一个 Topic 发送消息，消费者订阅了这个 Topic 就能消费到这个消息。

而实际上在 RocketMQ 中有队列的概念：

也就是生产者往一个 Topic 发送消息时，消息会被分到不同的队列中。

而属于同一个消费组的消费者们会平分消费这些队列，从上图可以看到 Topic A 分了三个队列，分别是 MessageQueue 0、1、2。

而消费组 ConsumerGroupA 中的 Consumer1 仅消费 MessageQueue0 和 MessageQueue1 这两个队列中的消息，而 Consumer2 仅消费 MessageQueue2。

这样划分后，Consumer1 是无法消费到 MessageQueue2 中的消息的。

看到可能有人会说，这跟 tag 有什么关系吗？没错，问题就在这个分割跟 tag 没关系！

在默认情况下生产者发送消息是以轮询队列的方式发送的。

比如现在 Producer A 要发送 TopicA-tag1、TopicA-tag2、TopicA-tag3 这三条数据，轮询发送后，MessageQueue 0、1、2 分别存储了这 3 条消息。

假设同样订阅了 TopicA，但是 Consumer 1订阅的 tag 是 tag1和 tag3，而 Consumer 2 订阅的是 tag1、tag2，那么问题就来了。

按轮询的顺序 Consumer 1 要消费的 tag3 被投递到 MessageQueue2 这个队列中，而 Consumer 1 又无法消费 MessageQueue2 中的消息，Consumer 2 能消费 MessageQueue2 中的消息，但偏偏它又不要 tag3 的消息。这样一来 tag3 的这条消息就丢了，问题就出现了。

所以，在实践中，我们要求同一个消费组的消费者的订阅关系要保持一致。

也就是 Conusmer1 和 Conusmer2 需要订阅一样的 Topic、一样的 tag，这样消息才不会丢失。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/

再回到问题

现在我们已经知道订阅关系一致的重要性，但是有时候不得已就会“明知故犯”。

假设我们订单服务线上一共部署了 5 台，这 5 台机器属于同一个消费组，因此它们负载均衡消费有关订单的消息，如 Topic-Order。

这 5 台机器部署的都是同一套代码，它们都订阅了 Topic-Order，且 tag 是 A、B、C 三个。

这次发版需要订单服务新增消费 Topic-Order 下的 tag D 消息，由于分批部署，所以先部署了 1 台机器观察。

而此时线上就出现了订阅关系不一致的情况！5台机器，有 1 台订阅了 Topic-Order tag A、B、C、D，而其他 4 台订阅了 Topic-Order tag A、B、C。

这段时间内就出现了上述所说的丢消息的情况，如果有 Topic-Order tagD 的消息产生，那么就有可能会丢了。

明知有错，不想犯，却犯了！

针对这个场景，我暂时没啥思路，不知道业界是否有什么方式可以优雅的处理这个问题？欢迎各位留言指导或探讨！

然后留个坑，如果一台机器订阅的是 tagA||tagB，而另一台订阅的是 tagB||tagA，这样算订阅消息一致吗？

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）