首先,造成这个问题的 BUG RocketMQ 官方已经在 3月16号这个提交中修复了,这里只是探讨一下在修复之前造成问题的具体细节,更多的上下文可以参考我之前写的 《RocketMQ Consumer 启动时都干了些啥?》 ,这篇文章讲解了 RocketMQ 的 Consumer 启动之后都做了哪些操作,对理解本次要讲解的 BUG 有一定的帮助。

其中讲到了:


消息堆积

重复消费自不必说,你 ClientID 都相同了。本篇着重聊聊为什么会消息堆积

文章中讲到,初始化 Consumer 时,会初始化 Rebalance 的策略。你可以大致将 Rebalance 策略理解为如何将一个 Topic 下的 m 个 MessageQueue 分配给一个 ConsumerGroup 下的 n 个 Consumer 实例的策略,看着有些绕,其实就长这样:


rebalance策略

而从 Consumer 初始化的源码中可以看出,默认情况下 Consumer 采取的 Rebalance 策略是 AllocateMessageQueueAverage()


默认的 Rebalance 策略

默认的策略很好理解,将 MessageQueue 平均的分配给 Consumer。举个例子,假设有 8 个 MessageQueue,2 个 Consumer,那么每个 Consumer 就会被分配到 4 个 MessageQueue。

那如果分配不均匀怎么办?例如只有 7 个 MessageQueue,但是 Consumer 仍然是 2 个。此时 RocketMQ 会将多出来的部分,对已经排好序的 Consumer 再做平均分配,一个一个分发给 Consumer,直到分发完。例如刚刚说的 7 个 MessageQueue 和 2 个 ConsumerGroup 这种 case,排在第一个的 Consumer 就会被分配到 4 个 MessageQueue,而第二个会被分配到 3 个 MessageQueue。

大家可以先理解一下 AllocateMessageQueueAveragely 的实现,作为默认的 Rebalance 的策略,其实现位于这里:


默认策略的实现位置

接下来我们看看,AllocateMessageQueueAveragely 内部具体都做了哪些事情。

其核心其实就是实现的 AllocateMessageQueueStrategy 接口中的 allocate 方法。实际上,RocketMQ 对该接口总共有 5 种实现:

  • AllocateMachineRoomNearby
  • AllocateMessageQueueAveragely
  • AllocateMessageQueueAveragelyByCircle
  • AllocateMessageQueueByConfig
  • AllocateMessageQueueByMachineRoom
  • AllocateMessageQueueConsistentHash

其默认的 AllocateMessageQueueAveragely 只是其中的一种实现而已,那执行 allocate 它需要什么参数呢?


入参

需要以下四个:

  • ConsumerGroup 消费者组的名字
  • currentCID 当前消费者的 clientID
  • mqAll 当前 ConsumerGroup 所消费的 Topic 下的所有的 MessageQueue
  • cidAll 当前 ConsumerGroup 下所有消费者的 ClientID

实际上是将某个 Topic 下的所有 MessageQueue 分配给属于同一个消费者的所有消费者实例,粒度是 By Topic 的。

所以到这里剩下的事情就很简单了,无非就是怎么样把这一堆 MessageQueue 分配给这一堆 Consumer。这个怎么样,就对应了 AllocateMessageQueueStrategy 的不同实现。

接下来我们就来看看 AllocateMessageQueueAveragely 是如何对 MessageQueue 进行分配的,之前讲源码我一般都会一步一步的来,结合源码跟图,但是这个源码太短了,我就直接先给出来吧。

public List<MessageQueue> allocate(String consumerGroup, String currentCID, List<MessageQueue> mqAll, List<String> cidAll) {
  if (currentCID == null || currentCID.length() < 1) {
    throw new IllegalArgumentException("currentCID is empty");
  }
  if (mqAll == null || mqAll.isEmpty()) {
    throw new IllegalArgumentException("mqAll is null or mqAll empty");
  }
  if (cidAll == null || cidAll.isEmpty()) {
    throw new IllegalArgumentException("cidAll is null or cidAll empty");
  }

  List<MessageQueue> result = new ArrayList<MessageQueue>();

  // 判断一下当前的客户端是否在 cidAll 的集合当中
  if (!cidAll.contains(currentCID)) {
    log.info("[BUG] ConsumerGroup: {} The consumerId: {} not in cidAll: {}",
             consumerGroup,
             currentCID,
             cidAll);
    return result;
  }

  // 拿到当前消费者在所有的消费者实例数组中的位置
  int index = cidAll.indexOf(currentCID);
  // 用 messageQueue 的数量 对 消费者实例的数量取余数, 这个实际上就把不够均匀分的 MessageQueue 的数量算出来了
  // 举个例子, 12 个 MessageQueue, 有 5 个 Consumer, 12 % 5 = 2 
  int mod = mqAll.size() % cidAll.size();
  int averageSize =
    mqAll.size() <= cidAll.size() ? 1 : (mod > 0 && index < mod ? mqAll.size() / cidAll.size() + 1 : mqAll.size() / cidAll.size());
  int startIndex = (mod > 0 && index < mod) ? index * averageSize : index * averageSize + mod;
  int range = Math.min(averageSize, mqAll.size() - startIndex);
  for (int i = 0; i < range; i++) {
    result.add(mqAll.get((startIndex + i) % mqAll.size()));
  }
  return result;
}

