了解 Cassandra Paxos 实施

Alo*_*lon 5 cassandra paxos

在 Datastax 的文档中,他们说 Paxos 协议有四个阶段(意思是在轻量级事务中):

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

左边是提议者的阶段,右边是接受者的阶段。

然后他们尝试解释这个过程:

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

我无法理解这个解释。有人可以用更清楚的方式解释一下吗?

Abh*_*arg 9

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

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

准备承诺阶段

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

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

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

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

它可能会因为失败而失败,或者因为另一台服务器也认为自己是领导者并且对第 135 个命令应该是什么有不同的想法。如果副本节点已经响应了更高编号的准备请求,在这种情况下,它会返回一个承诺,但带有它响应序列 135 的承诺值,以便领导节点也可以知道这一点以及您的原始请求变成136。

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

提议/接受

支柱

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

如果接受者收到编号为 n 的提案的接受请求,则它接受该提案,除非它已经响应了编号大于 n 的准备请求。

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

Cassandra具体变化:

读取/结果

在此输入图像描述

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

提交/确认

在此输入图像描述

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

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

这个话题很难用一个答案来解释,但我建议你阅读这篇文章