cassandra - 理解 Cassandra Paxos 的实现

Question

在 Datastax 的文档中，他们说 Paxos 协议有四个阶段（意思是在轻量级事务中）：

1. 准备/承诺
2. 阅读/结果
3. 提议/接受
4. 提交/确认

而左侧是提议者的阶段，右侧是接受者的阶段。

然后他们试图解释这个过程：

提议者通过向法定人数的接受者发送包含提议编号的消息来进行准备。如果提案编号是他们收到的最高编号，则每个接受者都承诺接受该提案。一旦提议者收到承诺的法定人数的接受者，就会从每个接受者中读取提议的值并将其发送回提议者。提议者确定要使用的值，并将该值连同提议编号一起提交给法定人数的接受者。当且仅当接受者尚未承诺接受具有高数字的提案时，每个接受者都接受具有特定数字的提案。如果满足所有条件，则该值被提交并确认为 Cassandra 写入操作。

我无法理解这个解释。有人可以更清楚地解释一下吗？

标签： cassandrapaxos

Answer 1

Paxos 算法本质上是一种共识算法。假设您有多个协调器 Cassandra 节点，并且所有这些节点都提出了多个更新。Paxos 算法确保在任何给定时间的所有建议更新中，选择单个值并按顺序执行。

算法有多个阶段，第一个阶段是
准备/承诺

在 Paxos 中，请求按特定顺序执行，因此我们希望为每个请求分配一个序列号，并且请求将按照基于序列号的顺序执行。

客户端向领导者发送命令，领导者基本上是 Cassandra 中的协调节点，由领导者决定每个命令应该出现的顺序。

在这个阶段，领导者试图确定请求的正确序列号。如果领导者决定某个客户端命令应该是第 135 个命令，它会尝试将该命令选为共识算法的第 135 个实例的值。

它创建一个值和序列号为 135 的准备请求。其他 Cassandra 节点（副本）将检查数字 135 是否大于他们到目前为止收到的最高数字，如果是，则该节点将返回一个 Promise它不会接受任何其他序列号小于 135 的请求。

它可能因为失败而失败，或者因为另一个服务器也认为自己是领导者并且对第 135 条命令应该是什么有不同的想法。如果一个副本节点已经响应了一个更大数量的准备好的请求，在这种情况下，它会返回一个 promise，但它会返回它响应序列 135 的 promise 的值，这样领导节点也可以知道那个和你的原始请求变为 136。

一旦大多数副本节点向领导者返回了一个承诺，则执行下一阶段。

提议/接受

如果提议者从大多数接受者那里收到对其准备请求（编号为 n）的响应，那么它会向这些接受者中的每一个发送一个接受请求，以获取编号为 n 且值为 v 的提议，其中 v 是最高-响应中的编号提案，或者如果响应报告没有提案（新条目），则为任何值。

如果一个接受者收到一个编号为 n 的提议的接受请求，它会接受该提议，除非它已经响应了准备编号大于 n 的请求。

这就是确保命令按顺序执行的方式。

Cassandra 的具体变化：

阅读/结果

所有 Cassandra-Paxos 查询都是比较和交换查询。服务器检查现有值并基于该更新使用新值。例如，增量计数器操作可能需要它。此阶段读取列的现有值并返回结果。

提交/确认

在这个阶段，发生了对存储的实际写入。在每个副本都接受了提案后，他们仍然需要将其写入存储。因此副本将接受的值写入 Cassandra 存储并向领导者发送确认。

老实说，我认为当你的领导节点数量非常少（可能是 2 个）时，这个系统是最有效的。在 Cassandra 的情况下，由于每个节点都可以在任何时间点成为领导节点，因此系统中可能存在很多低效率。

这个话题很难用一个答案来解释，但我会推荐你​​阅读这个。