在Datastax的文档中,他们说Paxos协议有四个阶段(这意味着在轻量级事务中):
- 准备/承诺
- 读取/结果
- 提议/接受
- 提交/确认
在左侧是提议者的阶段,在右侧是接受者的阶段。
然后他们尝试解释该过程:
提议者通过向法定人数的接受者发送消息来进行准备, 包括投标编号。每个接受者承诺接受 如果提案编号是他们收到的最高编号。 一旦提案人收到承诺的法定人数, 从每个接受者读取提案的值,并将其发送回给 提议者。提议者找出要使用的价值并提出建议 提案数量以及法定人数的接受者。 每个接受者在且仅当以一定数量接受提议 如果尚未答应接受方提出较高的建议 数。该值已提交并作为Cassandra写入确认 如果满足所有条件,则进行操作。
我听不懂这个解释。有人可以更清楚地解释吗?
答案 0 :(得分:0)
Paxos算法本质上是一种共识算法。假设您有多个协调器Cassandra节点,并且所有这些节点都在提议多个更新。 Paxos算法可确保在任何给定时间在所有建议的更新中选择单个值并按顺序执行。
算法有多个阶段,第一个阶段是
准备/承诺
在Paxos中,请求以特定顺序执行,因此我们希望为每个请求分配一个序列号,并且请求将基于序列号以该顺序执行。
客户将命令发送给领导者,领导者基本上是Cassandra中的协调器节点,领导者决定每个命令应出现的顺序。
在此阶段,领导者尝试确定请求的正确序列号。如果领导者决定某个客户命令应该是第135 命令,它将尝试选择该命令作为第135个值 共识算法的实例。
它将创建一个准备请求,其值和序列号为135。其他Cassandra节点(副本)将检查数字135是否大于它们迄今为止所收到的最高数目,如果是,则该节点将返回一个承诺,它将不接受序列号小于135的任何其他请求。
它可能由于失败而失败,或者是因为另一台服务器也认为自己是领导者,并且对第135条命令的含义有所不同。如果副本节点已经响应了较大数目的准备好的请求,那么在这种情况下,它会返回一个promise,但是其promise的值是它对序列135做出的响应,以便领导节点也可以知道该请求和您的原始请求变成136。
一旦副本节点的多数已经向Leader返回了承诺,则执行下一个阶段。
提议/接受
如果提议者收到对其准备请求的答复 (编号为n)来自大多数接受者,然后它发送接受 向每个接受者请求编号为n的提案 值v,其中v是编号最高的提案中的值 答复,或者如果答复未报告任何建议(新条目),则为任何值。
如果接受方收到对编号为的投标的接受请求 n,除非已对准备工作做出回应,否则它将接受该建议 该请求的数字大于n。
这是确保命令按顺序执行的方式。
老实说,我认为当您的领导节点数量很少(可能为2个)时,此系统效率最高。在Cassandra的情况下,由于每个节点在任何时间点都可以成为领导节点,因此系统中可能存在很多效率低下的情况。
这个主题很难用一个答案来解释,但是我建议您阅读this。