consensus - raft算法如何在写入失败后节点故障的情况下保持强读一致性

Question

考虑三个节点(A、B、C)获取键/值数据。并发生了以下步骤

1. 节点 A 接收键:值 (1:15)。这是一个领导者
2. 复制到节点B和节点C
3. 在预提交日志中对节点 B 进行的输入
4. 节点C进入失败
5. 来自节点 B 的 Ack 丢失。
6. Nod A 进入失败并发送失败给客户端
7. 节点A仍然是leader，B不在quorum中
8. 客户端从节点 A 读取键 1 并返回旧值。
9. 节点 A 宕机
10. 节点 B 和节点 C 已启动
11. 现在节点 B 在预提交日志中有一个条目，而节点 C 没有。

此时日志匹配是如何发生的。节点 B 是要提交该条目还是要丢弃它。如果要提交，则读取不一致，或者如果要丢弃，则在其他情况下可能会丢失数据

Answer 1

错误出现在第 8 步。每个读取操作都必须复制到其他节点，否则您可能会遇到过时数据的风险，系统应该在将虚拟值写入日志后提供读取服务。在您的情况下(B 离线)，“读取”必须影响节点 A 和 C，因此当节点 B 重新上线并且 A 死亡，C 将能够使 B 的记录无效。

这是一个棘手的问题，甚至 Etcd 过去也遇到过(现在是 fixed )。