Paxos 和 Cassandra 中的 W+R>=N 有啥区别？

Posted 2023-03-10

【中文标题】Paxos 和 Cassandra 中的 W+R>=N 有啥区别？

【英文标题】：Whats the difference between Paxos and W+R>=N in Cassandra?Paxos 和 Cassandra 中的 W+R>=N 有什么区别？

【发布时间】：2012-08-22 19:10:45

【问题描述】：

类 Dynamo 数据库（例如 Cassandra）可以通过 quorum 强制一致性，即应以 W+R 的方式选择同步写入的副本数 (W) 和要读取的副本数 (R) >N 其中 N 是复制因子。另一方面，Zookeeper 等基于 PAXOS 的系统也被用作一致的容错存储。

这两种方法有什么区别？ PAXOS 是否提供 W+R>N 模式未提供的保证？

【问题讨论】：

FWIW，Zookeeper 不是基于 Paxos，它是一个两阶段提交协议（没有中止），当主服务器宕机时，它具有单独的自定义领导者选举协议。当然，您可以将其视为 Vertical Paxos 的实现，但最终，所有正确的共识算法都可以映射到 Paxos。

【参考方案1】：

是的，Paxos 提供了类似 Dynamo 的系统及其读写仲裁不提供的保证。不同之处在于如何处理故障以及在写入期间会发生什么。成功写入后，两种系统的行为相似。数据将被保存并可供以后读取（直到被覆盖或删除）等等。

在写入期间和失败后会出现差异。在向最终一致的系统写入内容时，直到您从 W 节点获得成功的答案，然后数据可能已写入某些节点而不是其他节点，并且无法保证整个系统就当前值达成一致。如果您此时尝试读回数据，一些客户端可能会取回新数据和一些旧数据。换句话说，系统不是立即一致的。这是因为写入在这些系统中的节点之间不是原子的。通常有一些机制可以“修复”这样的不一致性，并且“最终”系统将再次变得一致（即读取将再次始终返回相同的值，直到写入新的内容）。这就是为什么它们通常被称为“最终一致”的原因。不一致可能（并且将会）出现，但最终总会得到处理和协调。

使用 Paxos，可以跨节点进行原子写入，因此可以避免节点之间的不一致。 Paxos 算法可以保证非故障节点在任何时间点都不会对写入结果产生分歧。写入要么在任何地方成功，要么在任何地方都不成功。在任何时候都不会出现任何不一致的读取（当然，如果正确实施并且所有假设都成立）。然而，这是有代价的。主要是，系统可能需要延迟一些请求并且在例如太多节点（或它们之间的通信）不工作时不可用。这对于确保没有给出不一致的答复是必要的。

总结一下：主要区别在于类似 Dynamo 的系统可以在写入期间或失败一段时间后返回不一致的结果（但最终会从中恢复），而基于 Paxos 的系统可以保证永远不会出现任何此类不一致有时不可用并延迟请求。

【参考方案2】：

Paxos 实现起来并不简单，而且价格昂贵，以至于许多使用它的系统也使用提示，或者仅将它用于领导选举，或其他什么。但是，它确实在出现故障的情况下提供了保证的一致性——当然要受到其特定故障模型的限制。

我看到的第一个基于仲裁的系统假定某种领导者或事务基础设施可以确保足够的一致性，您可以相信仲裁机制有效。这个基础设施很可能是基于 Paxos 的。

查看诸如https://cloudant.com/blog/dynamo-and-couchdb-clusters/ 之类的描述，Dynamo 似乎不是基于保证其仲裁系统一致性的基础设施 - 那么它是非常聪明还是偷工减料？根据http://muratbuffalo.blogspot.co.uk/2010/11/dynamo-amazons-highly-available-key.html，“Dynamo 系统强调可用性到牺牲一致性的程度。摘要中写着“Dynamo 在某些故障场景下牺牲了一致性”。实际上，后来很明显，Dynamo 即使在没有故障的情况下也牺牲了一致性：Dynamo在存在多个并发写入请求的情况下可能会变得不一致，因为副本可能会因多个协调器而分歧。” （结束引用）

因此，在 Dynamo 中实现的仲裁情况下，Paxos 提供了更强的可靠性保证。

【参考方案3】：

Paxos 和 W+R>N quorum 尝试解决略有不同的问题。 Paxos 通常被描述为一种复制状态机的方式，但实际上它更像是一个分布式日志：写入日志的每一项都得到一个索引，不同的服务器最终持有相同的日志项 + 其索引。 （复制状态机可以通过将状态机的输入写入日志来实现，每个服务器根据它们的索引在约定的输入上重放状态机）。你可以在我写的一篇博文中了解更多关于 Paxos 的信息 here。

W+R>N quorum 解决了在多个服务器之间共享单个值的问题。在学术界它被称为“共享寄存器”。共享寄存器有两个操作：读取和写入，我们期望读取返回之前写入的值。

所以，Paxos 和 W+R>N quorum 存在于不同的域中，并且具有不同的属性（例如，Paxos 保存了一个有序的项目列表）。不过，Paxos 可以用来实现共享寄存器，W+R>N quorum 可以用来实现分布式日志（虽然效率很低）。

综上所述，有时 W+R>N 仲裁并未以“完全稳健”的方式实现，因为它需要不止一轮的通信。因此，在需要低延迟的系统中，W+R>N quorum 的实现可能会提供较弱的属性（例如，冲突的值可以共存）。

综上所述，理论上，Paxos 和 W+R>N 可以达到相同的目标。实际上，这将是非常低效的，并且对于稍微不同的东西，每个都更好。更实际的是，W+R>N 并不总是完全实现，因此为了速度而牺牲了一些一致性属性。

更新：Paxos 支持一个非常普遍的故障模型：消息可以被丢弃，节点可以崩溃和重启。 W+R>N quorum 方案有不同的实现，其中许多假设不太普遍的失败。因此，两者之间的差异还取决于所支持的可能失败的假设。

【参考方案4】：

没有区别。仲裁的定义表明任何两个仲裁的交集都不为空。简单多数法定人数是一个例子而不是一个定义。看看 Lamport 博士后来的论文“Vertical Paxos”，他在其中给出了一些其他可能的 quorum 配置。

多法令 paxos 协议（AKA Multi-Paxos），在稳定状态下它只是两阶段提交。仅当领导者失败时才需要更改选票号码。

Zookeeper 的复制协议 (ZAB) 和 RAFT 都是基于 Paxos 的。区别在于领导者失败后的故障检测和转换。

【讨论】：

Raft 不是基于 Paxos 如下来自“Raft 论文”第一段raft.github.io/raft.pdf

【参考方案5】：

正如其他答案中提到的，在 R+W > N 系统中，写入在所有节点上都不是原子的，这意味着当写入正在进行时（或在写入失败期间），一些节点将具有更新的值，而一些年长的。以 n=3、r=2 和 w=2 的系统为例。为清楚起见，我们假设 3 个节点分别命名为 A、B 和 C。考虑这种情况：正在写入；节点 A 已更新，而 B 和 C 仍在接收更新值的过程中。从 A 和 B 读取的客户端将看到较新的值（使用版本向量或上次写入获胜解决），从 B 和 C 读取的客户端将看到旧值。这种类型的读取不被认为是可线性化的。使用适当的线性化系统（如 Paxos 或 Raft）不会出现此类问题。

【讨论】：

您的答案可以通过额外的支持信息得到改进。请edit 添加更多详细信息，例如引用或文档，以便其他人可以确认您的答案是正确的。你可以找到更多关于如何写好答案的信息in the help center。