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

【问题标题】：How raft algorithm maintains strong read consistency in case of write failure followed by a node failureraft算法如何在写入失败后节点失败的情况下保持强读一致性
【发布时间】：2017-10-11 06:48:25
【问题描述】：

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

节点 A 接收键：值 (1:15)。它是一个领导者
它复制到节点 B 和节点 C
预提交日志中节点 B 的条目
节点 C 输入失败
来自节点 B 的确认丢失。
Nod A 输入失败并将失败发送给客户端
节点 A 仍然是领导者，而 B 不在仲裁中
客户端从节点 A 读取键 1 并返回旧值。
节点 A 已关闭
节点 B 和节点 C 已启动
现在节点 B 在预提交日志中有一个条目，而节点 C 没有。

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

【问题讨论】：

标签： consensus raft

【解决方案1】：

错误出现在第 8 步。每个读取操作都必须复制到其他节点，否则您可能会收到过期数据，系统应在将虚拟值写入日志后提供读取服务。在您的情况下（B 处于脱机状态），“读取”必须影响节点 A 和 C，因此当节点 B 重新联机并且 A 死亡时，C 将能够使 @ 无效987654328@的记录。

这是一个棘手的问题，过去甚至 Etcd 都遇到过（现在是 fixed）。

【讨论】：

编写一个虚拟条目并复制它以供读取是有意义的。但它会影响读取的性能。但我想这是进行一致读取的惩罚。
@risabhmittal：是的，这使得读取可以线性化，这是有代价的。另见 PACELC 定理。请注意，有一些 Paxos 变体使用读取租约来授予节点完全在本地进行线性化读取的能力。
@GManNickG 你能说出这些 Paxos 变种的名字吗？据我了解，通过租约是不可能实现的，因为任何系统（硬实时系统除外）都可能随时遇到无法控制的冻结（GC 暂停、虚拟化问题等），因此租约可能会在系统不知道的情况下到期。
请参阅“Paxos Quorum Leases：快速读取而不牺牲写入”，这本质上是一种确保正确遵守租约的结构化方法。事实上，他们的一个假设是，虽然时钟不需要同步，但它们确实需要具有足够相似的漂移率，这样一个简单的等待缓冲区就可以保证在远程节点上检测到租约到期。 [1/2]
在它服务请求之前，你的意思是在发送响应之前但在阅读并验证租约之后？那仍然是可线性化的，对吗？否则，我认为只要您在本地读取后验证您的租约就可以了 - 如果您在两者之间暂停，只要您的硬件时钟仍然上升，您就会检测到您的读取已经过时。如果您使用的是与虚拟机一起暂停的软件时钟，我认为您搞砸了，但我将其重新打包为“获得一个以〜恒定速率滴答作响的时钟”。