RocketMQ的消费流程及最佳实践

消费者概述

      消费者一般指获取消息、转发消息给业务代码处理的一系列代码实现。

消费流程

      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次重试机会，每次都会按照一定的时间间隔进行重试，如下表所示。

Rebalance 机制

      Rebalance（重平衡）机制，用于在发生 Broker 掉线、Topic 扩容和缩容、消费者扩容和缩容等变化时，自动感知并调整自身消费，以尽量减少甚至避免消息没有被消费。