其实前半部分都是些常规的 check,可以忽略不看,从这里:

int index = cidAll.indexOf(currentCID);

开始,才是核心逻辑。为了避免逻辑混乱,还是假设有 12 个 MessageQueue,5 个 Consumer,同时假设 index=0

那么 mod 的值就为 12 % 5 = 2 了。

averageSize 的值,稍微有点绕。如果 MessageQueue 的数量比消费者的数量还少,那么就为 1 ;否则,就走这一堆逻辑(mod > 0 && index < mod ? mqAll.size() / cidAll.size() + 1 : mqAll.size() / cidAll.size())。我们 index 是 0,而 mod 是 2,index < mod 则是成立的,那么最终 averageSize 的值就为 12 / 5 + 1 = 3

接下来是 startIndex,由于这个三元运算符的条件是成立的,所以其值为 0 * 3 ,就为 0

看了一大堆逻辑,是不是已经晕了?直接举实例:

12 个 Message Queue

5 个 Consumer 实例

按照上面的分法:

排在第 1 的消费者 分到 3 个

排在第 2 的消费者 分到 3 个

排在第 3 的消费者 分到 2 个

排在第 4 的消费者 分到 2 个

排在第 5 的消费者 分到 2 个


具体分配流程

所以,你可以大致认为:

先“均分”,12 / 5 取整为 2。然后“均分”完之后还剩下 2 个,那么就从上往下,挨个再分配,这样第 1、第 2 个消费者就会被多分到 1 个。

所以如果有 13 个 MessageQueue,5 个 Consumer,那么第 1、第 2、第 3 就会被分配 3 个。

但并不准确,因为分配的 MessageQueue 是一次性的,例如那 3 个 MessageQueue 是一次性获取的,不会先给 2 个,再给 1 个。

而我们开篇提到的 Consumer 的 ClientID 相同,会造成什么?

当然是 index 的值相同,进而造成 modaverageSizestartIndexrange 全部相同。那么最后 result.add(mqAll.get((startIndex + i) % mqAll.size())); 时,本来不同的 Consumer,会取到相同的 MessageQueue(举个例子,Consumer 1 和 Consumer 2 都取到了前 3 个 MessageQueue),从而造成有些 MessageQueue(如果有的话) 没有 Consumer 对其消费,而没有被消费,消息也在不停的投递进来,就会造成消息的大量堆积

当然,现在的新版本从代码上看已经修复这个问题了,这个只是对之前的版本的原因做一个探索。

本篇文章已放到我的 Github github.com/sh-blog 中,欢迎 Star。微信搜索关注【SH的全栈笔记】,回复【队列】获取MQ学习资料,包含基础概念解析和RocketMQ详细的源码解析,持续更新中。

如果你觉得这篇文章对你有帮助,还麻烦点个赞关个注分个享留个言

