分布式事务(一)

太过爱你忘了你带给我的痛 2021-10-01 09:02 353阅读 0赞

分布式事务是个复杂的问题, 针对不通的业务场景, 实现的方式也各式各样, 今天主要从下面两个方面:

1.  为什么? 为什么需要分布式事务;
2.  怎么做? 分布式事务如何实现;

来展开, 希望这场分享下来, 大家能对分布式事务有个基础的了解;

# 1. 为什么需要分布式事务? #

分布式事务是伴随分布式产生的, 我们通过架构的演进来看下为什么需要分布式事务;

假设我们是一家互金公司, 刚开始的时候, 都处于一台服务器上: 有个场景是用户下单购买了基金, 这个时候需要扣账户余额, 并给用户加资产;

![16020996-95d7b9bd888374c0][]

image.png

当所有业务都处于一个DB的Connection的时候, 可以使用单机事务来保证, 落订单成功了, 必然会给用户加上资产的;

但是随着公司的发展, 单个应用已经撑不起现有业务了, 而且随着业务的扩展, 需要进入为微服务阶段了:

![16020996-40e75bb7bc930895][]

image.png

这只是一个场景: 将原有的系统做了拆分, 有了三个微服务: 订单, 账户和资产, 服务间通过RPC进行信息交互; 这三个微服务共用同一个DB实例;

还是刚才用户购买基金, 但是可以看到服务拆分虽然降低了系统间的耦合, 但是也导致了原本的单机事务不可用了(这里的不可用指的是跨服务之间的写入操作, 单系统内仍然可以使用单机事务), 所以我现在其实是无法保证落订单成功必定会加资产的;

和单机事务出现的原因一样, 正因为出现了三态问题, 我们就需要引入一种机制, 来帮业务系统处理掉中间态;

# 2. 分布式事务如何实现 #

## 2.1 分布式常见的问题 ##

### 2.1.1 部分失效问题 ###

当一项工作需要多个节点参与时, 其中的一些节点可能会失败, 甚至你不会收到明确的结果;

### 2.1.2 不可靠的网络 ###

我们的应用基本都是互联网应用, 系统间的交互都是基于网络的, 虽然平时在说网络调用时都说的是同步阻塞的, 但是我们所处的网络大部分都是**异步分组网络（asynchronous packet networks）;** 也就是说一个节点给另一个节点发送数据时, 网络不能保证数据包什么时候到达, 甚至不能保证一定到达; 可以参考一下场景:

1.  请求都没发出去(被拔网线);
2.  请求阻塞了, 但是随后会发出去;
3.  请求的远程节点可能挂了(断电或者什么原因);
4.  远程节点收到了, 但是还没处理(比如在GC), 但是一段时间后会处理;
5.  远程节点响应了, 但是在网络中丢了(比如交换机配置错误, 响应到另一台机器上去了);
6.  远程节点响应了, 但是响应被阻塞了, 但是恢复后会发出;

再回过来看, 如果我们请求方没有收到响应, 是因为

1.  请求没发出?
2.  远程节点不可用?
3.  远程节点挂起了?
4.  还是远程节点响应了, 我们没收到？

其实我们是不知道远程阶段的状态的, 只是知道我们没有收到响应;

还有个词需要专门提一下, 网络分区; 简单来说就是有A, B, C三个节点, AB能正常通信, 但是AB无法与C通信, 那么就说AB与C形成了网络分区;

### 2.1.3 不可靠的时钟 ###

### 2.1.4 拜占庭将军问题 ###

## 2.2 CAP ##

在[理论计算机科学][Link 1]中，[**CAP定理**][CAP]（CAP theorem），又被称作**布鲁尔定理**（Brewer's theorem），它指出对于一个[分布式计算系统][Link 2]来说，不可能同时满足以下三点：[\[1\]][1][\[2\]][2]

*  一致性（**C**onsistency） （等同于所有节点访问同一份最新的数据副本）
 *  [可用性][Link 3]（**A**vailability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
 *  [分区容错性][Link 4]（**P**artition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[\[3\]][3]。）

虽然CAP看似给了三个选项, 但这里面的P其实是个必须项, 因为前面也说了, 网络是不可靠, 那么就是从C 和 A做取舍, 最终结果是CP 和 AP;

其实我觉得CAP考虑的还是比较片面的, 主要原因是P只是考虑网络异常中的网络分区, 延时节点或者死亡节点压根就没提;

### 2.2.1 CAP的一致性 ###

