Zookeeper的Paxos分布式一致性算法-类比

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函数返回)。
情况三：
总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明，推选新的总统，总统大选期间政府停业，拒绝屁民的请求。

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转帖整理。

Zookeeper的Paxos分布式一致性算法-类比相关推荐

深入浅出Paxos分布式一致性算法
深入浅出Paxos分布式一致性算法
Paxos分布式一致性算法简介和Apache ZooKeeper的概念映射
为什么80%的码农都做不了架构师?>>> Paxos是一个基于消息传递的一致性算法,近几年被广泛应用于分布式计算中,Google的Chubby,Apache的Zookeeper ...
paxos分布式一致性算法--讲述诸葛亮的反穿越
1. 引子一日,诸葛亮找到刘备,突然献上一曲<独角戏>,而后放声大哭.刘备正沉醉于新曲,暗叹孔明大才,竟作得如此不凡仙乐,看到孔明忽而大悲,慌问:"水,何事悲恸?" ...
CAP原理，分布式一致性算法，两阶段提交，三阶段提交，Paxos，Raft，zookeeper的选主过程,zab协议,顺序一致性,数据写入流程,节点状态,节点的角色
我们知道,一般在分布式应用都有CAP准则: C Consistency, 一致性,分布式中的各个节点数据保持一致 A availability 可用性,任何时刻,分布式集群总是能够提供服务 P par ...
Paxos、Raft分布式一致性算法应用场景
本文是Paxos.Raft分布式一致性最佳实践的第一篇文章,说明分布式一致性问题与分布式一致性算法的典型应用场景,帮助后面大家更好的理解Paxos.Raft等分布式一致性算法. 一.分布式一致性 (C ...
【Raft】分布式一致性算法Raft和zab、paxos
目录前言 Raft算法 Raft动画教程 Raft手动设置模拟 Raft协议说明 Raft和zab区别 paxos算法前言开发面试Zookeeper肯定要问,Zab协议逃不掉,那么和 Raft ...
分布式一致性算法-paxos详解与分析
前言在Paxos算法面前,其他分布式一致性算法都是渣渣,都是残次品.Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品. ...
分布式一致性算法——Paxos 和 Raft 算法
写在前面本文隶属于专栏<100个问题搞定大数据理论体系>,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢! 本专栏目录结构和参考文献请见100个问题搞定大数据理 ...
区块链共识算法(4)分布式一致性算法Paxos
# 分布式一致性算法Paxos Paxos是一种基于消息传递的分布式一致性算法,由Leslie Lamport(莱斯利·兰伯特)于1990提出. 是目前公认的解决分布式一致性问题的最有效算法之一. # ...
从 Paxos 到 Raft，分布式一致性算法解析
导语 | 后台服务架构经过了集中式.SOA.微服务和服务网格四个阶段,目前互联网界大都使用微服务和服务网格.服务从集中式.中心化向分布式.去中心化不断演进,服务也变得更灵活,能够自动扩缩容.快速版本迭 ...

Zookeeper的Paxos分布式一致性算法-类比

Zookeeper的Paxos分布式一致性算法-类比相关推荐

最新文章

热门文章