RabbitMq分布式事务解决方案第一篇

前言

微服务架构下,相比单机事务,一个比较复杂的地方在于,在分布式环境下,面对的是分布式事务,分布式事务整体来说无法严格遵循传统的ACID4个特性,而只能根据系统的业务指标,通常满足可用性,和最终一致性,这也是不少互联网产品的实践结果的选择

分布式事务一章中,探讨了有关常用分布式事务的几种解决方案,可以依据自己所在项目的特点,有选择的使用,比如对数据的一致性要求严格而对并发数可容忍的,可以考虑使用seata解决,对并发要求高,同时对数据一致性的要求也比较高的,可以考虑使用rocketMq事务消息

下面要介绍的是使用rabbitMq如何解决分布式事务

在分布式事务解决方案中,提到了一种思路,叫做柔性事务解决方案,柔性在这里的含义可以理解为尽最大可能满足数据的最终一致性,它结合了“最大努力通知”模型的精髓,同时由于消息中间件的高并发能力,在某些场景下,可以大提升分布式系统的整体效能

rocketMq事务解决方案中,使用rocketMq提供的事务消息,是可以达到预期的目的的,但研究过rocketMq源码或者对其框架比较熟悉的同学应该知道,事务消息在rocketMq中是比较耗费性能的一种

为什么采用rabbitMq

关于rabbitMq的介绍,这里不再多做介绍,有兴趣的同学可以参阅rabitmq专栏进行学习或者上网查阅相关资料

总结来说,rabbitMq提供了相当丰富和完善的消息处理机制和基于消息的各自回调事件,用于满足开发者在消息传递过程中方便的拿到消息的各种状态,从而根据消息的各种状态指导应用上下文的业务走向

下图是一张rabbitMq在分布式环境下,从应用A发消息到应用B接收消息时,消息在rabbitMq内部的一个传递的过程
RabbitMq分布式事务解决方案第一篇_第1张图片

一个正常的消息流程是,应用A发消息到rabbitMq,mq接收到消息之后,如果应用A发送至mq成功,应用A内部可以通过confirmCallBack的回调函数掌握消息是否投递成功,MQ接收到消息之后,会按照预定好的规则,将这条消息分发到指定的exchange,exchange再根据routingKey将消息投递到与之绑定的queue中

如果MQ在将消息发出去的时候没有找到与之绑定的队列,比如queue没有创建,就会将消息退回,这种情况下,对于应用A来说,可以通过returnCallBack的回调函数掌握退回消息的情况

如果MQ成功将消息通过exchange投递到指定的queue中,且被应用B正常消费,且应用B确认消费成功后,MQ就会删掉queue中的这条消息

以上描述的是一个正常的消息消费过程,而在实际开发过程中,情况可能会更加复杂,比如应用A发消息至MQ时网络问题,或者MQ服务器宕机了,或者应用B消费消息时候宕机,或者没有及时确认等等

如何与业务应用结合

既然要使用rabbitMq作为分布式事务的解决方案,我们可能需要考虑下面几个问题

  • MQ在业务应用中扮演什么角色
  • 是否需要存储消息数据
  • MQ如何保证业务应用的事务最终一致性
  • 要使用到MQ的哪些关键特性

如果将rabbitMq作为一个应用层框架级的中间件进行使用,上面几个问题是必须要考虑的,小编从自身业务中的应用以及思考总结,可以充分利用rabbitMq提供的各种消息回调机制,封装并完善消息从发送、接收、确认等过程,即从框架层面的封装上思考如何将rabbitMq运用到自己的业务中

结合上面的消息传递业务流程图,其中几个比较重要的点如下

  • MQ是与本地事务的关系,互相依赖,MQ消息发送失败,本地事务亦失败
  • 事务的传递依赖消息在MQ中的传递,因此MQ消息需要持久化
  • 考虑到在生产中,消息的量级会非常大,消息一旦成功发送到MQ,生产端需要删除消息,生产端通过confirmCallBack回调机制,判定消息是否成功发送至MQ
  • MQ将消息发送至指定应用,未能投递成功,通过ReturnCallback得到消息退回的通知,退回的消息将重新持久化,并通过定时任务尝试多次发送(多次发送仍然无效,消息将进入死信队列,做后续业务处理)
  • 消费端应用消费成功并ACK之后,删除消息

上面的流程图展示了一个消息从投递到成功的完整路径,为了更好的完善我们的逻辑,以及在实际业务场景中预判到的几个失败场景,主要包括生产端应用的发送失败的重试,以及消费端的消费失败重试

发送失败重试

RabbitMq分布式事务解决方案第一篇_第2张图片

在上面的流程中,为了清楚的记录消息从应用到MQ之间的投递状态,即围绕是否成功发送到MQ被MQ接收来展开,其中比较关键的需要一张消息表,利用这个消息表来传递,具体来说,消息表在设计中为了具备较强的灵活性,建议与应用的某个或者某些关键的业务字段结合,方便消息回溯

以上是消息从应用到达MQ过程涉及到几个关键的流程分析

消费失败流程分析

RabbitMq分布式事务解决方案第一篇_第3张图片
消费端的流程和生产端的流程类似,一旦接收到消息之后,首先需要进行消息的持久化,但这里可能存在第一次消费失败的情况,一旦消费失败了,通过本地消息表可以触发再次的消费,消费次数达到预设的阈值时,根据业务的需要,将这些无法消费的消息推送至死信队列,等待后面的业务处理,或者达到最大次数时发送告警通知等

你可能感兴趣的:(技术总结,rabbitmq分布式事务,分布式事务解决方案,rabbitmq解决分布式事务)