RocketMQ(4.8.0)——消费流程
一、消费者概述
消费者一般指获取消息、转发消息给业务代码处理的一系列代码实现。在RocketMQ中，消费行为是如何进行的呢？
RocketMQ消费者支持订阅发布模式和Queue模式。下面以集群模式消费为例，描述生产、消费是如何进行的，见下图：
基本概念：
消费者组： 一个逻辑概念，在使用消费者时需要指定一个组名。一个消费者组可以订阅多个Topic。
消费者实例：一个消费者组程序部署了多个进程，每个进程都可以称为一个消费者实例。
订阅关系：一个消费者组订阅一个Topic的某一个Tag，这种记录被称为订阅关系。RocketMQ规定消费订阅关系(消费者组名-Topic-Tag)必须一致。一个消费者组中的实例订阅的Topic和Tag必须完全一致，否则就是订阅关系不一致，订阅关系不一致会导致消费消息絮乱。
二、消费模式
RocketMQ 目前支持2种消费模式：
- 集群消费模式
- 广播消费模式
2.1 集群消费模式
在同一个消费者组中的消费实例，是负载均衡（策略可以配置）地消费 Topic 中的消息，假如有一个生产者（producer）发送 120 条消息，其所属的 Topic 有 3 个消费者（Consumer）组，每个消费者组设置为集群消息，分别有 2 个消费者实例，如下图：
Consumer Group 1 的两个实例 127.0.0.1 和 127.0.0.2 分别负载均衡地消费 60 条消息。由此我们可以得出使用负载均衡策略时，每个消费者实例消费消息数=生产消息数/消息者实例数，在本例中是 60=120/2。
目前大部分场景都适合集群消费模式，RocketMQ的消费模式默认是集群消费。比如异步通信、削峰等对消息没有顺序要求的场景都适合集群消费。因为集群消费模式的消费进度是保存在 Broker 端的，所以即使应用崩溃，消费进度也不会出错。
2.2 广播消费模式
广播消费，顾名思义全部的消息都是广播分发，即消费者组中的全部消费者实例将消费整个 Topic 的全部消息。比如，有一个生产者生产了 120 条消息，其所属的 Topic 有3个消费者组，每个消费者组设置为广播消费，分别有两个消费者实例。
Consumer Group 1 中的消费者 127.0.0.1 和消费者 127.0.0.2 分别消费 120 条消息。整个消费者组收到消息 120*2=240 条。由此我们可以得出广播消费时，每个消费者实例的消费消息数=生产者生产的消息数，整个消费者组中所有实例消费消息数=每个消费者实例消费消息数*消费者实例数，本例中是 240==120*2。
广播消费比较适合各个消费者实例都需要通知的场景，比如刷新应用服务器中的缓存，见图：
生产者发一个刷新缓存的广播消息，消费者组如果设置为广播消息，那么每个应用服务中的消费者都可以消费这个消息，也都能刷新缓存。
广播消费的消费进度保存在客户端机器的文件中。如果文件丢失了，那么消费进度就丢失了，可能会导致部分消息没有消费。
三、可靠消费
RocketMQ是一种十分可靠的消息队列中间件，消费侧通过重试—死信机制、Rebalance机制等多种机制保证消费的可靠性。
3.1 重试——死信机制
我们假设有一个场景，在消费消息时由于网络不稳定导致一条消息消费失败。此时是让生产者重新手动发送消息呢，还是自己做数据补偿？RocketMQ告诉你，消费不是一锤子买卖。
横向看，RocketMQ的消费过程分为3个阶段：正常消费、重试消费和死信。在引进了正常Topic、重试队列、死信队列后，消费过程的可靠性提高了。RocketMQ的消费流程如图：
基本概念：
正常 Topic ：正常消费者订阅的 Topic 名字。
重试 Topic ：如果由于各种意外导致消息消费失败，那么该消息会自动被保存到重试 Topic 中，格式为 "%RETRY%消费者组"，在订阅的时候会自动订阅这个重试 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小时 |
死信 Topic ：死信 Topic 名字格式为 "%DLQ%消费者组名"。如果正常消费 1 次失败，重试16次失败，那么消息会被保存到死信 Topic 中，进入死信 Topic 的消息不能被再次消费。RocketMQ认为，如果17次机会都失败了，说明生产者发送消息的格式发生了变化，或者消费服务出现了问题，需要人工介入处理。
3.2 Rebalance机制
Rebalance（重平衡）机制，用于在发生 Broker 掉线、Topic 扩容和缩容、消费者扩容和缩容等变化时，自动感知并调整自身消费，以尽量减少甚至避免消息没有被消费。后面单独说 Rebalance机制。