分布式事务

分布式环境下为了保证跨服务、跨数据库数据的正确性,通常有两种方案,第一种是通过补偿机制实现弱一致性,另外一种就是通过分布式事务来实现强一致性。

下面就来探一探分布式事务的前世今生。

目录

定义

XA 

两阶段提交

三阶段提交


定义

分布式事务也称全局事务,参与全局事务的各本地事务称作分支事务。

分布式事务

分布式事务是为实现分布式环境下,跨数据库、跨服务的多个数据库之间的数据的完整性(本地事务我们通常叫做 ACID )。

XA 

 XA 是指由 X/Open 组织提出的分布式事务两阶段提交的规范(协议),主流的数据库都支持该协议。

XA 通过协调一个事务访问多个关系型数据库来保证数据的完整性。

协议定义了两个角色,以及两者之间通信的接口。

  • 事务管理器(TM, 也被称为协调者):管理全局事务

  • 资源管理器(RM):全局事务的参与者,可以是一个数据库或者一个 JMS 系统

XA 两阶段提交过程:

1. TM 询问 所有的 RM 提交事务会不会有问题;

2.  如果没问题,TM 向所有的 RM 发送 commit() 指令,否则发送 rollback() 指令

具体过程可以往下看。

两阶段提交

  1.  TC 发送 prepareCommit  到 RM, RM 执行提交操作并响应 TC;

分布式事务

2.  TC 根据所有RM 的响应,发送 commit/rollback 指令,RM 操作根据指令本地事务 

分布式事务

存在的问题:

1. TC 提供了超时重试机制,所以即使 RM 宕机了,事务仍然能正确执行;

但是 TC 一旦宕机了,RM 就会一直阻塞等待,本地资源也会一直被锁住。

2. 数据不一致风险:极端情况下会发生数据不一致, 比如第二阶段出现网络分区一部分RM 收到了指令正确执行 ,另一部分RM没收到会一直等待。

3. 第二阶段成功执行前,所有的分支事务会锁住对应的资源,所以性能不如单机的本地事务好。

为了解决两阶段提交存在的问题,提出了三阶段提交的方式。

三阶段提交

与两阶段提交相比,三阶段在开始增加了一个询问阶段:

  1. TC 询问 TM 可以提交吗,做些业务判断,是否具备事务操作的条件;

分布式事务

三阶段提交与两阶段提交相比,除了增加了第一步的询问,还增加了参与者超时机制,即使 TC 挂了,参与者会在一定时间后自动 commit 。

之所以三阶段提交可以增加超时机制,是因为多了一个询问阶段,询问阶段通过后,才会进入 prepare 阶段,TC 同时会记录全局事务的状态,超时后,RM 自动提交,TC 恢复后,能根据全局事务的状态执行补偿操作。

存在的问题:

  1. 性能比两阶段提交还要差;

  2.  仍然有数据不一致风险:比如还是第二阶段出现网络分区一部分RM 收到了 rollback 指令正确执行 ,另一部分RM没收到超时后,自动 commit;

总体来说,分布式事务设计到全局事务和多个分支事务协调,会因为各种不可靠问题,带来性能问题,并且会出现一些数据不一致的风险,因此使用需要谨慎!


如果觉得还不错的话,交个朋友, 原创不易,且看且珍惜~

分布式事务

 

上一篇:【数学基础】全相关(Total Correlation)


下一篇:TC进度条