关于分布式事务、模型、协议的理解

分布式事务的背景是SOA。服务拆分后，不同服务维护自己的数据库。存在一些操作横跨了多个服务，所以需要将不同服务上的子操作，纳入同一事务中管理，保证整体操作在各服务间的一致性，即各服务数据库的一致性。

在单个服务或系统中，事务的控制比较简单，借助于关系型数据库事务处理，可以很容易的将一组操作纳入一个事务中进行管理。

但在多个服务间，事务的控制往往需要借助额外的事务管理角色，来进行居间协调与控制。

最早的分布式事务协议，是X/Open公司提出的XA协议（eXtended Architecture）。

XA协议定义了事务管理者与参与者两种角色，事务管理者追踪参与者，并与参与者一起完成两阶段提交（2PC）。在2PC的基础上改进后也有三阶段提交（3PC）实现。

1、2PC

两阶段提交分为commit请求阶段与commit阶段。

1）commit请求阶段，事务管理者分别发送commit请求，并等待所有参与者反馈。参与者执行事务到待提交状态（写undo log与redo log），并反馈是否提交。

2）commit阶段，事务管理者汇总反馈状态，通知各参与者执行commit或rollback，并等待各参与者反馈。获得所有参与者反馈后事务完成。

需要注意的是，2PC模型中，等待都是阻塞的，包括事务管理者对参与者的等待以及参与者对事务管理者的等待。事务管理者的等待可以通过超时来处理特殊情况，但参与者的等待是一直持续的。

因此，2PC的缺点也均为阻塞引起，包括：

1）阻塞导致资源占用的性能问题。

2）事务管理者异常导致参与者一直阻塞等待的单点问题。

3）部分参与者提交后管理者异常导致剩余参与者一直阻塞的数据不一致问题。

2、3PC

三阶段提交分为canCommit、preCommit、commit三个阶段。并且加入了超时机制。

1）canCommit阶段，事务管理者分别发送commit请求，并等待所有参与者反馈。参与者反馈是否提交。

2）preCommit阶段，事务管理者汇总反馈状态，通知各参与者做preCommit或丢弃事务。参与者接到preCommit，执行事务到待提交状态，反馈ack并等待。

3）commit阶段，事务管理者汇总ack，通过各参与者做commit或丢弃事务。参与者做最终的commit，并反馈ack。事务管理者收到所有参与者ack后事务完成。

这里加入canCommit阶段，是为了确定在进行preCommit阶段时，各参与者已经对canCommit达成一致。如果事务管理者异常宕机，在恢复后判断有参与者已经commit，则表明在宕机前已经对commit达成一致，并下达了commit指令，所以可以继续通知其他参与者commit。如果判断有参与者未收到preCommit，则表明未达成canCommit一致，可以回滚事务。

3、TCC模型

TODO

参考文档：

1、X/Open XA

2、Two-phase commit protocol

3、Three-phase commit protocol