multi paxos协议

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,新主副本重新广播提交。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值