这里指的就是线性一致性, 这个线性一致性怎么理解呢? 读写并发的时候, 只有一个读已经读取了新数据, 该读取之后的所有读取都应该读取的是新数据;

这里的线性一致性有前提 就是按时间轴, 从左至右不会不会出现回退的情况, 怎么理解:

![16020996-fe02aa9d0db60431][]

image.png

注: 此模型不假设隔离性;

看最后一个读取 read x = 2是非法的, 因为db1已经做了CAS操作, 且最新的X值已经被db2读取到了, 那么db3就不应该还能读取到2了;

所以线性一致性通过记录所有请求和响应的时间, 再校验他们能否排列成一个时间有序的数组;

##### 线性一致性 和 可序列化(串行化) #####

串行化: 指的是事务并发的时候, 一个事务必定在前一个事务完成以后才会执行; 这里事务执行的先后顺序可以和事务实际顺序不同;

线性一致性: 线性一致性保证的是读取和写入的新鲜度保证, 但是线性一致性不是事务, 所以他不会防止写入偏差;

## 2.3 如何实现分布式事务 ##

### 2.3.1 回滚型事务: 两阶段提交(2PC) ###

单机事务的原子性是由数据的落盘顺序决定的: 在数据最终落盘之前, 事务都有可能被中止的;

但是分布式事务涉及到了多个节点, 那么仅向这些节点发送并独立提交事务是不可行的, 因为这样很容易违反原子性: 一些节点上提交成功了, 但是另一些节点上提交失败了; 为了解决这种情况, 必须有一个机制来协调这些节点的事务提交;

必须要注意一点是:事务的提交是不可撤销的, 原因是如果事务的提交是可撤销的, 那么该事务之后的所有写入都需要被撤销, 这个是不现实的;

接下来看下2PC是怎么保证原子提交的;

![16020996-0e1b6d59b70fe683][]

image.png

TC: 事务协调器: 主要作用就是来协调各个分支的提交与回滚的; 分布式事务的原子提交逻辑主要在TC上面;

参与者: 各个系统上的数据库;

主要流程:

1.  当应用想要启动一个分布式事务时，它向协调者请求一个事务ID。此事务ID是全局唯一的。
2.  应用在每个参与者上启动单节点事务，并在单节点事务上捎带上这个全局事务ID。所有的读写都是在这些单节点事务中各自完成的。如果在这个阶段出现任何问题（例如，节点崩溃或请求超时），则协调者或任何参与者都可以中止。
3.  当应用准备提交时，协调者向所有参与者发送一个**准备**请求，并打上全局事务ID的标记。如果任意一个请求失败或超时，则协调者向所有参与者发送针对该事务ID的中止请求。
4.  参与者收到准备请求时，需要确保在任意情况下都的确可以提交事务。这包括将所有事务数据写入磁盘（出现故障，电源故障，或硬盘空间不足都不能是稍后拒绝提交的理由）以及检查是否存在任何冲突或违反约束。通过向协调者回答“是”，节点承诺，只要请求，这个事务一定可以不出差错地提交。换句话说，参与者放弃了中止事务的权利，但没有实际提交。
5.  当协调者收到所有准备请求的答复时，会就提交或中止事务作出明确的决定（只有在所有参与者投赞成票的情况下才会提交）。协调者必须把这个决定写到磁盘上的事务日志中，如果它随后就崩溃，恢复后也能知道自己所做的决定。这被称为**提交点（commit point）**。
6.  一旦协调者的决定落盘，提交或放弃请求会发送给所有参与者。如果这个请求失败或超时，协调者必须永远保持重试，直到成功为止。没有回头路：如果已经做出决定，不管需要多少次重试它都必须被执行。如果参与者在此期间崩溃，事务将在其恢复后提交——由于参与者投了赞成，因此恢复后它不能拒绝提交。

上面是只有TC的情况, 可以发现TC的业务其实非常重的, 那么在生产中一般会抽象出一个TM(事务管理器), TM主要是用来定义事务边界和事务编排的, 一般事务的发起者就是TM; 下面看一下具有TM的2PC是怎么做的:

![16020996-7bde31f4cb18ebae][]

image.png

2PC根据CAP来看的话, 是属于CP的, 也就是为了一致性牺牲了可用性;

#### 2PC的问题 ####

