你好，我是yes。

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

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

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

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

问题和起因

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

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

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

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

原理分析

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

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

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

生产者往一个 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，这样消息才不会丢失。

再回到问题

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

假设我们订单服务线上一共部署了 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，这样算订阅消息一致吗？

我是yes，从一点点到亿点点我们下篇见~