最终一致性 可靠消息投递的方案

杭州-后端-梁桂钊] 分布式事务可以分成强一致性和最终一致性两种方案。对于强一致性,可以了解下「二阶段提交协议」、「三阶段提交协议」。但是,强一致性存在一些问题,因此生产环境中更多的是利用最终一致性的方案。对于,TCC 和 saga 可以查阅一下相关材料。这里,想分享一下可靠消息投递的方案。

 

 

image.png

 

消息队列发生消息后,可能消费者宕机而无法消费。绝大多数消息中间件对于这种情况,例如 RabbitMQ、RocketMQ 等引入了 ACK 机制。注意的是,默认的情况下,采用自动应答,这种方式中消息队列会发送消息后立即从消息队列中删除该消息。所以,为了确保消息的可靠投递,我们通过手动 ACK 方式,如果消费者因宕机等原因没有发送 ACK,消息队列会将消息重新发送,保证消息的可靠性。从业务服务处理完相关业务后通过手动 ACK 通知消息队列,消息队列才从消息队列中删除该持久化消息。那么,消息队列如果一直重试失败而无法投递,就会出现消息主动丢弃的情况,我们需要如何解决呢?主业务服务将要发送的消息持久化到本地数据库。从业务服务消费成功后,它也会向消息队列发送一个通知消息,此时它是一个消息的生产者。消费者接收到消息后,最终把本地的持久化消息标志状态为“完成”状态。说到这里,我们应该可以理解到使用“正反向消息机制”确保了消息队列可靠事件投递。当然,补偿机制也是必不可少的。定时任务会从数据库扫描在一定时间内未完成的消息并重新投递

 

参考石杉的架构笔记

展开阅读全文

没有更多推荐了,返回首页