
共识
|
257
冲突的提案,并回复自己的命令日志 {1}。
•
P
5
更新其本地依赖列表,并发送一条消息 Accept(2,{1}) 以确保各副本包含相同
的依赖关系。等到各副本响应后,它便可以提交该值。
图
14-8
:
EPaxos
的算法执行
两个命令 A 和 B 仅当它们的执行顺序影响执行结果时互相干扰,换句话说,先做 A 再做
B 和先做 B 再做 A 会产生不同的结果。
上述步骤完成后,领导者响应客户端命令,并用 Commit 消息异步通知各个副本来完成
提交。提交
之后
命令才被执行。
由于在预接受阶段已经收集了依赖关系,因此在执行请求时,命令间的顺序已经确定,
命令之间不会突然冒出别的命令:新命令只会被追加到序列号最大的命令
之后
。
执行命令时,副本将构建一张依赖关系图,以反向依赖关系的顺序执行所有命令。换
句话说,在执行一条命令之前,必须先执行它所有的依赖项(包括间接依赖项)。考虑
到只有互相干扰的命令才存在依赖,因此这种情况对于大多数工作负载来说应该相对
罕见 [MORARU13]。
类似于 Paxos,EPaxos 也使用提案编号来防止传播过期的消息。序列号由
epoch
(当 前
集群配置的标识符,当有节点离开或加入时会变化)、单调递增的节点本地计数器和副本
ID 构成。如果副本收到的提案序列号小于已经见过的序列号,它将拒绝该提案,并回复
已知的最大序列号以及更新过的命令列表。
14.3.7
柔性
Paxos
Quorum 通常被定义为多数派的进程。根据定义,无论我们如何选择节点,两个 Quorum
间必然存在