消息发送重试机制
背景
Apache RocketM Q的消息发送重试机制主要解答如下问题：
- 部分节点异常是否影响消息发送？
- 请求重试是否会阻塞业务调用？
- 请求重试会带来什么不足？
概念
Apache RocketMQ 客户端连接服务端发起消息发送请求时，可能会因为网络故障、服务异常等原因导致调用失败。为保证消息的可靠性， Apache RocketMQ 在客户端SDK中内置请求重试逻辑，尝试通过重试发送达到最终调用成功的效果。
同步发送和异步发送模式均支持消息发送重试。
重试触发条件
触发消息发送重试机制的条件如下：
- 客户端消息发送请求调用失败或请求超时
- 网络异常造成连接失败或请求超时。
- 服务端节点处于重启或下线等状态造成连接失败。
- 服务端运行慢造成请求超时。
- 服务端返回失败错误码
1、 系统逻辑错误：因运行逻辑不正确造成的错误；
2、 系统流控错误：因容量超限造成的流控错误；
注意：对于事务消息，只会进行透明重试（transparent retries），网络超时或异常等场景不会进行重试。
当发生上面场景时，RocketMQ会在一直重试发送消息，直到达到重试最大次数或发送成功并在最后一次重试失败后返回错误码。
重试间隔
- 除服务端返回系统流控错误场景，其他触发条件触发重试后，均会立即进行重试，无等待间隔。
- 若由于服务端返回流控错误触发重试，系统会按照指数退避策略进行延迟重试。指数退避算法通过以下参数控制重试行为：
INITIAL_BACKOFF： 第一次失败重试前后需等待多久，默认值：1秒。
MULTIPLIER ：指数退避因子，即退避倍率，默认值：1.6。
JITTER ：随机抖动因子，默认值：0.2。
MAX_BACKOFF ：等待间隔时间上限，默认值：120秒
MIN_CONNECT_TIMEOUT ：最短重试间隔，默认值：20秒。
建议算法如下：
current_backoff = INITIAL_BACKOFF
current_deadline = now() + INITIAL_BACKOFF
while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT))!= SUCCESS)
SleepUntil(current_deadline)
current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
current_deadline = now() + current_backoff + UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)
除了第一次重试外，之后每次的等待间隔时间等于上一次的间隔时间 * 指数退避因子 和 等待间隔时间上限之中的最大值 ，计算出结果后， 在加上 计算后的结果 * 负的随机抖动因子 到 计算后的结果 * 随机抖动因子 之间的一个随机数。每次的重试时间都不会超过MIN_CONNECT_TIMEOUT。
功能约束
- 链路耗时阻塞评估：从上述重试机制可以看出，在重试流程中生产者仅能控制最大重试次数。若由于系统异常触发了SDK内置的重试逻辑，则服务端需要等待最终重试结果，可能会导致消息发送请求链路被阻塞。对于某些实时调用类场景，您需要合理评估每次调用请求的超时时间以及最大重试次数，避免影响全链路的耗时。
- 最终异常兜底： Apache RocketMQ 客户端内置的发送请求重试机制并不能保证消息发送一定成功。当最终重试仍然失败时，业务方调用需要捕获异常，并做好冗余保护处理，避免消息发送结果不一致。
- 消息重复问题：因远程调用的不确定性，当Apache RocketMQ客户端因请求超时触发消息发送重试流程，此时客户端无法感知服务端的处理结果，客户端进行的消息发送重试可能会产生消息重复问题，业务逻辑需要自行处理消息重复问题。
消息流控机制
背景
Apache RocketMQ 的流控机制主要为您解答如下问题：
- 系统在什么情况下会触发流控？
- 触发流控时客户端行为是什么？
- 应该如何避免触发流控，以及如何应对突发流控？
概念
消息流控指的是系统容量或水位过高， Apache RocketMQ 服务端会通过快速失败返回流控错误来避免底层资源承受过高压力。
触发条件
Apache RocketMQ 的消息流控触发条件如下：
- 存储压力大：参考消费进度管理的原理机制，消费者分组的初始消费位点为当前队列的最大消费位点。若某些场景例如业务上新等需要回溯到指定时刻前开始消费，此时队列的存储压力会瞬间飙升，触发消息流控。
- 服务端请求任务排队溢出：若消费者消费能力不足，导致队列中有大量堆积消息，当堆积消息超过一定数量后会触发消息流控，减少下游消费系统压力。
流控行为
当系统触发消息发送流控时，客户端会收到系统限流错误和异常，错误码信息如下：
- reply-code：530
- reply-text：TOO_MANY_REQUESTS
客户端收到系统流控错误码后，会根据指数退避策略进行消息发送重试。
处理建议
- 如何避免触发消息流控：触发限流的根本原因是系统容量或水位过高，您可以利用可观测性功能监控系统水位容量等，保证底层资源充足，避免触发流控机制。
- 突发消息流控处理：如果因为突发原因触发消息流控，且客户端内置的重试流程执行失败，则建议业务方将请求调用临时替换到其他系统进行应急处理。
流控分类
生产者流控，因为broker处理能力达到瓶颈；消费者流控，因为消费能力达到瓶颈。
生产者流控：
- commitLog文件被锁时间超过osPageCacheBusyTimeOutMills时，参数默认为1000ms，返回流控。
- 如果开启transientStorePoolEnable == true，且broker为异步刷盘的主机，且transientStorePool中资源不足，拒绝当前send请求，返回流控。
- broker每隔10ms检查send请求队列头部请求的等待时间，如果超过waitTimeMillsInSendQueue，默认200ms，拒绝当前send请求，返回流控。
- broker通过拒绝send 请求方式实现流量控制。
注意，生产者流控，不会尝试消息重投。
消费者流控：
- 消费者本地缓存消息数超过pullThresholdForQueue时，默认1000。
- 消费者本地缓存消息大小超过pullThresholdSizeForQueue时，默认100MB。
- 消费者本地缓存消息跨度超过consumeConcurrentlyMaxSpan时，默认2000。
消费者流控的结果是降低拉取频率。