Paxos分布式一致性算法简介和Apache ZooKeeper的概念映射

Paxos是一个基于消息传递的一致性算法,近几年被广泛应用于分布式计算中,Google的Chubby,Apache的Zookeeper都是基于它的理论来实现的,Paxos还被认为是到目前为止唯一的分布式一致性算法,其它的算法都是Paxos的改进或简化。Paxos只有在一个可信的计算环境中才能成立,这个环境是不会被入侵所破坏的。

由Leslie Lamport发明了Paxos算法,他目前供职于微软研究院。1998年在ACM Transactions on Computer Systems的《The Part-Time Parliament》论文是Paxos算法第一次公开发表,文本可参考微软研究院地址:http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf。Lamport觉得同行无法接受他的幽默感,于是用容易接受的方法重新表述了一遍,文本可参考微软研究院地址:http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf。

Paxos算法的中文译本可参考这里:http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95。

本文部分内容根据http://www.spnguru.com/?p=232的文字整理,但原地址已失效,所以实际是从这个http://blog.csdn.net/cxhzqhzq/article/details/6568040转帖整理。

Paxos描述了这样一个场景,有一个叫做Paxos的小岛(Island)上面住了一批居民,岛上面所有的事情由一些特殊的人决定,他们叫做议员(Senator)。议员的总数(Senator Count)是确定的,不能更改。岛上每次环境事务的变更都需要通过一个提议(Proposal),每个提议都有一个编号(PID),这个编号是一直增长的,不能倒退。每个提议都需要超过半数((Senator Count)/2 +1)的议员同意才能生效。每个议员只会同意大于当前编号的提议,包括已生效的和未生效的。如果议员收到小于等于当前编号的提议,他会拒绝,并告知对方:你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号,他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。现在议会有一个目标:保证所有的议员对于提议都能达成一致的看法。

现在议会开始运作,所有议员一开始记事本上面记录的编号都是0。有一个议员发了一个提议:将电费设定为1元/度。他首先看了一下记事本,嗯,当前提议编号是0,那么我的这个提议的编号就是1,于是他给所有议员发消息:1号提议,设定电费1元/度。其他议员收到消息以后查了一下记事本,哦,当前提议编号是0,这个提议可接受,于是他记录下这个提议并回复:我接受你的1号提议,同时他在记事本上记录:当前提议编号为1。发起提议的议员收到了超过半数的回复,立即给所有人发通知:1号提议生效!收到的议员会修改他的记事本,将1好提议由记录改成正式的法令,当有人问他电费为多少时,他会查看法令并告诉对方:1元/度。

现在看冲突的解决:假设总共有三个议员S1-S3,S1和S2同时发起了一个提议:1号提议,设定电费。S1想设为1元/度, S2想设为2元/度。结果S3先收到了S1的提议,于是他做了和前面同样的操作。紧接着他又收到了S2的提议,结果他一查记事本,咦,这个提议的编号小于等于我的当前编号1,于是他拒绝了这个提议:对不起,这个提议先前提过了。于是S2的提议被拒绝,S1正式发布了提议: 1号提议生效。S2向S1或者S3打听并更新了1号法令的内容,然后他可以选择继续发起2号提议。

现在让我们来对号入座,看看在ZK Server里面Paxos是如何得以贯彻实施的。

小岛(Island)——ZK Server Cluster

议员(Senator)——ZK Server

提议(Proposal)——ZNode Change(Create/Delete/SetData…)

提议编号(PID)——Zxid(ZooKeeper Transaction Id)

正式法令——所有ZNode及其数据

在所有议员中设立一个总统,只有总统有权发出提议,如果议员有自己的提议,必须发给总统并由总统来提出。

总统——ZK Server Leader

现在我们假设总统已经选好了,下面看看ZK Server是怎么实施的。

情况一:

屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的情况(ZNode的数据),议员毫不犹豫的拿出他的记事本(local storage),查阅法令并告诉他结果,同时声明:我的数据不一定是最新的。你想要最新的数据?没问题,等着,等我找总统Sync一下再告诉你。

情况二:

