别裁伪体亲风雅,转益多师是汝师。这篇文章主要讲述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高可用设计之消息重试机制】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宕机且磁盘损坏的情况下可能会丢失少量消息。
- 优点:数据和服务无单点故障,在Master宕机的情况下,消息无延迟,服务可用性和数据可用性都非常高
- 缺点:性能比异步复制模式略低,发送单个消息的RT略高。
推荐阅读
- OpenHarmony基线功能之文件管理
- 14 款命令行常用工具的替代品!
- Hello Blazor(启用深色模式 #yyds干货盘点#)
- PMP相关的十八种图总结及图例
- GDP Streaming RPC 设计
- Spring源码解析之八finishBeanFactoryInitialization方法即初始化单例bean
- redis存储token
- Linux i2c子系统驱动probe
- lsnrctl启动报错,Linux Error: 29: Illegal seek