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

Posted 2022-03-12 周杰伦本人

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略高。