2PC和3PC中故障情况分析

2PC故障情况分析

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

• 发生在第二阶段：无论协调者发起的是提交还是终止，那宕机的参与者在重启之后，都将执行对应操作，不存在不一致情况。
• 发生在第一阶段：由于协调者无法收集到所有参与者的反馈，会陷入阻塞情况。

解决办法：引入超时机制。

• 超过指定时间未收到反馈，事务失败，向所有节点发送终止事务请求。
• 宕机的节点启动后，收到终止事务请求，该事务失败。

小结

简单来说，由于协调者没挂，无论参与者是否宕机，都可以从协调者这里获取正确的状态。

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

无论处于哪个阶段，由于协调者宕机，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况。

解决办法：引入协调者备份，同时协调者需记录操作日志。

• 当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态。
• 如果存在commit或者abort，则对所有节点执行对应的操作。（是不会存在既有commit和abort的情况的）
• 如果只有prepare和未执行，可以继续完成该事务，也可以终止该事务。最终的状态是一致的。

小结

由于参与者正常，引入协调者备份和日志机制后，总能根据日志获取未完成的事务，并向各个参与者查询出对应的状态，并针对性的处理。

3. 协调者、参与者都发生了宕机

首先协调者宕机，那我们需要使用协调者备份，该协调者备份启动后，通过日志找到未完成的事务，对各参与者发起询问。由于参与者存在宕机，我们细分为以下3种情况：
- 存在commit或者abort，则执行对应操作。
- 存在未开始的节点，说明没有节点到第二阶段，可以直接终止。
- 剩下的情况就是：未宕机的节点都是prepare状态。这种情况最复杂，因为无法判断宕机节点的状态，它可能是commit、abort、prepare或者未开始。

下面具体分析第三种情况：
- 如果宕机节点是prepare或者未开始的话，则终止就可以了，这种情况没问题。
- 如果宕机节点是commit或者abort的话，由于该结点的事务已经结束，无法改变，所以对于其他节点必须执行相同的操作，否则就会不一致。但是你不知道该节点到底是什么状态，除非它重新启动了。

小结

出现第三种情况的话，由于无法判断事务状态，则无法完成该事务。该问题无法解决，只能等待参与者恢复，并确认参与者的状态。

3PC故障情况分析

2PC与3PC异同

• 2PC在第一阶段就执行对应操作了（资源被锁定），而第二阶段是提交。
• 3PC第一阶段只是询问能否提交，并不锁定资源；第二阶段再锁定资源执行对应操作；第三阶段是提交。
• 3PC如果第二阶段执行后，超过一定时间未收到协调者信息，会自动提交。

3PC的状态

• 处于第一阶段（CanCommit）：参与者返回YES、NO。
• 处于第二阶段（PreCommit）：协调者如果第一阶段存在NO或者超时则ABORT，如果全部是YES则PREPARE。参与者返回ACK。
• 处于第三阶段（doCommit）：协调者如果第二阶段存在NO或者超时则ABORT，如果全部是ACK则COMMIT。参与者返回ACK。

3PC故障情况分析

这里跳过只有协调者或者只有参与者宕机的情况，这2种情况的解决方案与2PC一致。直接讨论协调者、参与者都发生了宕机，为了简化，假设参与者只宕机了一台。
- 存在COMMIT、ABORT，执行对应操作
- 存在处于第一阶段或者未开始的节点，说明事务未进入第三阶段，直接终止。可能出现宕机节点处于第二阶段的情况，但无论宕机节点是abort或者prepare或者第一阶段或者未开始，都可以执行abort指令。
- 未宕机节点全是prepare状态。如果宕机参与者是PREPARE状态，重启后会收到COMMIT消息，这种没问题。如果是COMMIT状态，也没问题。如果是ABORT状态，由于其他节点变成了COMMIT，此时出现状态不一致。如果是宕机节点未收到PREPARE消息，也就是处于第一阶段完成后，这个时候他只可能是返回YES，重启后收到PREPARE和COMMIT消息后，状态也正确。

总结

我们可以发现3PC使用超时自动提交的方式解决了2PC中无法判断状态需要不断等待的情况，也就是提升了服务可用性。但是3PC比2PC多了一个步骤，所以延时应该是增加了。同时3PC可能存在网络分化情况，也就是协调者在第二阶段发送了PREPARE消息后，如果在第三阶段发送ABORT消息，则如果网络出现问题，导致消息部分节点未送达，就会出现某些节点ABORT了，某些节点COMMIT了。

也就是说，3PC实际并没有解决2PC中的那种协调者和参与者同时宕机的场景，只是做了自动提交，来提升服务可用性。

那2PC能否做自动提交呢？2PC由于只有2个阶段，第一阶段就已经执行对应的操作了（锁资源），如果没有收到第二阶段的COMMIT请求就自动提交，那连一次跟其他节点确认的机会都没有，这样出错的可能性很大。3PC至少是经过第一轮跟其他节点确认后，才会进行超时自动提交的，降低了出错概率。

综上，2PC延迟低，但是参与者故障后可能会阻塞；3PC可用性高，但可能出现数据不一致（网络分化），以及多了个步骤导致延迟会高一些。