RocketMQ（四）：功能特性

1 消息发送重试和流控机制

        本节介绍Apache RocketMQ的消息发送重试机制和消息流控机制

1.1 消息发送重试机制

1.1.1 重试基本概念

        Apache RocketMQ 客户端连接服务端发起消息发送请求时，可能会因为网络故障、服务异常等原因导致调用失败。为保证消息的可靠性，Apache RocketMQ在客户端SDK中内置请求重试逻辑，尝试通过重试发送达到最终调用成功的效果。

        同步发送和异步发送模式均支持消息发送重试

        重试触发条件

        触发消息发送重试机制的条件如下：

        1、客户端消息发送请求调用失败或请求超时

        2、网络异常造成连接失败或请求超时

        3、服务端节点处于重启或下线等状态造成连接失败

        4、服务端运行慢造成请求超时

        5、服务端返回失败错误码

                （1）系统逻辑错误：因运行逻辑不正确造成的错误。

                （2）系统流控错误：因容量超限造成的流控错误。

1.1.2 重试流程

        生产者在初始化时设置消息发送最大重试次数，当出现上述触发条件的场景时，生产者客户端会按照设置的重试次数一直重试发送消息，直到消息发送成功或达到最大重试次数重试结束，并在最后一次重试失败后返回调用错误响应。

        同步发送：调用线程会一直阻塞，直到某次重试成功或最终重试失败，抛出错误码和异常。

        异步发送：调用线程不会阻塞，但调用结果会通过异常事件或成功事件返回。

1.1.3 重试间隔

        除服务端返回系统流控错误场景，其他触发条件触发重试后，均会立即进行重试，无等待间隔。

        若由于服务端返回流控错误触发重试，系统会按照指数退避策略进行延迟重试。指数退避算法通过以下参数控制重试行为：

        1、INITIAL_BACKOFF：第一次失败重试前后需要等待多久，默认值：1秒。

        2、MULTIPLIER：指数退避因子，即退避倍率，默认值：1.6.

        3、JITTER：随机抖动因子，默认值：0.2

        4、MAX_BACKOFF：等待间隔时间上限，默认值：120秒。

        5、MIN_CONNECT_TIMEOUT：最短重试时间，默认值：20秒。

1.1.4 功能约束

        1、链路耗时阻塞评估：从上述重试机制可以看出，在重试流程中生产者仅能控制最大重试次数。若由于系统异常触发了SDK内置的重试逻辑，则服务端需要等待最终重试结果，可能会导致消息发送请求链路被阻塞。对于某些实时调用类场景，需要合理评估调用请求的超时时间以及最大重试次数，避免影响全链路的耗时。        

        2、最终异常兜底：Apache RocketMQ 客户端内置的发送请求重试机制并不能保证消息发送一定成功。当最终重试仍然失败时，业务方调用需要捕获异常，并做好冗余保护处理，避免消息发送结果不一致。

        3、消息重复问题：因远程调用的不确定性，当Apache RocketMQ客户端因请求超时触发消发送重试流程，此时客户端无法感知服务端的处理结果，客户端进行的消息发送重试可能会产生消息重复问题，业务逻辑需要自行处理消息重复问题。

1.2 消息流控机制

1.2.1 消息流控基本概念

        消息流控指的是系统容量使用率超过阈值时，Apache RocketMQ服务端会通过快速返回失败流控错误来避免底层资源承受过高压力。

1.2.2 触发条件

        Apache RocketMQ的消息流控触发条件如下：

        1、存储压力过大：消费者分组的初始消费位点为当前队列的最大消费位点。若某些场景如业务上新等需要回溯到指定时刻前开始消费，此时队列的存储压力会瞬间飙升，触发消息流控。

        2、服务端请求任务排队溢出：若消费者消费能力不足，导致队列中有大量堆积消息，当堆积消息超过一定数量后会触发消息流控，减少下游消费系统压力。

1.2.3 流控行为

        当系统触发消息发送流控时，客户端会收到系统限流错误和异常，错误码信息如下：

        1、reply-code：530

        2、reply-text：TOO_MANY_REQUESTS

        客户端收到系统流控错误码后，会根据指数退避策略进行消息发送重试。

1.2.4 处理建议

        如何避免触发消息流控：触发限流的根本原因是系统容量使用率到达阈值，可以利用可观测性功能监控系统的使用率，保证底层资源 充足，避免触发流控机制。

        突发消息流控处理：如果因为突发原因触发消息流控，且客户端内置的重试流程执行失败，则建议业务方将请求调用临时替换到其他系统进行应急处理。

2 消费者分类

Apache RocketMQ 支持PushConsumer、SimpleConsumer、PullConsumer三种类型的消费者，本节分别从使用方式、实现原理、可靠性和使用场景分别介绍这三种类型的消费者。

2.1 背景信息

        Apache RocketMQ 面向不同的业务场景提供了不同消费者类型，每种消费者类型的集成方式和控制方式都不一样。了解如下问题，可以选择更匹配业务场景的消费者类型。

        如何实现并发消费：消费者如何使用并发的多线程机制处理消息，以此提高消息处理效率？

        如何实现同步、异步消息处理：对于不同的集成场景，消费者获取消息后可能会将消息异步分发到业务逻辑中处理，此时，消息异步化处理如何实现？

        如何实现消息可靠处理：消费者处理消息时如何返回响应结果？如何在消息异常情况下进行重试，保证消息的可靠处理？

2.2 功能描述

        如上图所示，Apache RocketMQ 的消费者处理消息时主要经过以下阶段：消息获取——>消息处理——>消费状态提交。

        针对以上几个阶段，Apache RocketMQ提供了不同的消费者类型：PushConsumer、SimpleConsumer、PullConsumer。具体差异如下：

【注意】在实际使用场景中，PullConsumer仅推荐在流处理框架中集成使用，大多数消息收发场景使用PushConsumer和SimpleConsumer就可以满足。如果业务场景发生变更，或当前使用的消费者类型不适合当前业务，可以选择在PushConsumer和SimpleConsumer之间变更消费者类型。变更消费者类型不影响当前 Apache RocketMQ资源的使用和业务处理。

【危险】生产环境中相同的ConsumerGroup下严禁混用PullConsumer和其他两种消费者，否则会导致消息消费异常。

对比项	PushConsumer	SimpleConsumer	PullConsumer
接口方式	使用监听器回调接口返回消费 结果，消费者仅允许在监听器 范围内处理消费逻辑	业务方自行实现消息 处理，并主动调用接口 返回消费结果。	业务方自动按队列拉取 消息，并可选择性地提交 消费结果。
消费并发 度管理	由S