[Java复习] 分布式事务 Part 1

1. CAP理论

C: Consistency 一致性

A: Availability 可用性

P: Partition tolerance 分区容错性

CAP定理：一个分布式系统不可能同时满足CAP三个要求，最多只能同时满足其中两项。

1.1. CA:

放弃分区容错性，所有数据放一个节点，退回单机模式。

1.2. CP:

放弃可用性，一旦网络故障，受影响服务需要等待恢复时间，系统处于不可用状态。

1.3. AP:

放弃一致性，这里指放弃强一致性，确保最终一致性。大多数分布式系统的选择。

2. BASE理论

BASE: Base Available(基本可用)，Soft state(软状态), Eventually consistent(最终一致性)。

BASE是对CAP一致性和可用性权衡的结果。

1. 基本可用：指分布式系统出现不可预知故障时，允许损失部分可用性，响应时间合理延长，服务上适当降级。

2. 软状态: 允许分布式系统中的数据处于中间状态，允许各节点数据同步时存在延时。

3. 最终一致性：允许系统中所有数据副本，在经过一段时间同步后，最终能够达到一个一致的状态。不需要实时保证系统的数据一致性。

3. 两阶段提交(2PC)

数据库支持2PC，又叫XA transactions。

MySQL从5.5版，Oracle从7版，SQL Server 2005开始支持。

XA是一个两阶段提交协议，协议分两阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交/投票(pre commit)此操作，并反映是否可以提交。

第二阶段：事务协调器要求每个数据库提交数据。

如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

预提交/投票阶段：

事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息，每个参与者要么直接返回失败(如权限验证失败)，

要么在本地执行事务，写本地的 redo 和 undo 日志，但不提交。

提交阶段：

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；

否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过

程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

2PC缺点：

1. 同步阻塞。 执行过程中，所有节点都是事务阻塞的。

2. 单点故障。

2.1. 协调者正常，参与者宕机

协调者无法收集到所有参与者反馈，会陷入阻塞。

2.2. 协调者宕机，参与者正常

无论哪个阶段，协调者挂了，则无法发送提交请求，参与者会陷入阻塞。

2.3. 协调者与参与者都宕机

1). 发生在第一阶段，由于参与者都没有真正commit，则可以重新选出协调者，再执行2PC。

2). 发生在第二阶段，并且挂了的参与者在挂之前并没有收到协调者指令。这种情况，新的协调者重新执行2PC。

3). 发生在第二阶段，有部分参与者已经commit，产生数据不一致(脑裂)。2PC无法解决！

4). 协调者发出commit后挂了，唯一接收到这条消息的参与者同时也挂了。则即使选举出新的协调者，这条事务状态也不确定，没人知道事务是否被已经提交。

4. 三阶段提交（3PC）

3PC是2PC的改进版。

3PC改进点：

1. 同时在协调者和参与者引入超时机制。

2. 在2PC的第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与者状态时一致的。

3PC有CanCommit, PreCommit, DoCommit三个阶段。

1. CanCommit阶段：

2PC的第一阶段是本地事务执行结束后，最后不Commit。3PC的CanCommit是指尝试获取数据库锁，如果可以就返回Yes，进入预备状态，否则返回No。

2. PreCommit阶段：

如果上一阶段所有参与者都返回Yes，则进入PreCommit阶段进行事务预提交。这里协调者和参与者都引入超时机制。

假如有任何一个参与者向协调者发送No，或者等待超时之后，协调者还没有收到参与者响应，则执行事务中断。

3. DoCommit阶段：

真正进行事务提交。

包括 1. 协调者发送提交请求；2.参与者提交事务；3.参会者响应反馈(向协调者发送ACK)；4.协调者确定事务完成。

5. TCC事务

TCC: Try / Confirm / Cancel，可归纳为补偿型事务。

核心思想：针对每个操作，都有有一个与其对应的确认和补偿(撤销)操作。

Try: 针对业务操作做检测(一致性)和资源预留(隔离性)。

Confirm:对业务进行确认提交。默认Try成功并开始执行Confirm，Confirm一定成功。

Cancel: 在业务执行错误，需要回滚时执行业务补偿，释放预留资源。

TCC优点：

1. 解决协调者单点故障的问题。

2. 引入超时后进行补偿，并不会锁定整个资源，事务颗粒的变小。

3. 通过补偿机制，由业务操作管理数据一致性。

TCC缺点： 开发复杂，每个目标字段都需要一个预留(冻结)字段，需要写很多补偿代码，在一些业务场景不太好定义和处理。

TCC使用场景：钱，金融等对事务要求非常高的核心业务场景。

总结： TCC使用于大部分接口是同步调用的场景，要么一起成功，要么一起回滚。但在实际系统中，可能服务之间的调用时异步的，通过消息中间件。