分布式事务基础

发表于 | 更新于 | 分类于 | 阅读次数：

分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。单数据源的一致性依靠单机事务保证，多数据源的一致性由分布式事务保证。

1. 原理

1.1 事务

1.1.1 原子性 (Atomicity)

一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。

1.1.2 一致性 (Consistency)

在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义的等约束不会被破坏。

1.1.3 隔离性 (Isolation)

数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

1.1.4 持久性 (Durability)

事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

1.2 两将军问题

In computing, the Two Generals’ Problem[1] is a thought experiment meant to illustrate the pitfalls and design challenges of attempting to coordinate an action by communicating over an unreliable link. In the experiment, two generals are only able to communicate with one another by sending a messenger through enemy territory. The experiment asks how they might reach an agreement on the time to launch an attack, while knowing that any messenger they send could be captured.

It is related to the more general Byzantine Generals Problem and appears often in introductory classes about computer networking (particularly with regard to the Transmission Control Protocol, where it shows that TCP can’t guarantee state consistency between endpoints and why this is the case), though it applies to any type of two-party communication where failures of communication are possible. A key concept in epistemic logic, this problem highlights the importance of common knowledge). Some authors also refer to this as the Two Generals’ Paradox, the Two Armies Problem, or the Coordinated Attack Problem.[1][2] The Two Generals’ Problem was the first computer communication problem to be proved to be unsolvable. An important consequence of this proof is that generalizations like the Byzantine Generals problem are also unsolvable in the face of arbitrary communication failures, thus providing a base of realistic expectations for any distributed consistency protocols.

1.3 CAP

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

In theoretical computer science, the CAP theorem, also named Brewer’s theorem after computer scientist Eric Brewer), states that it is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees.

1.4 BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语font>的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

分布式事务在分布式环境下，为了满足可用性、性能与降级服务的需要，降低一致性与隔离性的要求，一方面遵循 BASE 理论：

  • 基本业务可用性（Basic Availability）
  • 柔性状态（Soft state）
  • 最终一致性（Eventual consistency）

同样的，分布式事务也部分遵循 ACID 规范：

  • 原子性：严格遵循
  • 一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽
  • 隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽
  • 持久性：严格遵循

1.5 XA，JXA

XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口[2]。XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现。

2. 解决方案

拿转账作为例子，A需要转100元给B，那么需要给A的余额-100元，给B的余额+100元，整个转账要保证，A-100和B+100同时成功，或者同时失败。看看在各种场景下，是如何解决这个问题的。

2.1 两阶段提交(2PC)

两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。

2.1.1 过程

2.1.1.1 准备

首先协调者询问参与者事务是否执行成功，参与者发回事务执行结果。

2.1.1.2 提交或者回滚

然后如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。(标黄的部分可能会失败)

2.1.2 具体实现

  • 第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。
  • 第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。

2.1.3 协调者如何来通信的？

2.1.4 存在的问题

2.1.4.1 同步阻塞

所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。

2.1.4.2 单点问题

协调者存在挂掉的风险。

2.1.4.3 数据不一致

如果在第二阶段，因为网络问题，出现只有部分commit的情况，但是此时并没有回滚。

2.2 补偿事务(TCC)

关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

2.2.1 过程

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

  • Try 阶段主要是对业务系统做检测及资源预留
  • Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
  • Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

举个例子，假入 Bob 要向 Smith 转账，思路大概是： 我们有一个本地方法，里面依次调用

  1. 首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
  2. 在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
  3. 如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

2.2.2 存在的问题

2.2.2.1 数据一致性问题

2.3 SAGA

2.4 本地消息表

2.5 事务消息

2.6 最大努力通知

2.7 AT事务消息

这是阿里开源项目seata中的一种事务模式，在蚂蚁金服也被称为FMT。优点是该事务模式使用方式，类似XA模式，业务无需编写各类补偿操作，回滚由框架自动完成，缺点也类似AT，存在较长时间的锁，不满足高并发的场景。有兴趣的同学可以参考seata-AT。

引用资料

  1. 1.Wikipedia《两将军问题，拜占庭将军问题》https://en.wikipedia.org/wiki/Two_Generals'_Problem ↩
  2. 2.分布式事务最经典的七种解决方案 ↩
-------------本文结束感谢您的阅读-------------
我知道是不会有人点的，但万一有人想不开呢？