1.  2PC要求所有参与者在全局事务提交之前, 各个分支事务的资源都必须锁住; 那么如果一阶段完成到全局事务提交之前, 各个参与者锁住的资源其实不可用的; 这个时候如果其中某个参与延迟特别高, 就会导致全局事务变成长事务, 其他参与者的资源长时间处于不可用的状态;
2.  2PC的协调者如果不做高可用的话, 协调者挂了, 所有参与者都只能被动的等待协调者重启, 在这段时间内, 锁住的资源同样得不到释放;

### 2.3.2 补偿型事务 ###

#### 2.3.2.1 TCC ####

在回滚型事务不理想的情况下, 我们的想法是想让一阶段结束, 就让参与者释放锁; 然而因为事务是不可撤销的, 那么如果参与者出现了异常怎么处理; 我们就需要引入补偿, 二阶段的时候再起一个事务, 对一阶段的操作补偿;

补偿型事务中人气最高的是TCC, TCC是try, confirm, cancel的简写; 下面我们来看看TCC是怎么实现分布式事务的:

![16020996-a341ffd3984dd964][]

image.png

如果只是看图的话, 和回滚型的2PC基本没啥区别的, 但是TCC和2PC最大的区别是锁的粒度, TCC把二阶段的锁控制交给了业务层来做处理, 分布式事务随着一阶段的提交, 也就释放了锁; 因此使用TCC需要对业务做改造, 下面基于基金的购买来说明下如何做业务改造;

首先看account的改造:

假设原本的表结构是:

<table> 
 <thead> 
  <tr> 
   <th>account_no</th> 
   <th>user_id</th> 
   <th>amount</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>账户</td> 
   <td>用户ID</td> 
   <td>可用金额</td> 
  </tr> 
 </tbody> 
</table>

那么需要在该表中引入一个中间态的金额: 冻结金额

<table> 
 <thead> 
  <tr> 
   <th>account_no</th> 
   <th>user_id</th> 
   <th>amount</th> 
   <th>frozen_amount</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>账户</td> 
   <td>用户ID</td> 
   <td>可用金额</td> 
   <td>冻结金额</td> 
  </tr> 
 </tbody> 
</table>

同样position中也需要引入两个中间态: 一个是购买中的金额, 另一个是赎回中的金额;

<table> 
 <thead> 
  <tr> 
   <th>position_id</th> 
   <th>user_id</th> 
   <th>capital</th> 
   <th>buying_capital</th> 
   <th>taking_capital</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>资产ID</td> 
   <td>用户ID</td> 
   <td>持有中的资产</td> 
   <td>购买中的资产</td> 
   <td>赎回中的资产</td> 
  </tr> 
 </tbody> 
</table>

表结构改造完成以后, 结合图片来看下TCC是具体怎么执行的;

a. TM会开启全局事务, 获取全局事务ID;

b. TM调用各个分支事务的分支事务的try方法:

order\_try: insert order status = 0(初始化状态, 表示处理中);

account\_try: update account set amount = amount -100, frozen\_amount = frozen\_amount + 100;

position\_try: update position set buying\_capital = buying\_capital + 100;

c. TM 等待各个分支事务的ACK;

d. 如果各个分支事务try的ACK都是OK, 那么就需要发送commit指令给TC做全局事务的提交;

e. TC调用分支事务的confirm方法:

order\_confirm: update order set status = 1(成功) where id = 1;

account\_confirm: udpate account set frozen\_amount = frozen\_amount - 100;

position\_confirm: update position set capital = capital + 100, buying\_capital = buying\_capital - 100;

f. 如果其中有个分支事务的ACK是失败或者超时了, 那么就需要调用cancel做补偿:

g. TC调用分支事务的cancel做补偿:

order\_cancel: update order set status = -1(失败) where id = 1;

account\_cancel: update account set amount = amount + 100, frozen\_amount = frozen\_amount + 100;

position\_cancel: update position set buying\_amount = buying\_amount - 100;

h. 如果在二阶段(confirm | cancel)TC没有接收到分支事务二阶段的ACK, 是需要再次调用confirm ｜ cancel方法的, 所以TCC中的confirm ｜ cancel方法一定要是幂等的;

##### TCC存在的问题 #####

虽然TCC通过将一个全局事务拆分为两个小事务, 一阶段 和 二阶段的事务, 灵活性和可用性得到了保证; 但是刚才的讲解中也可以看到, TCC对业务的侵入性很高:

1.  需要提供三个接口, try, confirm, cancel;
2.  需要对现有业务做改造, 需要处理一阶段造成的中间态数据;
3.  如果是不可控的第三方业务, TCC是无法做的(不可能去推动第三方做TCC改造);

