分布式环境下为了保证跨服务、跨数据库数据的正确性,通常有两种方案,第一种是通过补偿机制实现弱一致性,另外一种就是通过分布式事务来实现强一致性。
下面就来探一探分布式事务的前世今生。
目录
定义
分布式事务也称全局事务,参与全局事务的各本地事务称作分支事务。
分布式事务是为实现分布式环境下,跨数据库、跨服务的多个数据库之间的数据的完整性(本地事务我们通常叫做 ACID )。
XA
XA 是指由 X/Open 组织提出的分布式事务两阶段提交的规范(协议),主流的数据库都支持该协议。
XA 通过协调一个事务访问多个关系型数据库来保证数据的完整性。
协议定义了两个角色,以及两者之间通信的接口。
-
事务管理器(TM, 也被称为协调者):管理全局事务
-
资源管理器(RM):全局事务的参与者,可以是一个数据库或者一个 JMS 系统
XA 两阶段提交过程:
1. TM 询问 所有的 RM 提交事务会不会有问题;
2. 如果没问题,TM 向所有的 RM 发送 commit() 指令,否则发送 rollback() 指令
具体过程可以往下看。
两阶段提交
-
TC 发送 prepareCommit 到 RM, RM 执行提交操作并响应 TC;
2. TC 根据所有RM 的响应,发送 commit/rollback 指令,RM 操作根据指令本地事务
存在的问题:
1. TC 提供了超时重试机制,所以即使 RM 宕机了,事务仍然能正确执行;
但是 TC 一旦宕机了,RM 就会一直阻塞等待,本地资源也会一直被锁住。
2. 数据不一致风险:极端情况下会发生数据不一致, 比如第二阶段出现网络分区一部分RM 收到了指令正确执行 ,另一部分RM没收到会一直等待。
3. 第二阶段成功执行前,所有的分支事务会锁住对应的资源,所以性能不如单机的本地事务好。
为了解决两阶段提交存在的问题,提出了三阶段提交的方式。
三阶段提交
与两阶段提交相比,三阶段在开始增加了一个询问阶段:
-
TC 询问 TM 可以提交吗,做些业务判断,是否具备事务操作的条件;
三阶段提交与两阶段提交相比,除了增加了第一步的询问,还增加了参与者超时机制,即使 TC 挂了,参与者会在一定时间后自动 commit 。
之所以三阶段提交可以增加超时机制,是因为多了一个询问阶段,询问阶段通过后,才会进入 prepare 阶段,TC 同时会记录全局事务的状态,超时后,RM 自动提交,TC 恢复后,能根据全局事务的状态执行补偿操作。
存在的问题:
-
性能比两阶段提交还要差;
-
仍然有数据不一致风险:比如还是第二阶段出现网络分区一部分RM 收到了 rollback 指令正确执行 ,另一部分RM没收到超时后,自动 commit;
总体来说,分布式事务设计到全局事务和多个分支事务协调,会因为各种不可靠问题,带来性能问题,并且会出现一些数据不一致的风险,因此使用需要谨慎!
如果觉得还不错的话,交个朋友, 原创不易,且看且珍惜~