2PC、3PC 和 TCC

对于单机下的本地事务，很显然我们有已被实践证明的成熟 ACID 模型来保证数据的严格一致性。但对于一个高访问量、高并发的分布式系统来说，如果我们期望实现一套严格满足 ACID 特性的分布式事务，很可能出现的情况就是在系统的可用性和严格一致性之间出现冲突——因为当我们要求分布式系统具有严格一致性时，很可能就要牺牲掉系统的可用性。但毋庸置疑的一点是，可用性又是一个所有用户不允许我们讨价还价的属性，比如像淘宝这样的网站，我们要求它 7x24 小时不间断地对外服务。因此，我们需要在可用性和一致性之间做一些取舍，围绕这种取舍，出现了两个经典的分布式理论——CAP 和 BASE，这两者也是所有分布式事务协议的基石。

一、CAP 定理

CAP 首次在 ACM PODC 会议上作为猜想被提出，两年后被证明为定理，从此深深影响了分布式计算的发展。CAP 理论告诉我们，一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本需求，最多只能同时满足其中的两项。

一致性：数据在多个副本之间保持一致。当有一个节点的数据发生更新后，其它节点应该也能同步地更新数据。

可用性：对于用户的每一个操作请求，系统总能在有限的时间内返回结果。

分区容错性：分布式系统中的不同节点可能分布在不同的子网络中，这些子网络被称为网络分区。由于一些特殊原因导致子网络之间出现网络不连通的情况，系统仍需要能够保证对外提供一致性和可用性的服务。

CAP 定理告诉了我们同时满足这三项是不可能的，那么放弃其中的一项会是什么样的呢？

放弃项

放弃P : 如果希望能够避免出现分区容错性问题，一种较为简单的做法是将所有数据放在一个节点上。这样肯定不会受网络分区影响。但此时分布式系统也失去了意义。因此在实际的架构设计中，P是一定要满足的。

放弃A: 放弃可用性就是在系统遇到网络分区或其他故障时，受影响的服务可以暂时不对外提供，等到系统恢复后再对外提供服务。

放弃C: 放弃一致性不代表完全放弃数据一致性，这样的话系统就没有意义了。而是放弃数据的强一致性，保留最终一致性。这样的系统无法保证数据保持实时的一致性，但能够承诺数据最终会达到一个一致的状态。

实际的实现中，我们往往会把精力花在如何根据业务特点在 C（一致性）和 A（可用性）之间寻求平衡。

二、BASE 理论

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

基本可用：基本可用是指在分布式系统出现不可预知的故障时，允许损失部分性能。比如：正常情况下 0.5 秒就能返回结果的服务，但在故障情况（网络分区或其他故障）下，需要 1~2 秒；正常情况下，电商网站的首页展示的是每个用户个性化的推荐内容，但在节日大促的情况下，展示的是统一的推荐内容。

软状态：软状态是指运行系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。比如秒杀系统中，用户余额的扣减和商家余额的增加可以存在延时，当用户余额减了之后即可返回支付成功，商家余额的增加可以等系统压力小的时候再做。

最终一致性：最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能达到一个一致的状态。这也是分布式系统的一个基本要求。

严格遵守 ACID 的分布式事务我们称为刚性事务，而遵循 BASE 理论的事务我们称为柔性事务。在分布式环境下，刚性事务会让系统的可用性变得难以忍受，因此实际生产中使用的分布式事务都是柔性事务，其中使用最多的就是 2PC、3PC 和 TCC。

三、2PC 协议

2PC 是二阶段提交（Two-phase Commit）的缩写，顾名思义，这个协议分两阶段完成。第一个阶段是准备阶段，第二个阶段是提交阶段，准备阶段和提交阶段都是由事务管理器（协调者）发起的，协调的对象是资源管理器（参与者）。二阶段提交协议的概念来自 X/Open 组织提出的分布式事务的规范 XA 协议，协议主要定义了（全局）事务管理器和（局部）资源管理器之间的接口。XA 接口是双向的系统接口，在事务管理器以及一个或多个资源管理器之间形成通信桥梁。Java 平台上的事务规范 JTA（Java Transaction API）提供了对 XA 事务的支持，它要求所有需要被分布式事务管理的资源（由不同厂商实现）都必须实现规定接口（XAResource 中的 prepare、commit 和 rollback 等）。

两阶段如下：

准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，参与者会写 redo 和 undo 日志，然后锁定资源，执行操作，但是并不提交。

提交阶段：如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者明确返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行 undo 日志，释放锁定的资源。