那么又没有即不需要做业务改造, 又能避免2PC的性能问题的呢? SAGA可能是一个解决方案;

#### 2.3.2.2 SAGA ####

SAGA的解决方案其实和TCC挺相似的, 也是将长事务拆分; 但是SAGA的一阶段不是预留资源, 而是和2PC一样直接修改并提交; 如果在某个分支事务执行出错了, 需要按顺序回滚之前的所有分支事务, 按顺序怎么理解呢? 还是刚才的例子:

order -> account -> position; 结果在position加资产的时候出异常了, 那么SAGA会进行回滚, 顺序是:

account -> order; 也就是回滚的顺序是倒序;

虽然SAGA相对TCC省去了业务改造, 并且也省去了prepare阶段的资源占有; 但是这种直接操作的结果是对其他业务线程可见的, 就会导致充值场景下, 一阶段给用户加了资金, 但是二阶段需要回滚, 但是用户已经消费了, 导致回滚失败的情况;

### 2.3.3 通知型事务 ###

通知型事务的产生是为了解决2PC的性能问题, TCC的业务侵入性, 将事务看成消息, 由消费者来保证最终一致性;

通知型事务又可以分为可靠通知和最大努力通知;

#### 2.3.3.1 最大努力通知 ####

最大努力通知有个前提就是服务存在上下游关系, 上游(provider)成功了, 通知的消费者必须保证消费成功, 如果消费失败会重试机制; 如果还是重试失败, 上游必须提供个接口给下游查询事务成功后数据;

这个场景比较常用的是跨系统间的信息交互, 比如支付网关和业务系统; 支付网关支付成功后会通知业务系统, 业务系统消费失败达到次数限制后会反查支付网管的数据;

#### 2.3.3.2 可靠通知 ####

可靠通知可以看成是支持回滚的最大努力通知, 在达到重试次数后, 允许下游执行事务回滚; 这样就没有了消费者必须成功的约束了;

我们回看分布式事务下的ACID保证，原子性（Atomicity）和持久性（Durability）与传统事务无异，但一致性（Consistency）与隔离性（Isolation）上除了2PC完全满足外, 其他的补偿型与通知型事务都有或多或少的缺失，它们都强调最终一致性，即允许在一段可接受的时间内各节点数据不一致，由于它们多半是将大事务分解成一个个本地小事务，所以在一段时间也存在隔离性问题;

[16020996-95d7b9bd888374c0]: /images/20210809/5920888713f54dbea13f3000ec7913e4.png
[16020996-40e75bb7bc930895]: /images/20210809/ad679f193db447e794f85d486ad6f690.png
[Link 1]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fwiki%2F%25E7%2590%2586%25E8%25AB%2596%25E8%25A8%2588%25E7%25AE%2597%25E6%25A9%259F%25E7%25A7%2591%25E5%25AD%25B8
[CAP]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fwiki%2FCAP%25E5%25AE%259A%25E7%2590%2586
[Link 2]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fwiki%2F%25E5%2588%2586%25E5%25B8%2583%25E5%25BC%258F%25E8%25AE%25A1%25E7%25AE%2597
[1]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fwiki%2FCAP%25E5%25AE%259A%25E7%2590%2586%23cite_note-Lynch-1
[2]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fwiki%2FCAP%25E5%25AE%259A%25E7%2590%2586%23cite_note-2
[Link 3]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fwiki%2F%25E5%258F%25AF%25E7%2594%25A8%25E6%2580%25A7
[Link 4]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fw%2Findex.php%3Ftitle%3D%25E7%25BD%2591%25E7%25BB%259C%25E5%2588%2586%25E5%258C%25BA%26action%3Dedit%26redlink%3D1
[3]: https://links.jianshu.com/go?to=https%3A%2F%2Fzh.wikipedia.org%2Fwiki%2FCAP%25E5%25AE%259A%25E7%2590%2586%23cite_note-3
[16020996-fe02aa9d0db60431]: /images/20210809/6b3ea3a35ccc428281ddf296f600f784.png
[16020996-0e1b6d59b70fe683]: /images/20210809/0530d8118c7044b795b6f068cc50e4ff.png
[16020996-7bde31f4cb18ebae]: /images/20210809/cfcdda76f06d4e58876c103183a3a51b.png
[16020996-a341ffd3984dd964]: /images/20210809/f843416c480949188561bc87a9cf1917.png