阅读目录
「XA规范」就是上图中「RM」和「TM」的交互规范和接口定义。仅仅是定义了xa_和ax_系列的函数原型以及功能描述、约束和实施规范等，并不包括建议的实现方式。后面会提到的两阶段提交（2PC）是「TM」协调「RM」们完成事务的方法。
所以其实可以说，事务起源于数据库，辉煌于分布式系统。在摩尔定律还适用的时候，软件系统为了承载更大的流量或者说用户数，开始运用「分治」的思想来设计。然后随着互联网的蓬勃发展，B/S应用大行其道的背景下，分布式系统越来越常见。并且随着一个个巨无霸互联网公司的出现，越来越被鼓吹和传颂。
一轮明月的背后是一个阴暗面，从来不让人看见。
能被吹捧的永远是有益的一面，再加上耀眼的数据：多少TPS、多少QPS，更抓人眼球。但是这背后为了让「分治」后的系统能够尽可能的像单个个体一样运作，各类专家学者们通过多年研究，才有了如今的各种著名理论和解决方案。
三、分布式系统中的事务问题
正如前面所说，事务问题其实一直存在，只是在分布式系统中被放大了。并且随着系统拆分的粒度越细，问题的复杂度成指数上升。
分布式系统的事务，不得不提到被广为流传的两个理论：「CAP」、「BASE」。
「CAP」理论由Eric Brewer在2000年PODC会议上提出[2]，所以还被称为Brewer定理。是Eric Brewer在Inktomi期间研发搜索引擎、分布式web缓存时得出的一个猜想：
It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.
印象中左耳朵耗子（陈皓）之前拿西方结婚时的仪式做过一个形象的比喻。大致好像是牧师分别询问男女双方“你愿意吗？”相当于这里的「请求提交」，得到的“yes”相当于「是」这个答复。然后再要求给对方带上戒指，这个要求就相当于这里的「提交」，带完戒指之后的反馈就是「ACK」。
另外值得注意的是，参与者在答复「是」之前会将自己的内部资源变为阻塞状态。因此如果在产生阻塞后协调者出问题，那么这些被阻塞的资源有可能就一直不被释放了，需要额外的介入。
2PC相对来说是最简单的事务模型，但缺点也更多。其它缺点诸如：在某些场景下的数据不一致（参与者与协调者共同与「提交」环节挂了）、阻塞范围过大等问题。
02 三阶段提交（3PC）[6]
▲图片来源于网络，版权归原作者所有
3PC的出现就是通过增加复杂度（性能也因此降低）来解决或优化2PC中的一部分问题。本质的变化就是在2PC的「请求提交」之后增加了一个「准备提交」环节，以增加每个参与者需要等待其它的参与者确认后方可进行具体的操作。
-
「阻塞」这个动作延后到这个「准备提交」环节再做，使得阻塞范围缩小为2PC的2/3（图中背景黄色和绿色部分）。正如上面的例子，在交换戒指之前增加了把戒指交给牧师的动作。
-
同时还解决了协调者的单点问题。故障恢复或者新接替的协调者，可以利用「准备提交」产生的状态结果，来作为参与者和协调者在「提交」出现故障恢复后的界定依据。还是前面的例子，夸张点，交换戒指的时候我失忆了，意识恢复后我只要看到牧师手掌上托着戒指或者我的手上已经被戴好了戒指，就知道我的妻子已经答应了，我只要继续给她做带戒指这个事就好了。
-
新引入了timeout机制，在发生超时执行默认约定，避免了永久阻塞，也因此对多个参与者下的100%数据一致性作出了妥协。比如，协调者在向参与者A发送「doCommit」时timeout了，会引发广播「abort」，但是这个「abort」又未能投递到参与者B，导致参与者B执行了「ACK」后的timeout默认约定「commit」。
03 TCC
在国内，由于阿里的光环加持下TCC好像更火，风头盖过了2PC和3PC。其本质上是另辟蹊径达到了和3PC类似的效果。
▲图片来源于网络，版权归原作者所有
-
通过运用本地事务代替了全局事务，使得可以不需要协调者的存在，避免了协调者的单点问题。
-
3PC中协调者的另一个作用：故障恢复后的数据一致性。在TTC里通过事务日志来确保。
这个概念最初是由Pat Helland于2007年提出的[7]，那时还叫「Tentative-Confirmation-Cancellation」，在2008年的软件开发2.0技术大会上支付宝CTO（程立）将其在国内推广开来。
