文章目录
- 背景
- 问题排查
- Consumer负载均衡机制
- 订阅关系的一致
背景
业务团队反馈使用我提供的RocketMQ集群，上游生产的消息，部分消息，消费程序需要等1分钟，甚至几分钟后，才能收到。
问题排查
见怪不怪，大部分的问题，都是和客户端的使用上有关系，根据一番了解，业务方是这样写消费者程序的：
- 消费者使用拉模式；
- 消费者有3个实例；
- 使用了XXL-JOB做任务调度，每分钟执行一次，触发消费者的拉取操作
- XXL-JOB使用的是轮询的调度方式。
到这里，如果了解RocketMQ消费者机制的，应该已经知道问题了，下面是简单的思路总结：
- RocketMQ创建Topic时会有队列数的配置，类似于Kafka的Partition；
- 例如：RocketMQ集群有3个Broker，创建Topic时设置读队列数为16，这个Topic的总的消费队列为48；
- 所有消费者实例会近似平均地去负责这48个队列，也就是说，每隔1分钟，用轮询的方式去执行消费，每次只会消费到topic中1/3的消息，下一次JOB执行，才会继续消费，这中间JOB执行的间隔，就导致了消费的延迟。
下面详细说一下RocketMQ消费者的负载均衡机制。
Consumer负载均衡机制
集群模式下，同一个消费组内的消费者会分担收到的全量消息，这里的分配策略是怎样的？如果扩容消费者是否一定能提升消费能力？
Apache RocketMQ 提供了多种集群模式下的分配策略，包括平均分配策略、机房优先分配策略、一致性hash分配策略等，可以通过如下代码进行设置相应负载均衡策略。
consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueAveragely());
默认的分配策略是平均分配，这也是最常见的策略。平均分配策略下消费组内的消费者会按照类似分页的策略均摊消费。
在平均分配的算法下，可以通过增加消费者的数量来提高消费的并行度。比如下图中，通过增加消费者来提高消费能力。
从一个消费者，扩到两个消费者：
从3个扩到4个：
但也不是一味地增加消费者就能提升消费能力的，比如下图中Topic的总队列数小于消费者的数量时，消费者将分配不到队列，即使消费者再多也无法提升消费能力。
在RocketMQ中每个队列都会记录自己的最小位点、最大位点。针对于消费组，还有消费位点的概念，在集群模式下，消费位点是由客户端提给交服务端保存的，在广播模式下，消费位点是由客户端自己保存的。一般情况下消费位点正常更新，不会出现消息重复，但如果消费者发生崩溃或有新的消费者加入群组，就会触发重平衡，重平衡完成后，每个消费者可能会分配到新的队列，而不是之前处理的队列。为了能继续之前的工作，消费者需要读取每个队列最后一次的提交的消费位点，然后从消费位点处继续拉取消息。但在实际执行过程中，由于客户端提交给服务端的消费位点并不是实时的，所以重平衡就可能会导致消息少量重复。
订阅关系的一致
再补充一点，也是很多业务方会忽略的一个问题，很多用户为了方便，或者不经意间，会用一个消费组去消费多个topic，这样也是会存在问题的。
同一个消费者组（Group ID相同）下所有Consumer实例所订阅的Topic与Tag及对消息的处理逻辑必须完全一致。否则，消息消费的逻辑就会混乱，甚至导致消息丢失。
