消费者概述
消费者一般指获取消息、转发消息给业务代码处理的一系列代码实现。
消费流程
RocketMQ 消费者支持订阅发布模式和 Queue 模式。它在整个 RocketMQ 的生产和消费体系中扮演的角色如下图所示。
- 消费者组:一个逻辑概念,在使用消费者时需要指定一个组名。一个消费者组可以订阅多个 Topic
- 消费者实例:一个消费者组程序部署了多个进程,每个进程都可以称为一个消费者实例
- 订阅关系:一个消费者组订阅一个 Topic 的某一个 Tag,这种记录被称为订阅关系,RocketMQ 规定消费订阅关系(消费者组名-Topice-Tag)必须一致
消费模式
RocketMQ 目前支持集群消费模式和广播消费模式,其中集群消费模式使用最为广泛。
集群消费模式
同一个消费者组中的消费者实例,是负载均衡(可配置)地消费 Topic 中的消息,假如有一个生产者发送了 120 条消息,其所属的 Topic 有3个消费者组,每个消费者组设置为集群消费,分别有2个消费者实例,消费情况如下图所示:
Consumer Group1的两个消费者实例分别负载均衡地消费了60条消息,由此我们可以得出使用负载均衡的消费策略时,每个消费者实例消费消息数=生产消息数/消费者实例数
。
目前大部分场景都适合集群消费模式,RocketMQ 的消费模式默认是集群消费。比如异步通信、削峰等对消息没有顺序要求的场景都适合集群消费。因为集群模式的消费进度是保存在 Broker 端的,所以即使应用崩溃,消费进度也不会出错。
广播消费模式
广播消费,顾名思义全部的消息都是广播分发,即消费者组中的全部消费者实例将消费整个Topic的全部消息。比如,有一个生产者生产者120条消息,其所属的 Topic 有3个消费者组,每个消费者组设置为广播消费,分别有两个消费者实例,消费情况如下所示:
Consumer Group1中的两个消费者实例分别消费120条消息。整个消费者组收到120*2条消息。由此我们可以得出广播消费时,每个消费者实例的消费消息数=生产者生产的消息数,整个消费者组中所有实例消费消息数=每个消费者实例消费消息数*消费者实例数
。
广播消费比较适合各个消费者实例都需要通知的场景,比如刷新应用服务器中的缓存。但是,广播消息的消费进度保存在客户端机器的文件中,如果文件弄丢了,那么消费进度就丢失了,可能会导致部分消息没有消费。
可靠消费
RocketMQ 消费侧通过重试-死信队列、Rebalance 机制等多种机制保证消费的可靠性。
重试-死信机制
RocketMQ 的消费过程可以分为3个阶段:正常消费、重试消费和死信。RocketMQ 的消费流程如下图所示。
- 正常Topic:正常消费者订阅的Topic名字;
- 重试Topic:如果由于各种意外导致消费失败,那么该消息会自动被保存到重试Topic中,格式为"%RETRY%消费者组",在订阅的时候会自动订阅这个重试Topic。
- 死信Topic:死信Topic的名字格式为"%DLQ%消费者组名"。进入死信Topic的消息不能被再次被消费。
进入死信Topic前,消息有16次重试机会,每次都会按照一定的时间间隔进行重试,如下表所示。
第几次重试 | 与上次重试的间隔时间 | 第几次重试 | 与上次重试的间隔时间 |
1 | 10秒 | 9 | 7分钟 |
2 | 30秒 | 10 | 8分钟 |
3 | 1分钟 | 11 | 9分钟 |
4 | 2分钟 | 12 | 10分钟 |
5 | 3分钟 | 13 | 20分钟 |
6 | 4分钟 | 14 | 30分钟 |
7 | 5分钟 | 15 | 1小时 | 8 | 6分钟 | 16 | 2小时 |
Rebalance 机制
Rebalance(重平衡)机制,用于在发生 Broker 掉线、Topic 扩容和缩容、消费者扩容和缩容等变化时,自动感知并调整自身消费,以尽量减少甚至避免消息没有被消费。
版权属于:带翅膀的猫
本文链接:https://www.chengpengper.cn/archives/169/
转载时须注明出处及本声明