RocketMQ为何敢说自己高可用嘞-消费者端

2,112 阅读3分钟

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第6天,点击查看活动详情

消费模式

集群消费模式

在Rocket集群消费模式下,同一个主题(Topic)下的消息,对于相同的消费者组的消费者而言是一种集群模式,即同一个消费者组内的所有消费者均分消息并消费。 需要集群消费模式的话,只需设置MessageModel为CLUSTERING模式即可。或者可以不设置,默认就是集群模式。

其实集群消费模式适用于大部分场景,并且消费者的消费进度是保存在Broker端的,所以就算消费者掉线,消费进度也不会出错。

consumer.setMessageModel(MessageModel.CLUSTERING);

广播消费模式

广播消费模式下,同一个消费者组内不同的消费者均会收到全量的消息。

需要广播消费模式的话,只需设置MessageModel为BROADCASTING模式即可。

广播消费适合需要将消息通知给集群内每个消费者的场景,比如刷新每个消费者的缓存等操作。

consumer.setMessageModel(MessageModel.BROADCASTING);

可靠消费

重试-死信机制

若是由于各种意外导致消息消费失败,那么这条消息会被自动保存到重试Topic中,重试Topic格式为%RETRY%group name,这个重试Topic会被自动订阅

若是进入到了重试消费者组,有16次重试机会,如下所示

重试次数与上次重试间隔时间重试次数与上次重试间隔时间
110秒97分钟
230秒108分钟
31分钟119分钟
42分钟1210分钟
53分钟1320分钟
64分钟1430分钟
75分钟151小时
86分钟162小时

若是正常消费或者重试消费中有一次消费成功,就算消费成功。

这里还有一个死信Topic,名字格式为%DLQ%group name,如果正常消费一次失败或者重试16次失败,那么消息会被保存到死信Topic中,进入到死信Topic的消息不能自动被再次消费。可以在RocketMQ控制台选择重发死信消息,让消费者重新消费一次。

Rebalance机制

Rebalance机制,用于发生Broker掉线,Topic扩容和缩容,消费者扩容和缩容等变化的时候,自动感知并调整自身的消费,以避免消息没有被消费。

Rebalance(再均衡)机制指的是:将一个Topic下的多个队列(或称之为分区),在同一个消费者组(consumer group)下的多个消费者实例(consumer instance)之间进行重新分配.

当Broker或者Consumer的数量发生变化时,会触发doRebalance()操作:

第一步

查找当前clientId对应的全部消费者组,全部执行一次Rebalance

第二步

判断Rebalance开关,如果没有暂停,就调用对应的RebalancePushImpl.rebalance()方法

第三步

RebalancePushImpl.rebalance()方法中,获取当前所有订阅的Topic循环对每个Topic进行Rebalance,全部执行完之后,将不属于当前消费者的队列删除。

第四步

Topic重新分配,这个是Rebalance的核心逻辑,根据是集群消费还是广播消费执行各自的逻辑。

Topic重新分配,以集群消费为例:

  1. 获取当前Topic的所有MessageQueue和当前Topic的所有消费者,只有当两者都不为空才会执行Rebalance。
  2. 将所有的MessageQueue和消费者客户端进行排序
  3. 根据当前的队列分配策略执行Queue分配
  4. 更新ProcessQueue,ProcessQueue是保存Pull消息的本地容器。
  5. 执行messgeQueueChange()方法,如果有MessageQueue订阅发生变化,则更新本地订阅关系版本。

这里只是简单讲了一下,之后会专门开一篇文章结合源码讲解这个Rebalance.