RocketMQ 高可用设计之消息重试机制

RocketMQ 高可用设计之消息重试机制

重试队列：在 Consumer 由于业务异常导致消费消息失败时，将消费失败的消息重新发送给 Broker 保存在重试队列中，这样不影响整体消费进度又防止消费失败的消息丢失。重试队列的消息保存在一个单独的 Topic 中，不在原消息的 Topic 中，Consumer 自动订阅该 Topic。重试队列的 Topic 名称格式为“%RETRY%+consumerGroup”，每个业务 Topic 都会有多个 ConsumerGroup，每个 ConsumerGroup 消费失败的情况不一样，因此各对应一个重试队列的 Topic

死信队列：由于业务问题等原因，导致 Consumer 对部分消息长时间消费重试一直失败，为了保证这部分消息不丢失，同时不能阻塞其他能重试消费成功的消息，超过最大重试消费次数之后的消息会进入死信队列。消息进入死信队列之后不再自动消费，需要人工干预。死信队列也存在单点 Topic 中，名称为“%DLQ&+consumerGroup”

RocketMQ 消息重试机制：采用时间衰减的方式，使用了自身定时消费的能力。首次在 10 秒后重试消费，如果消费成功则不再重试，如果消费失败则继续重试消费，第二次载 30s 后重试消费，以此类推，每次重试的间隔时间都会加长，直到超过最大重试次数（默认 16 次），则写入死信队列不再重试，重试消费过程中的间隔时间使用了定时消费，重试的消息数据并非直接写入重试队列，而是先写入定时消费队列，再通过定时消息的功能转发到重试队列。

RocketMQ 支持定时消息：延迟消息是指消息发送之后，等待指定的延迟时间后再进行消费。除了支持消息重试机制，延迟消息也适用于一些处理异步任务

RocketMQ 不支持任意时间精确的延迟消息，仅支持 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。

ACK 确认

广播模式的消费进度保存在客户端本地，集群模式的消费进度保存在 Broker 上。集群模式中 RocketMQ 中采用 ACK 机制确保消息一定被消费。在消息投递过程中，不是消息从 Broker 发送到 Consumer 就算消费成功了，需要 Consumer 明确给 Broker 返回消费成功状态才算。如果从 Broker 发送到 Consumer 后，已经完成业务处理，但给 Broker 返回消费成功状态之前，Consumer 发生宕机或断电断网，Broker 未收到反馈，则不会保存消费进度。Consumer 重启后消息会重新投递，此时会出现重复消费，需要消费幂等性保证。

Broker 集群部署

RocketMQ 中 Broker 有四种不同的集群搭建方式：

单 Master 模式：仅部署一台 Broker 机器，一旦 Broke 重启或宕机，导致整个服务不可用。

多 Master 模式：集群全部都是 Master 机器，没有 Slave 机器，属于不配置主从复制的场景

• 优点：配置简单，单个 Master 宕机或重启对应用无影响

• 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息的实时性会受到影响。

异步复制的多 Master 多 Slave：每个 Master 配置一个 Slave，有多对 Master-Slave，主从复制采用异步复制方式，主备有短暂消息延迟（毫秒级）

• 优点：即使磁盘损坏，消息丢失非常少，消息实时性不会受影响

• 缺点：Master 宕机且磁盘损坏的情况下可能会丢失少量消息。

同步复制的多 Master 多 Slave 模式：每个 Master 复制一个 Slave，有多对 Master-Slave，主从复制采用同步复制方式，即只有主备都写成功，才向应用返回成功。推荐异步刷盘+同步复制的 Master 多 Slave 模式：

• 优点：数据和服务无单点故障，在 Master 宕机的情况下，消息无延迟，服务可用性和数据可用性都非常高

• 缺点：性能比异步复制模式略低，发送单个消息的 RT 略高。