【分布式基础】Paxos 算法讲解

简介: 分布式基础: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后只需一轮
  • 实现困难,这是共识算法共有的问题
目录
相关文章
|
4天前
|
算法 关系型数据库 MySQL
分布式唯一ID生成:深入理解Snowflake算法在Go中的实现
在分布式系统中,确保每个节点生成的 ID 唯一且高效至关重要。Snowflake 算法由 Twitter 开发,通过 64 位 long 型数字生成全局唯一 ID,包括 1 位标识位、41 位时间戳、10 位机器 ID 和 12 位序列号。该算法具备全局唯一性、递增性、高可用性和高性能,适用于高并发场景,如电商促销时的大量订单生成。本文介绍了使用 Go 语言的 `bwmarrin/snowflake` 和 `sony/sonyflake` 库实现 Snowflake 算法的方法。
16 1
分布式唯一ID生成:深入理解Snowflake算法在Go中的实现
|
15天前
|
存储 缓存 算法
分布式缓存有哪些常用的数据分片算法?
【10月更文挑战第25天】在实际应用中,需要根据具体的业务需求、数据特征以及系统的可扩展性要求等因素综合考虑,选择合适的数据分片算法,以实现分布式缓存的高效运行和数据的合理分布。
|
16天前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
3月前
|
存储 算法 NoSQL
(七)漫谈分布式之一致性算法下篇:一文从根上儿理解大名鼎鼎的Raft共识算法!
Raft通过一致性检查,能在一定程度上保证集群的一致性,但无法保证所有情况下的一致性,毕竟分布式系统各种故障层出不穷,如何在有可能发生各类故障的分布式系统保证集群一致性,这才是Raft等一致性算法要真正解决的问题。
112 11
|
3月前
|
存储 算法 索引
(六)漫谈分布式之一致性算法上篇:用二十六张图一探Raft共识算法奥妙之处!
现如今,大多数分布式存储系统都投向了Raft算法的怀抱,而本文就来聊聊大名鼎鼎的Raft算法/协议!
114 8
|
3月前
|
存储 算法 Java
(五)漫谈分布式之一致性算法篇:谁说Paxos晦涩难懂?你瞧这不一学就会!
没在时代发展的洪流中泯然于众的道理很简单,是因为它们并不仅是空中楼阁般的高大上理论,而是有着完整落地的思想,它们已然成为构建分布式系统不可或缺的底层基石,而本文则来好好聊聊分布式与一致性思想的落地者:Paxos与Raft协议(算法)。
|
4月前
|
算法 前端开发
|
4月前
|
缓存 算法 NoSQL
Java中的分布式缓存与一致性哈希算法
Java中的分布式缓存与一致性哈希算法
|
4月前
|
算法
分布式篇问题之避免陷入死循环,保证Paxos算法的活性问题如何解决
分布式篇问题之避免陷入死循环,保证Paxos算法的活性问题如何解决
|
4月前
|
存储 算法 Java
分布式自增ID算法---雪花算法(SnowFlake)Java实现
分布式自增ID算法---雪花算法(SnowFlake)Java实现
277 0