分布式事务模型

分布式事务模型

• XA 模型，eXtended Architecture： 强一致模型 ， 原理

  • XA的含义是用来描述特定的分布式系统框架，该体系结构使用诸如两阶段提交的机制来支持 已确认的分布式事务。应该指的就是 X/Open DTP模型 ： X/Open就是现在的 Open Group组织

  • DTP 模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。

  • XA模型，有4个角色：TM、RM 、AP、CRM（ 通信资源管理器 ）

    • AP: Application，应用程序。也就是业务层。哪些操作属于一个事务，就是AP定义的。
    • TM: Transaction Manager，事务管理器。接收AP的事务请求，对全局事务进行管理，管理事务分支状态，协调RM的处理，通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分。
    • RM：Resource Manager，资源管理器。一般是数据库，也可以是其他的资源管理器，如消息队列(如JMS数据源)，文件系统等。

    

  • 有的说XA模型有3个角色](https://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html)

    

• 二阶提交模型（2PC，Two Phase Commitment Protocol） ：raincat ， LCN

  • 两个阶段是指：第一阶段：**准备阶段(投票阶段)**和第二阶段：提交阶段（执行阶段）

    • 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交
    • 如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源

    

  • 二阶段提交还是有几个缺点的：

    • 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的
    • 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作
    • 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。

• 三阶提交模型（3PC , Three Phase Commitment Protocol）

  • 三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段
    • CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
    • 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断
  • 3PC主要解决的单点故障问题，并减少阻塞。因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。

• TCC 模型：try、confirm/cancel

  • TCC事务解决方案本质上是一种补偿的思路，它把事务运行过程分成 try、confirm/cancel 两个阶段，每个阶段都由业务代码来控制。

  • TCC不再是两阶段提交，而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑。

  • 实现过程：

    1. try：完成所有业务检查（一致性），预留业务资源。
    2. confirm：确认执行业务操作，只使用try阶段预留的业务资源。
    3. cancel：取消try阶段预留的业务资源。

  • 与 XA 模型对比

    • XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。
    • TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

    

• Saga 模型（长篇小说）：Seata

  • Saga 模型描述的是另外一种在没有两阶段提交的的情况下解决分布式系统中复杂的业务事务问题
  • 核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务。然后由 Sagas 工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成；如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。
  • 比如我们一次关于购买旅游套餐业务操作涉及到三个操作，他们分别是预定车辆，预定宾馆，预定机票，他们分别属于三个不同的远程接口。可能从我们程序的角度来说他们不属于一个事务，但是从业务角度来说是属于同一个事务的。

• MQ 模型 ：即用消息队列实现，保证最终数据一致

  • 消息一致性方案是通过消息中间件保证上下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，下游应用向消息系统订阅该消息，收到消息后执行相应操作。本质上是依靠消息的重试机制，达到最终一致性。
  • 缺点是：耦合度高，需要在业务系统中引入MQ，导致系统复杂度增加。

• BED 模型（柔性事务）

  • 柔性事务是对XA协议的妥协和补偿，它通过对强一致性要求的降低，已达到降低数据库资源锁定时间的效果。柔性事务的种类很多，可以通过各种不同的策略来权衡使用。
  • 优点是无锁定资源时间，性能损耗小。缺点是尝试多次提交失败后，无法回滚，它仅适用于事务最终一定能够成功的业务场景。因此BED是通过事务回滚功能上的妥协，来换取性能的提升。

• Paxos算法 ， 图解Paxos

  • 世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。