1. Redo Log 同步的核心目标

• ​数据一致性：确保所有副本在事务提交后具有相同的数据视图。
• ​容错性：在主副本故障时，从副本能快速接管并恢复数据。
• ​高吞吐：通过批量同步和并行处理提升效率。

2. Multi Paxos 协议的同步流程

Multi Paxos 协议通过多轮投票机制协调副本间的日志同步。paxos协议用于保证同一个数据分片的多个副本之间的数据一致性。

（1）事务提交阶段

1. ​客户端发起事务：
   客户端向主副本提交事务请求（包含读写操作和 redo log 记录）。

   Client → Leader: {"type": "transaction", "redo_log": [...]}

2. ​主副本处理事务：

   • 主副本执行事务的读写操作，并将 redo log 记录写入本地日志。
   • ​关键动作：主副本作为 ​Proposer，生成包含 redo log 的提案（Proposal）。

（2）提案阶段（Propose Phase）​

• ​广播提案：
  主副本向所有从副本（包括自身）广播提案，包含：
  • ​提案编号​（唯一标识，递增）。
  • ​事务的 redo log。

  Leader → Followers: {"proposal_id": 1, "redo_log": [...]}

（3）投票阶段（Voting Phase）​

• ​从副本投票：
  每个从副本（Acceptor）根据以下规则决定是否接受提案：
  1. ​合法性检查：提案的 proposal_id 必须大于已接受的提案。
  2. ​日志兼容性：redo log 必须与本地已提交日志兼容（如顺序一致）。

  Follower → Leader: {"vote": "accept", "proposal_id": 1}

• ​多数派原则：
  必须获得 ​超过半数​ 的投票（包括主副本自身）才能通过提案。

（4）确认阶段（Commit Phase）​

• ​提交通知：
  主副本收到多数派确认后，广播提交消息给所有副本：

  Leader → All: {"commit": "proposal_id": 1}

• ​应用 Redo Log：
  • 主副本立即应用 redo log 到本地数据。
  • 从副本在收到提交通知后，异步应用 redo log。

​​（5）同步完成

• ​ACK确认：
  从副本向主副本发送确认（ACK），表明 redo log 已应用。

  Follower → Leader: {"ack": "proposal_id": 1}

• ​日志清理：
  主副本删除已提交的 redo log 节点，释放存储空间。

3. 故障恢复与同步

​​（1）主副本失效

• ​故障检测：
  从副本通过心跳机制（如每秒一次）检测主副本活性。若连续丢失心跳，启动 ​故障恢复。

  Follower → Monitor: "Leader heartbeat timeout"

​​（2）新领导者选举

• ​Multi Paxos 重新选举：
  所有存活节点参与新一轮 Multi Paxos 选举：
  1. ​候选者提议：节点依次成为临时领导者，广播提案。
  2. ​投票表决：其他节点投票给最高优先级（如任期最长）的候选者。
  3. ​确认领导地位：获得多数派投票的节点成为新主副本。

​​（3）日志同步恢复

• ​请求缺失日志：
  新主副本向其他从副本查询未提交的 redo log：

  New Leader → Follower: "request_log_range(1, 100)"

• ​同步未提交日志：
  从副本返回缺失的 redo log，新主副本重新广播提交。