屁民乙(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱,议员让他在办公室等着,自己将问题反映给了总统,总统询问所有议员的意见,多数议员表示欠屁民的钱一定要还,于是总统发表声明,从国库中拿出一万元还债,国库总资产由100万变成99万。屁民乙拿到钱回去了(Client函数返回)。

情况三:

总统突然挂了,议员接二连三的发现联系不上总统,于是各自发表声明,推选新的总统,总统大选期间政府停业,拒绝屁民的请求。

时间: 2024-08-15 04:09:33

Paxos分布式一致性算法简介和Apache ZooKeeper的概念映射的相关文章

分布式一致性算法——paxos

一.什么是paxos算法 Paxos 算法是分布式一致性算法用来解决一个分布式系统如何就某个值(决议)达成一致的问题. 人们在理解paxos算法是会遇到一些困境,那么接下来,我们带着以下几个问题来学习paxos算法: 1.paxos到底在解决什么问题? 2.paxos到底如何在分布式存储系统中应用? 3.paxos的核心思想是什么? 二.paxos解决了什么问题 分布式的一致性问题其实主要是指分布式系统中的数据一致性问题.所以,为了保证分布式系统的一致性,就要保证分布式系统中的数据是一致的. 在

分布式一致性算法:Raft 算法

Raft 算法是可以用来替代 Paxos 算法的分布式一致性算法,而且 raft 算法比 Paxos 算法更易懂且更容易实现.本文对 raft 论文进行翻译,希望能有助于读者更方便地理解 raft 的思想.如果对 Paxos 算法感兴趣,可以看我的另一篇文章:分布式系列文章--Paxos算法原理与推导 摘要Raft 是用来管理复制日志(replicated log)的一致性协议.它跟 multi-Paxos 作用相同,效率也相当,但是它的组织结构跟 Paxos 不同.这使得 Raft 比 Pax

兄弟连区块链入门到精通教程区块链共识算法分布式一致性算法Raft

Paxos自1990年提出以后,相当长时间内几乎已成为分布式一致性算法的代名词.但因其难以理解和实现,目前知名实现仅有Chubby.Zookeeper.libpaxos几种,其中Zookeeper使用的ZAB对Paxos做了大量改进.为此,2013年斯坦福的Diego Ongaro.John Ousterhout,提出了新的更易理解和实现的一致性算法,即Raft. Raft和Paxos均只要保证n/2+1节点正常,即可服务.相比Paxos,其优势即为易于理解和实现.Raf将算法分解为:选择领导者

分布式一致性算法梳理

分布式一致性算法主流方案:2PC.3PC.leader/follower.paxos 一致性有两种场景: 1.多份相同的数据,在一处修改,保证多份一致 2.一个业务变更多份不同的数据,要保持一致,要成功都成功,要失败都失败 产生不一致的原因: 1.异常操作导致不成功 2.网络分区 3.应用故障 两阶段提交(2PC) 将事务的提交分为准备和提交两个阶段来达成一致性的算法,主要用于事务管理.分布式一致性,两阶段提交需要在更新发起者和参与者中间加一个协调者的角色.具体步骤如下: 1.变更者发起变更申请

Raft 为什么是更易理解的分布式一致性算法

Raft 为什么是更易理解的分布式一致性算法 一致性问题可以算是分布式领域的一个圣殿级问题了,关于它的研究可以回溯到几十年前. 拜占庭将军问题 Leslie Lamport 在三十多年前发表的论文<拜占庭将军问题>(参考[1]). 拜占庭位于如今的土耳其的伊斯坦布尔,是东罗马帝国的首都.由于当时拜占庭罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信差传消息.在战争的时候,拜占庭军队内所有将军必需达成 一致的共识,决定是否有赢的机会才去攻打敌人的阵营.但是,在军队内

【转】Raft 为什么是更易理解的分布式一致性算法

编者按:这是看过的Raft算法博客中比较通俗的一篇了,讲解问题的角度比较新奇,图文并茂,值得一看.原文链接:Raft 为什么是更易理解的分布式一致性算法 一致性问题可以算是分布式领域的一个圣殿级问题了,关于它的研究可以回溯到几十年前. 拜占庭将军问题 Leslie Lamport 在三十多年前发表的论文<拜占庭将军问题>(参考[1]). 拜占庭位于如今的土耳其的伊斯坦布尔,是东罗马帝国的首都.由于当时拜占庭罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信差传消息.

分布式一致性算法2PC和3PC

为了解决分布式一致性问题,产生了不少经典的分布式一致性算法,本文将介绍其中的2PC和3PC.2PC即Two-Phase Commit,译为二阶段提交协议.3PC即Three-Phase Commit,译为三阶段提交协议.? 分布式系统和分布式一致性问题 ? 分布式系统,即运行在多台不同的网络计算机上的软硬件系统,并且仅通过消息传递来进行通信和协调. 分布式一致性问题,即相互独立的节点之间如何就一项决议达成一致的问题.? 2PC ? 2PC,二阶段提交协议,即将事务的提交过程分为两个阶段来进行处理

分布式一致性算法--Paxos

Paxos算法是莱斯利·兰伯特(Leslie Lamport)1990年提出的一种基于消息传递的一致性算法.Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致.在工程实践意义上来说,就是可以通过Paxos实现多副本一致性,分布式锁,名字管理,序列号分配等.比如,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点执行相同的操作序列,那么他们最后能得到一个一致的状态.为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致.本

【转载】Raft 为什么是更易理解的分布式一致性算法

一致性问题可以算是分布式领域的一个圣殿级问题了,关于它的研究可以回溯到几十年前. 拜占庭将军问题 Leslie Lamport 在三十多年前发表的论文<拜占庭将军问题>(参考[1]). 拜占庭位于如今的土耳其的伊斯坦布尔,是东罗马帝国的首都.由于当时拜占庭罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信差传消息.在战争的时候,拜占庭军队内所有将军必需达成 一致的共识,决定是否有赢的机会才去攻打敌人的阵营.但是,在军队内有可能存有叛徒和敌军的间谍,左右将军们的决定又