撤消仲裁系统中的部分写入

Question

假设一个仲裁系统有 5 个节点，写入和读取的仲裁数为 3。现在，假设客户端发送一个写入请求 w，并且 w 被复制到 2/5 个节点上。 由于我们没有在至少 3/5 个节点上进行复制，我们告诉客户端写入不成功。 现在，紧接着，2 个未复制写入的节点 go 关闭。 因此，在剩余的 3 个节点中，2 个有部分写入，1 个没有。 在这种情况下，系统如何确定部分写入 w 需要撤消，因为它实际上并没有成功完成？

Answer 1

在大多数系统中，3/5 表示该值已被选择且不得撤消。

不同的协议和系统以不同的方式处理这个问题。

在ABD中，下一次读取将从一个节点学习该值并将其传播到其他两个剩余节点。

同样，在Paxos中，下一个提议者将从该节点学习值并将其传播到其他两个节点。 在基于 Paxos 的实际系统中，会有一个系统（可能是 Leader）会产生一个no-op提议，以确保及时传播该值。

在像Raft这样的领导者选举/主副本系统中，领导者将确保传播到副本。 那当然是除非它是死者之一。 在这种情况下，选举过程通常要求新领导者是最新的，在这种情况下，这将包括有争议的值。

Answer 2

这是您在构建分布式系统以检查如何管理未发送到所有需要的节点的故障或事件时需要考虑的常见场景。

领导者有责任确保在事件被视为已提交之前将事件成功发送到定义的最小法定人数[应该有一个带有该事件 ID 哈希码的标志]，并且该事件不符合重试条件。

当请求从分布式系统中获取数据时； 它总是交给领导者，领导者将通过它的哈希码将请求委托给节点附近。 但在委托之前，Leader 必须确保 Commit Flag 为 TRUE（意味着事件被传递到最少定义的节点）。 否则，Leader 可以抛出异常。

此外，Leader 应该在事件上标记一个版本号并保留当前提交的标志版本号。 在检索事件时，Leader 可以比较事件版本以确保所有节点都提供最新和最好的数据。

您可以从 Zookeeper 等系统中看到开箱即用的功能。