性能文章>RocketMQ最佳实践之坑?>

RocketMQ最佳实践之坑?原创

343646

你好,我是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,从一点点到亿点点我们下篇见~

 

点赞收藏
yes的练级攻略

公众号【yes的练级攻略】,专注分享后端技术

请先登录,查看4条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
6
4