分布式基础:Paxos算法详解

1.前言

 

  • Paxos算法是莱斯利·兰伯特于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。

  • 产生背景:在常见的 分布式系统 中,总会发生 节点宕机 或 网络异常 (包括消息的 重复、丢失、延迟、乱序、网络分区) 等情况。Paxos 算法主要就是解决如何在一个 发生如上故障 的分布式系统中,快速正确的在集群内 对某个值达成一致,并且保证 整个系统的一致性。

 背景

拜占庭帝国想要进攻一个城市,为此派出了10个将军率领10支军队,这个城市足以抵御5支常规拜占庭军队的同时袭击。这10支军队不能集合在一起单点突破,必须在分开的包围状态下同时攻击,至少6支军队同时袭击才能攻下敌国。10支军队分散在敌国的四周,依靠通信兵相互通信来协商进攻意向及进攻时间。这里的问题是,对应于有的主机坏掉了,将军中可能会有叛徒,忠诚的将军希望达成命令的一致(比如约定某个时间一起进攻),但背叛的将军会通过发送错误的消息阻挠忠诚的将军达成命令上的一致。在这种状态下,拜占庭将军们能否找到一种分布式的协议来让他们能够远程协商,从而赢取战斗?

解决方案

分布式系统中的节点通信存在两种模型:共享内存(Shared memory)和消息传递(Messages passing)。基于消息传递通信模型的分布式系统,不可避免的会发生以下错误:进程可能会慢、被杀死或者重启,消息可能会延迟、丢失、重复,在基础 Paxos 场景中,先不考虑可能出现消息篡改即拜占庭错误的情况。Paxos 算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致,保证不论发生以上任何异常,都不会破坏决议的一致性。

2.Basic-Paxos算法

角色划分:首先将议员的角色分为 proposers,acceptors,和 learners(允许身兼数职)。proposers 提出提案,提案信息包括提案编号和提议的 value;acceptor 收到提案后可以接受(accept)提案,若提案获得多数派(majority)的 acceptors 的接受,则称该提案被批准(chosen);learners 只能“学习”被批准的提案

算法前置条件:

1、决议(value)只有在被 proposers 提出后才能被批准(未经批准的决议称为“提案(proposal)”);

2、在一次 Paxos 算法的执行实例中,只批准(chosen)一个 value;

3、learners 只能获得被批准(chosen)的 value。

算法内容:首先选出一个leader(也就是proposer),proposer提出一个提案前,首先要和足以形成多数派的acceptors进行通信,获得他们进行的最近一次接受(accept)的提案(prepare过程),之后根据回收的信息决定这次提案的value,形成提案开始投票。当获得多数acceptors接受(accept)后,提案获得批准(chosen),由acceptor将这个消息告知learner。这个简略的过程经过进一步细化后就形成了Paxos算法。

算法执行步骤:

1、选择一个节点成为leader/proposer。

2、leader选择一个值,发送到所有的节点(Paxos中称之为acceptor),这个消息被称为“接受请求”消息。acceptor可以回应接受或拒绝。

3、一旦节点中的大多数回应接受,共识就能达成,协调者将“提交”消息发送到所有节点

图解:

 缺点:

  • 易形成活锁,可以使用二进制退避算法解决
  • 效率低,两轮请求,Multi-paxos算法选出leader后只需一轮
  • 实现困难,这是共识算法共有的问题

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

白木Channel

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值