Multi-Paxos主备复制主序支持问题及相关技术疑问咨询

1. Multi-Paxos无法支持Primary Order的场景 #

Primary Order要求客户端发给主节点的请求，必须按主节点接收的顺序被复制到备节点。Multi-Paxos在以下场景会违反该要求：

• 主节点故障+客户端重传：原主节点处理请求时故障，客户端超时将请求重传到其他节点，新的Proposer（备节点）会提议这些重传请求，后续原主节点恢复并完成未完成请求的共识，导致旧请求的顺序被新请求插队。
• 多Proposer同时活跃：网络分区导致旧主节点未被判定为故障，新主节点又被选出，两个主节点各自处理客户端请求并提议，共识后的顺序和原主节点的接收顺序不一致。
• Proposer自主提议新值：当Proposer在Prepare阶段未收集到多数Acceptor已接受的最高编号值时，会自主提议新的请求值，而非继承之前主节点未完成的请求，打乱原有顺序。

2. Zab论文图1中Proposer2、3提议不同值的诱因解释 #

图1的核心是Paxos允许多个Proposer各自提议不同值，最终导致Primary Order被打破，具体诱因包括：

• 原主节点（Proposer1）故障：Proposer1提议请求X后，可能在Prepare阶段未完成多数Acceptor响应，或在Accept阶段发送部分请求后崩溃，未完成共识。客户端因超时重传请求（或新客户端请求）到Proposer2、3，触发这两个节点成为新的Proposer。
• Proposer的提案规则：Paxos规定，Proposer在Prepare阶段如果未收集到多数Acceptor返回的“已接受的最高编号值”，就可以提议任意值（包括自己接收到的客户端请求）。在图1场景中，Proposer1的X还未被多数Acceptor接受，所以Proposer2、3在Prepare阶段得到的承诺是没有已接受值，因此可以分别提议Y、Z，且先后达成共识。
• 缺乏主节点唯一性约束：原生Multi-Paxos没有强制单一主节点的机制，多个节点可以同时作为Proposer发起提案，各自处理客户端请求，自然会提议不同的值。

后续Proposer1恢复后，继续完成X的共识，最终共识顺序为Y→Z→X，完全违反了Primary Order（原主节点先接收X，应排在最前）。

3. 补充问题解答 #

a. 对Multi-Paxos的修改以支持Primary Order #

要让Multi-Paxos满足主备系统的Primary Order，需要做以下关键修改：

• 新增崩溃恢复阶段：新主节点当选后，先执行日志同步流程，从多数节点获取最新日志状态，将旧主节点未完成的所有请求补全并完成共识，之后再处理新客户端请求。
• 强制单一主节点提案：禁止非主节点作为Proposer发起提案，所有请求必须由当前主节点按接收顺序放入队列，依次提议共识。
• 绑定提案编号与主节点ID：让提案编号包含主节点唯一标识，确保新主节点的提案编号必然大于旧主节点，且新主节点在提案前必须确认旧主节点的所有提案已处理或作废。
• 日志严格顺序约束：主节点维护的日志必须严格按请求接收顺序追加，新主节点同步日志后，必须保证日志的连续性和顺序性，再对外提供服务。

b. 原生Multi-Paxos是否支持客户端请求线性化 #

原生Multi-Paxos不支持客户端请求的线性化。原因如下：

• 线性化要求所有请求的执行看起来像是在某个单点时间完成，且符合实时的发送顺序，但原生Multi-Paxos允许多个Proposer同时提案，共识后的顺序可能和客户端发送的实时顺序不符。
• 原生Multi-Paxos没有处理客户端重复请求的机制，超时重传的请求可能被多次共识，导致同一请求被执行多次。
• 缺乏主节点唯一性保障，多个主节点同时处理请求时，无法保证请求的全局顺序符合线性化要求。

若要支持线性化，需在原生Multi-Paxos基础上添加客户端请求去重、单一主节点强制、请求顺序绑定等额外机制。

内容的提问来源于stack exchange，提问作者user1532146