前言
关于分布式事务的实现,网上有很多解说,当然这也是面试官的常备面试题。很多朋友在工作中很少接触到分布式事务,认为这个玩意交互太多,没必要。其实我也是这么想的,想要完成一个完整的分布式事务链路,通信开销实在太多。而现如今,微服务架构在行业内大行其道,恨不得所有模块都用上微服务来管理,而不知道自己已经慢慢失去了对软件控制的能力,从数据层面上来说,我们降低了对数据一致性控制的能力。既然市场上很流行,我们还是需要了解一下的,借此,本文介绍一下基于消息中间件的分布式事务的原理。
一、核心思想
了解分布式事务,我们需要抓住几个重点。我总结了一下,可以称之为232法则,即两个角色,三个阶段,两个结果。两个角色是指系统中要存在协调者角色和参与者角色,本文中消息服务器充当协调者,客户端和服务端充当参与者;三个阶段是指分布式事务可以分为预提交阶段,提交阶段,撤销阶段。两个结果是指,参与者中的执行操作要么全部执行,要么全部失败,不能出现部分成功部分失败的情况。
基于消息服务器的分布式事务,我们需要将事务划分成两个部分,一个是客户端与消息服务器交互的提交部分,一个是服务端与消息服务器交互的消费部分。我们需要保证两点:
1、确保客户端处理完业务后一定能成功发送消息。
2、确保服务端一定能够消费掉此消息。
剩下的就看我们如何在交互上完成这两个目标。
二、客户端提交
客户端提交大概可以分为如下几个步骤:
1、A系统预提交消息。
2、消息服务器保存消息,但是处于未提交状态,不能被B系统消费。
3、消息服务器给予响应。
4、A系统处理本地业务。
5、A系统提交事务。
可能会存在的问题:
1、第1、2、3步其中之一出现问题,则不会执行A系统本地业务,故不会出现问题。
2、第4步如果执行失败,则直接回滚此操作。
3、第5步如果执行失败,则消息