关于 RocketMQ ClientID 相同引发的消息堆积的问题的更多相关文章

  1. 线上kafka消息堆积,consumer掉线,怎么办?

    线上kafka消息堆积,所有consumer全部掉线,到底怎么回事? 最近处理了一次线上故障,具体故障表现就是kafka某个topic消息堆积,这个topic的相关consumer全部掉线. 整体排查 ...

  2. EQueue - 详细谈一下消息持久化以及消息堆积的设计

    前言 之前写了一篇文章,总体介绍了EQueue.在看这篇文章之前如果还没看过那篇文章,可能会看不懂这篇文章.所以建议没看过的朋友务必先看一下那篇文章中所提到的各种概念,这样才能更好的理解本文所说的内容 ...

  3. 转 Kafka、RabbitMQ、RocketMQ等消息中间件的对比 —— 消息发送性能和优势

    Kafka.RabbitMQ.RocketMQ等消息中间件的对比 —— 消息发送性能和优势 引言 分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦.现在开源的消息中间件有很多,前 ...

  4. RabbitMQ,RocketMQ,Kafka 几种消息队列的对比

    常用的几款消息队列的对比 前言 RabbitMQ 优点 缺点 RocketMQ 优点 缺点 Kafka 优点 缺点 如何选择合适的消息队列 参考 常用的几款消息队列的对比 前言 消息队列的作用: 1. ...

  5. 一次 kafka 消息堆积问题排查

    收到某业务组的小伙伴发来的反馈,具体问题如下: 项目中某 kafka 消息组消费特别慢,有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组. 从服务端日志看到如下信息: 该消费组 ...

  6. RocketMQ系列(三)消息的生产与消费

    前面的章节,我们已经把RocketMQ的环境搭建起来了,是一个两主两从的异步集群.接下来,我们就看看怎么去使用RocketMQ,在使用之前,先要在NameServer中创建Topic,我们知道Rock ...

  7. 2020-04-28:工作中如何解决MQ消息堆积和消息重复的问题?

    福哥答案2020-04-28:此答案来自群员,感谢群员支持. 消息堆积 只能考虑 增多消费者 以及后端其他服务 组件的吞吐能力 别的有办法吗 如果更彻底一点 分撒单个队列里的消息 队列 更分门别类 或 ...

  8. 如何处理RabbitMQ 消息堆积和消息丢失问题

    消息堆积 解决方案: 增加消费者或后台相关组件的吞吐能力 增加消费的多线程处理 根据不同的业务实现不同的丢弃任务,选择不同的策略淘汰任务 默认情况下,RabbitMQ消费者为单线程串行消费,设置并行消 ...

  9. RabbitMQ,RocketMQ,Kafka 事务性,消息丢失和消息重复发送的处理策略

    消息队列常见问题处理 分布式事务 什么是分布式事务 常见的分布式事务解决方案 基于 MQ 实现的分布式事务 本地消息表-最终一致性 MQ事务-最终一致性 RocketMQ中如何处理事务 Kafka中如 ...

随机推荐

  1. 从零入门 Serverless | 一文讲透 Serverless Kubernetes 容器服务

    作者 | 张维(贤维) 阿里云函数计算开发工程师 导读:Serverless Kubernetes 是以容器和 kubernetes 为基础的 Serverless 服务,它提供了一种简单易用.极致弹 ...

  2. 数据应用的变与不变,ShardingSphere 正在影响未来数字体验的建设理念

    近年来关于底层数据库的开源产品越来越多,它们也受到了许多资本的青睐. 伴随着移动互联网催生的数字化场景爆发,云计算.大数据等技术逐渐有了更加广阔的应用场景.在云计算和大数据经过十年的追赶式发展后,不只 ...

  3. poj1248 (线性筛欧拉函数)(原根)

    强烈鸣谢wddwjlss 题目大意:给出一个奇素数,求出他的原根的个数,多组数据. 这里先介绍一些基本性质 阶 设\((a,m)=1\),满足\(a^r \equiv 1 \pmod m\)的最小正整 ...

  4. md5验证文件上传,确保信息传输完整一致

    注:因为是公司项目,仅记录方法和思路以及可公开的代码. 最近在公司的项目中,需要实现一个上传升级包到服务器的功能: 在往服务器发送文件的时候,需要确保 文件从开始发送,到存入服务器磁盘的整个传输的过程 ...

  5. python中dump与dumps实现序列化

    前言 使用中如果我们想把python可识别对象的dict类型的数据通过str类型写入文件或者存入变量中就需要用到dump与dumps 详解 dump 1.新建个dict文件,然后将dict文件存入一个 ...

  6. 解决Mybatis 报错Invalid bound statement (not found)

    解决Mybatis 报错Invalid bound statement (not found) 出现此错误的原因 1.xml文件不存在 2.xml文件和mapper没有映射上 namespace指定映 ...

  7. 【UE4 C++ 基础知识】<9> Interface 接口

    概述 简单的说,接口提供一组公共的方法,不同的对象中继承这些方法后可以有不同的具体实现. 任何使用接口的类都必须实现这些接口. 实现解耦 解决多继承的问题 蓝图使用 使用方法 三种调用方法的区别 调用 ...

  8. 从四个方向分析我们可以从linux学到什么

    我们真正关心的是自身可以从这个生态圈中获得些什么?说得更直白一点就是,我们可以从linux系统上面学到点什么,它对我们个人的成长和发展有哪些积极的因素.个人觉得,完全可以通过下面四个维度并结合自己的兴 ...

  9. IPv6(诞生原因、数据报格式、与IPv4的不同、地址表现形式、基本地址类型、IPv6与IPv4的过渡策略)

    文章转自:https://blog.csdn.net/weixin_43914604/article/details/105297642 学习课程:<2019王道考研计算机网络> 学习目的 ...

  10. 21.7.31 test

    \(NOIP\) 测试 好久没有这种感觉能阿克的冲动了!但还是挂了分 T1 WOJ2608(模拟,拓扑排序) 签到题,直接模拟,有点像拓扑排序. 要给点打标记不然可能被某次操作中弹出多次该点导致WA ...