multi paxos的疑问

OceanBase
#1

一轮具体的 Multi-Paxos 流程如下：

  • 选举协议从所有副本中选择出一个 Leader 节点，作为 Proposer；
  • Proposer 选择一个 ProposalID 对所有日志进行 Prepare； Follower 节点（也是协议中的 Acceptor）收到后进行检查：
  • 如果未收到过更大 ProposalID 的请求，则接受此 Prepare 消息，并回复 LocalMaxLogID;
  • 否则直接忽略此请求;
  • Reconfirm: Proposer 收到多数派 Acceptor 对 Prepare 的响应，选取响应中 LocalMaxLogID 最大值，记做 ReconfirmMaxLogID，假设本地最大确认 LogID 为 K，对于 [K+1, ReconfirmMaxLogID] 范围内所有日志，通过 Prepare/Accept 两阶段重新执行 Paxos 协议流程;
  • Leader Active: Reconfirm 完成后，切换到此状态提供数据的读写服务；

有两个疑问需要请教，
1、Proposer就是leader，leader的日志一般会比较新，通常来说K值会比ReconfirmMaxLogID更大，为什么是同步[K+1, ReconfirmMaxLogID] 范围内所有日志
2、通过 Prepare/Accept 两阶段重新执行 Paxos 协议流程没太清楚，是从来走一遍Prepare/Accept，还是只是走一遍Accept的paxos协商

#3

1、为什么是同步[K+1, ReconfirmMaxLogID] 范围内所有日志?

Proposer/Leader 的日志通常是最新的，但并不总是这样。在分布式系统中，由于网络分区或其他原因，不同节点上的日志可能会出现不一致的情况。当一个新的 Leader 被选举出来后，它需要确保它的日志是所有节点中最新的日志的超集。这就是为什么 Proposer 在 Prepare 阶段收到多数派的响应后，需要检查和同步日志。

如果一个 Acceptor 提供了一个更高的 LocalMaxLogID（即该 Acceptor 已经承诺了一个比当前 Leader 的日志更长的日志序列），Leader 需要同步这些缺失的日志条目，以确保系统的一致性。这就是为什么会同步 [K+1, ReconfirmMaxLogID] 范围内的所有日志条目，这里 K 是 Leader 本地最大确认的 LogID，ReconfirmMaxLogID 是所有回复中最大的 LogID。

2、只走 Accept 还是重新走 Prepare/Accept 流程？

重新执行 Paxos 协议流程相当于对于 [K+1, ReconfirmMaxLogID] 范围内的每个日志条目，Proposer 都要执行一遍 Prepare 和 Accept 这两个阶段。Acceptors 返回的 Prepare 响应中包含了对应日志条目的值，Proposer 会决定用哪个值来补全自身的日志记录。这确保了即使之前某些条目没有被成功提交，新的 Leader 也可以将它们加入到其日志中，从而保证了日志的一致性。

#4

好的，明白了，谢谢
另外还有一个疑问，在2PC中，不同的participants节点中进行的事务变更其实是不一样的，比如logid都到100了，那一个分布式事务接下来都给他们分配的log条目的id是101还是怎样的（但是事实上每个node上的数据变更不同），paxos中日志可以无序，上面的流程中paxos对这种日志的持久化是怎样工作的呢。

#5

还是说每个paxos组都有自己的logid，比如在3.x中如果2pc涉及到多个节点了，那肯定设计到多表或者多分区了，这些表和分区都是一个paxos组，他们会单独走一次paxos提案的协商？

#6

image
image2684×796 182 KB

这个图中，P0和P1的clog持久化可以看作是同时发生的，那它们的logid是怎么分配的，又是怎么通过paxos同步给其他节点的呢？

#7

每个参与者的log id是单独分配的，每一次“持久化日志”就是一次paxos同步的过程，图中的参与者实际上是一个paxos组的leader，在其他节点上还有对应数据的副本。

#8

哦哦，好的，就是每个paxos组都有自己的logid是吗，这样的话在clog中的物理顺序就不重要了。

#9

所以这样的话，在4.x中，paxos组就等于zone的数量，也就是日志流的个数等于zone的数量？如果我是1-1-1的或是3-3-3的集群，就会是3个日志流？