cassandra - 了解 Cassandra Paxos 实现

标签 cassandra paxos

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

  1. Prepare/Promise
  2. Read/Results
  3. Propose/Accept
  4. Commit/Acknowledge

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

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

A proposer prepares by sending a message to a quorum of acceptors that includes a proposal number. Each acceptor promises to accept the proposal if the proposal number is the highest they have received. Once the proposer receives a quorum of acceptors who promise, the value for the proposal is read from each acceptor and sent back to the proposer. The proposer figures out which value to use and proposes the value to a quorum of the acceptors along with the proposal number. Each acceptor accepts the proposal with a certain number if and only if the acceptor is not already promised to a proposal with a high number. The value is committed and acknowledged as a Cassandra write operation if all the conditions are met.

我没能理解这个解释。谁能用更清楚的方式解释一下?

最佳答案

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

算法有多个阶段,第一个是
准备/ promise

Prepare Promise Stage

在Paxos中,请求是按照特定的顺序执行的,所以我们想为每个请求分配一个序列号,请求将根据序列号的顺序执行。

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

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

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

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

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

提议/接受

Prop

如果提议者收到对其准备请求的响应 (编号为 n)来自大多数接受者,然后它发送一个接受 向每个接受者请求编号为 n 的提案 值 v,其中 v 是其中编号最高的提案的值 响应,或者如果响应报告没有提案(新条目)则为任何值。

如果接受者收到对编号为提案的接受请求 n, 它接受提议,除非它已经响应了一个 prepare 编号大于 n 的请求。

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

Cassandra 的特定变化:

读取/结果

enter image description here

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

提交/确认

enter image description here

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

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

这个话题很难一一回答,但我会推荐你​​阅读this .

关于cassandra - 了解 Cassandra Paxos 实现,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57038300/

相关文章:

cassandra - Cassandra 中的一对多映射

distributed-system - 领导选举的 paxos vs raft

implementation - 关于 Paxos 和论文 Paxos Made Simple 的说明

cloud - 顾客值(value)选择

基于 Cassandra 的队列是一种反模式。解决办法是什么?

java - 通过字段 'personRepository' 表示的不满足的依赖关系;嵌套异常是 org.springframework.beans.factory.BeanCreationException :

nosql - 使用 cql 在 cassandra 中将值设置为 null

cassandra - 试图登录到 cassandra 的控制台 (cqlsh) 并且它拒绝了我

angularjs - Node.js 的共识算法

distributed-system - 分布式系统的好书