X/Open分布式事务模型

X/Open DTP是X/Open组织定义的一套分布式事务标准,这个标准提出了二阶段提交协议(2PC)来保证分布式事务的完整性。

X/Open DTP中包含三种角色。

  1. AP : Application 应用程序
  2. RM: Resource Manager ,资源管理器,比如数据库
  3. TM: Transaction Manager ,事务管理器,也称为事务协调者,提供APi接口管理RM。

X/Open规范中分布式事务发起流程

  1. 配置TM,并将多个RM注册进入TM中,相当于TM注册RM为数据源。
  2. AP从TM中获取RM链接。
  3. AP向TM发起全局事务,并生成 全局事务id(XID),XID会通知到各个RM。
  4. AP通过链接完成数据操作,此时AP会把XID传递给RM。
  5. AP结束全局事务,TM通知各个RM事务结束。
  6. 根据RM各个事务的执行结果,TM执行提交或者回滚操作。

TM和RM之间的事务控制是通过XA协议来完成的。XA协议是X/Open的事务处理规范,也是分布式事务的业界标准。

二阶段提交过程(2PC)

  1. 准备阶段:TM通知RM准备分支事务,记录事务日志,并告知事务返回结果。
  2. 提交/回滚阶段:如果所有的RM都返回成功,TM通知所有RM提交事务。如果存在RM返回失败的情况,TM通知所有的RM回滚事务。

存在的问题

  1. 同步阻塞:所有的RM都是事务阻塞型,对于任何一个指令都必须有明确下一步才能进行,否则将处于阻塞状态。
  2. 过于保守:任何一个节点失败都会导致全局事务回滚。
  3. 单点故障:如果TM在第二阶段发生了故障,那么其他RM会一直处于锁定状态。
  4. 第二阶段脑裂问题:可能存在第二阶段RM接收COMMIT指令时,部分RM没有收到COMMIT,导致最终出现不一致的情况。

三阶段提交过程(3PC)

三阶段提交协议利用超时解决了部分同步阻塞的问题,具体阶段如下

  1. CanCommit(询问阶段):TM向其他RM发送事务执行请求,询问是否可以完成指令。这一阶段RM不需进行事务锁定,同时会有超时机制保证。
  2. PreCommit(准备阶段):TM根据返回决定事务是否继续执行。如果所有RM可以进行事务,则TM发送进入PreCommit指令。否则TM发送中断指令。
  3. DoCommit(提交/回滚阶段):TM根据PreCommit结果决定是否进行提交事务。如果RM全部PreCommit阶段返回成功则Commit,否则回滚。

三阶段提交与两阶段提交的区别:

  1. 增加ComCommit阶段,用于尽早发现不能提交事务的RM从而终止事务。
  2. CanCommit和PreCommit阶段增加超时机制,一旦超时,事务会继续提交(这种情况下成功几率较大)。防止对资源长时间锁定。

CAP和BASE理论

前面提到的2PC和3PC是XA协议用于解决一致性的基本原理,但是这两种方案为了解决一致性而失去了可用性。这里涉及到分布式领域的两个关键理论CAP和BASE。

CAP理论

指分布式系统中不能同时满足C (一致性),A(可用性),P(分区容错性)。

C: 一致性,比如数据在多个副本中保持强一致。
A:可用性,系统对外提供的服务一直保持可用状态。
P:分区隔离性,在分布式系统中出现任何网络分区故障,系统仍然能够正常提供服务。

准确的说,分区隔离性并不是特性,而是属于分布式的必然存在场景,因此分区隔离性在分布式系统中必须得到满足。

既然隔离性必须得到满足,那么系统就会有两个发展方向,CP和AP。

CP:放弃可用性,实现强一致性,比如前面提到XA协议的2PC和3PC。
AP:放弃强一致性,保留最终一致性,但是保证高可用,AP是分布式系统的主要选择。

BASE理论

BASE理论是根据CAP理论中一致性和可用性不可兼得的思想衍生而来。它的核心思想是牺牲数据的强一致性来获取高可用性。
它有如下三个特性:

  1. Basically Avaliable (基本可用):系统在出现故障时,允许损失一部分功能的可用性,保证可行功能可用。
  2. Soft State (软状态):允许系统中存在中间状态,也就是允许系统中数据同步存在延时。
  3. Eventually Consistent (最终一致性):系统中的数据在经过一段时间后,会达到最终的一致。

分布式事务的常见解决方案
在分布式系统中,基于CP的强一致性方案在数据处理能力上有很大的瓶颈,因此在互联网场景中更多采用柔性事务,所谓柔性事务就是遵循BASE理论来实现的事务模型,它有两个特性:基本可用,柔性状态。

TCC补偿性方案

TCC(TRY-CONFIRM-CANCEL)把一个完成的事务拆成三个步骤:

  1. Try:对数据校验或者预留阶段。
  2. Confirm:确认真正执行的任务,只操作Try阶段预留的资源。
  3. Cancel:取消执行,释放Try阶段的资源。

TCC是利用了2PC的思想,Try阶段通知RM准备资源,Confirm阶段确认事务。

下面用一个购买理财产品的例子来描述下TCC的工作机制。

使用余额购买理财产品涉及到两个阶段:

  1. 账户服务中对用户账户余额进行扣减。
  2. 理财产品服务中对执行理财产品可申购余额进行扣减。

下面对两个服务实现TCC三个方法。

  1. 账户服务中,使用Try方法对用户余额进行冻结,Confirm对用户余额进行扣减,Cancel对用户余额进行解冻。
  2. 理财产品服务中,使用Try方法对申购余额进行冻结,Confirm对冻结的额度进行扣减,Cancel对冻结的额度进行释放。

同时需要保证TCC服务接口的幂等性,因为TCC事务时允许重试的。

基于可靠性消息的最终一致性方案

基于消息队列实现一致性也是分布式系统常用的解决方案。它主要利用消息中间件(Kafka,RocketMQ)的可靠性来实现数据一致性的投递。
如果某些场景中不要求实时性,那么可以采用这种基于可靠性消息的方案来实现最终一致性保证。

参考资料:《Spring Cloud Alibaba 微服务原理与实践》

发表评论

邮箱地址不会被公开。 必填项已用*标注