先决条件：两阶段提交协议
在两阶段提交协议中，参与分布式事务的站点和全局管理整个事务的协调器可能会失败或崩溃，这可能导致整个事务失败。因为如果任何一个站点失败，为了成功提交分布式事务需要一致同意，所以整个事务将被中止。
在两阶段提交协议中可能会遇到以下类型的失败：
贡献站点的故障——如果协调器(C)检测到站点崩溃，则协调器采取以下措施：
如果站点(Si)在向协调器(C)响应
如果站点在向C发送
当故障站点(Si)从故障中恢复时，站点将检查其日志记录以了解事务 T的命运。不管失败与否——
- 如果日志包含
记录，在这种情况下，站点将执行 。 - 如果日志包含
记录，在这种情况下，站点执行 。 - 一种最重要的情况，如果日志记录包含
， 在这种情况下，站点必须联系协调器(C)。但是，如果C本身失败了，那么在这种情况下，站点 (Si)必须咨询相邻站点并检查它们的日志状态，事务 (T)是否已执行或在其不存在的情况下中止。 - 如果所有站点都无法给出适当的响应，那么在这种情况下，站点 (Si)必须等待协调器恢复或相邻站点的适当响应。
- 因此， Si必须通过向其他站点发送查询消息来定期查询事务 T 的命运。
如果日志中没有关于事务 T 的记录(中止、提交、就绪)，那么我们就知道Si在响应来自Ci 的
协调器失败(Ci)-如果协调器在两阶段提交协议中事务 T的执行过程中失败，则参与站点必须决定事务 T的命运。在某些情况下，参与站点无法决定是提交还是中止事务 T ，因此这些站点必须等待失败的协调器的恢复。
- 如果所有站点的日志中都包含
记录，则必须提交T。 - 如果所有站点的日志中都包含
记录，则 T必须被中止。 - 如果某些站点的日志中不包含
记录，则失败的协调器(C)无法决定提交/中止，因此站点无法响应协调器的 消息 因此最好中止交易而不是等待。 - 如果前面的情况都不成立，则所有活动站点的日志中都有
记录，但由于协调器失败，因此无法找到其他记录，除非协调器，否则无法确定是否已做出提交/中止决定(C)恢复。因此，所有站点都必须等待协调器的恢复。这种情况称为阻塞问题。
The solution to the blocking Problem is Three Phase commit Protocol.
网络分区 –只不过是一种故障，其中网络连接由于故障而在分区或节点之间分裂。当发生网络分区时，可能会出现以下两种情况：
- 协调器和所有参与站点都保持在一个网络分区中，那么网络故障会对提交协议产生影响。
- 如果所有参与站点和协调器都属于两个或多个不同的分区，那么从站点的角度来看，分区没有协调器的站点失败并启动恢复协议，而其他站点则简单地执行其分区包含协调器和遵循通常的2PC 协议。
参考： 亨利科思