分布式事务

事务

事务应该具有4个属性：原子性、一致性、隔离性、持续性

原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。
一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
持久性（durability）。持续性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

分布式事务

1. 两段提交
2. 补偿

两阶段提交协议(two-phase commit)

两阶段提交协议（Two-phase Commit，2PC）经常用来实现分布式事务，在两阶段协议中，系统一般包含两类节点：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个。协议中假设每个节点都会记录操作日志并持久化到非易失性存储介质，即使节点发生故障日志也不会丢失。顾名思义，两阶段提交协议由两个阶段组成。在正常的执行过程中，这两个阶段的执行过程如下所述：

第一阶段(提交请求阶段)

协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应；
参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志；
各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
有时候，第一阶段也被称作投票阶段，即各参与者投票是否要继续接下来的提交操作。

第二阶段(提交执行阶段)

成功：当协调者节点从所有参与者节点获得的相应消息都为”同意”时：
协调者节点向所有参与者节点发出”正式提交”的请求；
参与者节点正式完成操作，并释放在整个事务期间内占用的资源；
参与者节点向协调者节点发送”完了”消息；
4. 协调者节点受到所有参与者节点反馈的”完了”消息后，完成事务。

失败：如果任一参与者节点在第一阶段返回的响应消息为”中止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
协调者节点向所有参与者节点发出”回滚操作”的请求；
参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源；
参与者节点向协调者节点发送”回滚完了”消息；
协调者节点受到所有参与者节点反馈的”回滚完了”消息后，取消事务。

两阶段提交协议可能面临两种故障：

事务参与者发生故障。 给每个事务设置一个超时时间，如果某个事务参与者一直不响应，到达超时时间后整个事务失败，回滚所有操作，这些都是非常耗性能的。

协调者发生故障。 协调者需要将事务相关信息记录到操作日志并同步到备用协调者，假如协调者发生故障，备用协调者可以接替它完成后续的工作。如果没有备用协调者，协调者又发生了永久性故障，事务参与者将无法完成事务而一直等待下去，一旦事务管理器挂掉，资源管理器则一直等待事务管理器的命令。这时候可能就需要使用备份的事务管理器来接替原来事务管理器的工作。

总而言之，两阶段提交协议是阻塞协议，执行过程中需要锁住其他更新，且不能容错，大多数分布式存储系统都采用敬而远之的做法，放弃对分布式事务的支持。

补偿：

事务失败可以进行一些自动或者手动的补偿机制，例如支付成功但是没货了，可以进行退款流程，在这之间不强调强一致性。

参考资料：

Mysql数据库分布式事务XA详解