分布式事务，不可不知的 2PC

Posted 2021-04-25 有关SQL

单机版的 SQL 事务，大家肯定不陌生了。

当然，也不是绝对，看这里的数字，就知道大概还有 20%的 SQL 学习者，是不了解事务的机制的。

不信？看这篇文章

言归正传，单机版的事务对我们大家来说，不算个事儿了。

所以挑战分布式事务，就是下一个目标了。

可能大家很早就在用分布式事务了，就像MSDTS等。只不过平时只是编码，写 SQL， 并不会去理解为什么可以这么编程，为什么可以这样组合 SQL Server 和Oracle, 而探知原理，对于我们来说，是决不可放过的有趣经历。

如上图，假设我们要更新 2 台计算机中的数据，这 2 台计算机相互独立，更新的数据必须同时要么被写入数据库，要么同时被撤销。为了保证这个特性，引入了 2PC 机制，即 2 phases commit, 二段式提交策略。

当多台计算机构成一个事务，处理各个不同的数据，必须保证所有的计算机节点都已经提交完毕了，才能在最终发起事务的节点上，标记该事务结束。不允许其中某些节点处理失败，但事务依然提交。

假如我们有一个事务开始了，分别需要在两台计算机节点上做更新，当向两台计算机节点发出更新数据的请求时，等待他们都更新成功，发起事务的节点收到成功的信息，之后发起准备提交的请求，等待两台计算机节点返回准备完毕，之后发起节点发送提交命令，等待两台计算机节点都提交成功并返回，最终发起节点确定提交成功！发起事务的节点，称作coordinator。

让我们看看假如有一台计算机节点，对发来的“准备提交”请求，说了No，会怎么样！coordinator 收到 No 的回应之后，判断有计算机处理失败了，因此对所有的参与者（在这里是两台计算机节点）都发出撤销的请求。

这就像西方婚礼一样：

牧师：你愿意娶吗？

郎：I do 

牧师：你愿意嫁吗？

妻：I do 

牧师：礼成！

引用自：《Design Data-intensive Application》

2PC的优点在于：

1. 一旦 phase 1 得到确定的回应，比如所有的参与者都回应了“Yes"，即意味着所有的参与者都已经成功完成了他的事务，并准备好提交了，此时，coordinator会写上一个 commit point, 在 phase 2 中，会持续发送提交或者回滚的请求，直到所有的计算机节点都执行。如果当中有一个计算机节点故障脱机，那么等到这台计算机恢复的时候，还是会被强迫执行 commit point 点上执行的操作，要么提交，要么回滚！

2. commit point 一旦确定，是没有办法回头的。这也是强制性执行提交或者回滚的原理。

3. 当coordinator 故障脱机时，视时机不同，最终的结果也不同。假如是在phase 2 之前，故障脱机，参与者的所有事务都回滚；在 phase 2 写入 commit point 之后，coordinator 再故障脱机，那么所有的参与者必须等待 coordinator的恢复！恢复之后，coordinator 根据自身的日志记录，来决定是否再次发送 commit 请求。

分布式事务的实战：

 

1 同质化分布式事务：如果厂商是同一家公司的同一个产品，有自己的分布式组件，那么这类分布式事务就是同质的；

2 异构分布式事务：当应用了不同厂家的数据库系统，组成了一个集群，或者分布式处理集群，或者分布式存储集群，甚至有可能其中不少系统还不是数据库形式存在的，可能是其他消息类组件，比如message broker, 在这些异构的集群中，实现分布式事务，称为异构分布式。

X/Open XA ( eXtended Architecture) : 实现 2PC 机制的标准协议。无论参与者是什么产品，只要符合或者提供了XA的协议，那么使用 XA  就能达到 2PC 的提交。

1 XA 并不是网络层协议，并不由操作系统来控制

2 XA 是由 Transaction Coordinator 来实现的，而 Transaction Coordinator 可能会和 发起应用程序的进程写在一起，那么进程或者所在服务器故障脱机之后，整个事务就会被挂起，而事务锁定的对象，会导致其他事务同样被挂起，由分布式架构提供的服务就会变得不可用。因此，处理好 transaction coordinator 的单点故障，是整个分布式架构中要处理的细节之一。

3. Transaction Coordinator 故障后恢复，也可能存在部分事务不能被正确回滚或者进一步提交的情况。这些孤立的事务即将永远留在系统里面，造成资源阻塞。在这种情况下，很多厂商自己开发了一套协议用来迅速从这种尴尬环境中脱离出来，虽然背离了原子性提交 Atomic Commit, 没有听从 Transaction Coordinator 的调配，但是系统是稳定了。这种紧急机制叫做 heuristic decisions，只在灾难性情况下使用，并没有普适性。

总结：2PC 其实是达到共识(Consensus)的一种算法，区块链中大量用到共识算法，有兴趣可以留言！

-------------------------------

欢迎关注【有关SQL】,加入群讨论技术