消息发送重试和流控机制

本文为您介绍 Apache RocketMQ 的消息发送重试机制和消息流控机制。

背景信息

消息发送重试

Apache RocketMQ的消息发送重试机制主要为您解答如下问题:

  • 部分节点异常是否影响消息发送?

  • 请求重试是否会阻塞业务调用?

  • 请求重试会带来什么不足?

消息流控

Apache RocketMQ 的流控机制主要为您解答如下问题:

  • 系统在什么情况下会触发流控?

  • 触发流控时客户端行为是什么?

  • 应该如何避免触发流控,以及如何应对突发流控?

消息发送重试机制

重试基本概念

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

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

重试触发条件

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

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

  • 网络异常造成连接失败或请求超时。

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

  • 服务端运行慢造成请求超时。

  • 服务端返回失败错误码

    • 系统逻辑错误:因运行逻辑不正确造成的错误。

    • 系统流控错误:因容量超限造成的流控错误。

消息发送重试和流控机制 - 图1备注

对于事务消息,只会进行透明重试(transparent retries),网络超时或异常等场景不会进行重试。

重试流程

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

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

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

重试间隔

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

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

    • INITIAL_BACKOFF: 第一次失败重试前后需等待多久,默认值:1秒。

    • MULTIPLIER :指数退避因子,即退避倍率,默认值:1.6。

    • JITTER :随机抖动因子,默认值:0.2。

    • MAX_BACKOFF :等待间隔时间上限,默认值:120秒

    • MIN_CONNECT_TIMEOUT :最短重试间隔,默认值:20秒。

建议算法如下:

  1. ConnectWithBackoff()
  2. current_backoff = INITIAL_BACKOFF
  3. current_deadline = now() + INITIAL_BACKOFF
  4. while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT))!= SUCCESS)
  5. SleepUntil(current_deadline)
  6. current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
  7. current_deadline = now() + current_backoff + UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)

更多信息,请参见connection-backoff 策略

功能约束

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

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

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

消息流控机制

消息流控基本概念

消息流控指的是系统容量或水位过高, Apache RocketMQ 服务端会通过快速失败返回流控错误来避免底层资源承受过高压力。

触发条件

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

  • 存储压力大:参考消费进度管理的原理机制,消费者分组的初始消费位点为当前队列的最大消费位点。若某些场景例如业务上新等需要回溯到指定时刻前开始消费,此时队列的存储压力会瞬间飙升,触发消息流控。

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

流控行为

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

  • reply-code:530

  • reply-text:TOO_MANY_REQUESTS

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

处理建议

  • 如何避免触发消息流控:触发限流的根本原因是系统容量或水位过高,您可以利用可观测性功能监控系统水位容量等,保证底层资源充足,避免触发流控机制。

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