一致性问题以及特殊情况下的解决方法

一致性就是相互独立的节点之间如何达成一项决议的问题

假设一个具有 N 个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：

1. 全认同(aggreement)：所有 N 个几点都认同一个结果

2. 值合法(validity)：该结果必须由 N 个节点中的节点提出

3. 可结束(termination)：决议过程在一定时间内结束，不会无休止的进行下去

看似很简单，但实现起来并不轻松，因为面临着以下几个问题：

• 消息传递异步无序(asynchronous)：现实网络不是一个可靠的信道，存在消息延时，丢失，节点间消息传递做不到同步有序(synchronous)

• 节点宕机(fail-stop)：节点持续宕机，不会恢复

• 节点宕机恢复(fail-recover)：节点宕机一段时间后恢复，在分布式系统中较为常见

• 网络分化(network partition)：网络链路出现问题，将 N 个节点隔离成多个部分

• 拜占庭将军问题(byzantine failure)：节点或宕机或逻辑失败，甚至不按套路抛出干扰决议的信息

问题

1. 异步环境(asynchronous) 下，节点宕机(fail-stop)

2. 异步环境(asynchronous) 下，节点宕机恢复(fail-recover)、网络分化(network partition)

2PC 解决单节点宕机

节点包括 coordinator 和 participants

在不宕机的情况下可以满足一致性

在第一阶段出了问题，回滚就完事儿了

主要是在第二阶段

coordinator 宕机：会有 watchdog 作为监听备份，query 其他的 participants 来确定最终的命令是什么，继续执行。

participants 宕机：与前面类似

但是，在 Phase2 出现了协调者和参与者都挂掉的情景

Coordinator 刚发出一个请求给其中一个 Participant，此时并没有发送给其他的 Participants 并没有收到消息，此时，前面两者宕机，备用 Coordinator 并不能通过其他的 Participants 来判断那个宕机的 Participant 是什么状态 A.commited B.rollback C.propose 所以一旦其他 participants 的操作与宕机的那个不一致，则会造成数据的不一致，所以会造成堵塞

3PC

三阶段即 propose、precommit、commit 这三个阶段，

其中有 watchdog 和 状态记录(logging) 的应用

Phase1：如果 coordinator 未收到 participant(宕机) 的 vote，则中止事务

Phase2：如果未收到 participant(宕机)，因为已经投票了，不然不能进入 Phase2，所以继续 commit，participant 恢复后自行查看 Log 来决定是否 commit

Phase3：同上

3PC 解决了 2PC 的阻塞(不用摇摆判断是否 commit 还是 abort)，还增加了宕机恢复后的处理。

参考资料 分布式系统理论基础 - 一致性、2PC和3PC