Zookeeper中的角色主要有以下三c,如下表所C:(x)
1.最l一致性:(x)client不论q接到哪个ServerQ展C给它都是同一个视图,q是zookeeper最重要的性能?/p>
2 .可靠性:(x)h单、健壮、良好的性能Q如果消息m被到一台服务器接受Q那么它?yu)被所有的服务器接受?/p>
3 .实时性:(x)Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息Q或者服务器失效的信息。但׃|络延时{原因,Zookeeper不能保证两个客户端能同时得到刚更新的数据Q如果需要最新数据,应该在读数据之前调用sync()接口?/p>
4 .{待无关Qwait-freeQ:(x)慢的或者失效的client不得q预快速的client的请求,使得每个client都能有效的等待?/p>
5.原子性:(x)更新只能成功或者失败,没有中间状态?/p>
6 .序性:(x)包括全局有序和偏序两U:(x)全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将在消息b前被发布Q偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面?/p>
Zookeeper的核?j)是原子q播Q这个机制保证了(jin)各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两U模式,它们分别是恢复模式(选主Q和q播模式Q同步)(j)。当服务启动或者在领导者崩溃后QZabp入了(jin)恢复模式Q当领导者被选D出来Q且大多数Server完成?jin)和leader的状态同步以后,恢复模式q束了(jin)。状态同步保证了(jin)leader和Serverh相同的系l状态?/p>
Z(jin)保证事务的顺序一致性,zookeeper采用?jin)递增的事务idPzxidQ来标识事务。所有的提议QproposalQ都在被提出的时候加上了(jin)zxid。实Czxid是一?4位的数字Q它?2位是epoch用来标识leader关系是否改变Q每ơ一个leader被选出来,它都?x)有一个新的epochQ标识当前属于那个leader的统L期。低32位用于递增计数?/p>
每个Server在工作过E中有三U状态:(x)
当leader崩溃或者leader失去大多数的followerQ这时候zkq入恢复模式Q恢复模式需要重新选DZ个新的leaderQ让所有的Server都恢复到一个正的状态。Zk的选D法有两U:(x)一U是Zbasic paxos实现的,另外一U是Zfast paxos法实现的。系l默认的选D法为fast paxos。先介绍basic paxos程Q?/p>
通过程分析我们可以得出Q要使Leader获得多数Server的支持,则ServerL必须是奇?n+1Q且存活的Server的数目不得少于n+1.
每个Server启动后都?x)重复以上流E。在恢复模式下,如果是刚从崩溃状态恢复的或者刚启动的serverq(sh)(x)从磁盘快照中恢复数据和会(x)话信息,zk?x)记录事务日志ƈ定期q行快照Q方便在恢复时进行状态恢复。选主的具体流E图如下所C:(x)
选完leader以后Qzkp入状态同步过E?/p>
程囑֦下所C:(x)
Leader主要有三个功能:(x)
PING消息是指Learner的心(j)跳信息;REQUEST消息是Follower发送的提议信息Q包括写h?qing)同步请求;ACK消息是Follower的对提议的回复,过半数的Follower通过Q则commit该提议;REVALIDATE消息是用来g长SESSION有效旉?br />Leader的工作流E简囑֦下所C,在实际实CQ流E要比下囑֤杂得多,启动?jin)三个线E来实现功能?/p>
Follower主要有四个功能:(x)
Follower的消息@环处理如下几U来自Leader的消息:(x)
Follower的工作流E简囑֦下所C,在实际实CQFollower是通过5个线E来实现功能的?/p>
对于observer的流E不再叙qͼobserver程和Follower的唯一不同的地方就是observer不会(x)参加leader发v的投?/span>
http://blog.csdn.net/historyasamirror/article/details/3870168
写完?jin)Google ClusterQ该轮到Chubby?jin)?/span>
参考文献:(x)
[1] The Chubby lock service for loosely-coupled distributed systems
[2] Paxos Made Simple
声明
文中大部分的观点来自于文献[1]中的描述Q但也夹杂了(jin)部分本h自己的理解,所以不能保证本文的正确性。真x(chng)入了(jin)解Chubbyq是好好d版论文吧Q?
前言
MapReduce很多人已l知道了(jin)Q但关于Chubyyg熟?zhn)它的非常有限,q倒是不奇怪,因ؓ(f)MapReduce是一个针对开发h员的ProgrammingModelQ自然会(x)有很多hd?fn)它Q而Chubby更多的是一Uؓ(f)?jin)实现MapReduce或者Bigtable而构建的内部?nbsp;工具Q对于开发h员来说基本上是透明的。文献[1]我反复读?jin)至有两三天,但感觉也只是一个囫囵吞枣的l果Q里面有很多工程实现上的l节Q如果不是自?nbsp;亲自去设计或者实玎ͼ很难体会(x)到其中的道理和奥妙。但是,对于q样一个分布式service的研IӞq是让我对一个分布式pȝ的结构和设计思想有了(jin)更加?nbsp;观的感觉?/span>
从distributed consensus problem说v
distributed consensus problem(分布的一致性问?是分布式法中的一个经兔R题。它的问题描q大概是q样的:(x)在一个分布式pȝ中,有一l的ProcessQ它们需要确 定一个Value。于是每个Process都提Z(jin)一个ValueQconsensus是指只有其中的一个Value能够被选中作ؓ(f)最后确定的|q且 当这个D选出来以后,所有的Process都需要被通知到?/span>
表面上看Q这个问题很Ҏ(gu)解决。比如设|一个serverQ所有的process?nbsp;向这个server提交一个ValueQ这个server可以通过一个简单的规则来挑(xi)选出一个ValueQ例如最先到辄Value被选中Q,然后p个server通知所有的Process。但是在分布式系l中Q就?x)有各种的问题发生,例如Q这个server崩溃?jin)怎么办,所以我们可能需要有几台server共同军_。还有,Process提交Value的时间都不一P|络传输q程中由于gq这些Value到达server的顺序也都没有保证?/span>
?nbsp;?jin)解册个问题,有很多h提出?jin)各U各L(fng)ProtocolQ这些Protocol可以看做是一l需要遵循的规则Q按照这些规则,q些Processp 够选DZ个唯一的Value。其中,最有名的一个Protocol是Paxos法。(八卦一下,Paxos的提?gu)叫做LamportQ有很多分布 式的法都是他提出的Q他q是Latex的作者,大牛?..Q。想更加?jin)解Paxos法可以参考文献[2]Q很漂亮的一文章?/span>
那么 q些和Chubby有什么关pdQ其实Chubby是Z(jin)q个问题而构建出来的。只是它q不是一个Protocol或者是一个算法,而是google_?nbsp;?j)设计的一个service。这个service不仅能够解决一致性问题,q有其它的一些很实用的好处,?x)在下文慢慢介绍?/span>
一个实?/span>
在Google File System(GFS)中,有很多的serverQ这些server需要选D其中的一C为master server。这其实是一个很典型的consensus问题QValue是master server的地址。GFS是用Chubby来解决的q个问题Q所有的server通过Chubby提供的通信协议到Chubby server上创建同一个文Ӟ当然Q最l只有一个server能够获准创徏q个文gQ这个server成Z(jin)masterQ它?x)在q个文g中写入自?nbsp;的地址Q这样其它的server通过dq个文gp知道被选出的master的地址?/span>
Chubby是什?/span>
?nbsp;上面的这个实例可以看出,Chubby首先是一个分布式的文件系l。Chubby能够提供机制使得client可以在Chubby service上创建文件和执行一些文件的基本操作。说它是分布式的文gpȝQ是因ؓ(f)一个Chubby cell是一个分布式的系l,一般包含了(jin)5台机器,整个文gpȝ是部|在q?台机器上的?/span>
但是Q从更高?sh)点的语义层面上,Chubby是一个lock serviceQ一个针Ҏ(gu)耦合的分布式pȝ的lock service。所谓lock serviceQ就是这个service能够提供开发h员经常用?#8220;?#8221;Q?#8220;解锁”功能。通过ChubbyQ一个分布式pȝ中的上千个client都能?nbsp;对于某项资源q行“加锁”Q?#8220;解锁”?/span>
那么QChubby是怎样实现q样?#8220;?#8221;功能的?是通过文g。Chubby中的“?#8221;是文gQ在上例 中,创徏文g其实是q行“加锁”操作Q创建文件成功的那个server其实是抢占C(jin)“?#8221;。用户通过打开、关闭和d文gQ获取共享锁或者独占锁Q?nbsp;q且通过通信机制Q向用户发送更C息?/span>
lg所qͼChubby是一个lock serviceQ通过q个lock service可以解决分布式中的一致性问题,而这个lock service的实现是一个分布式的文件系l?/span>
可能?x)有人问Qؓ(f)什么不是直接实C个类gPaxos法q样的Protocol来解决一致性问题,而是要通过一个lock service来解冻I文献[1]中提刎ͼ用lock serviceq种方式有几个好处:(x)
1.大部分开发h员在开始开发service的时候都不会(x)考虑到这U一致性的问题Q所以一开始都不会(x)使用consensus protocol。只有当service慢慢成熟以后Q才开始认真对待这个问题。采用lock service可以使得在保持原有的E序架构和通信机制的情况下Q通过d单的语句可以解决一致性问题;
2.正如上文实例中所展现Q很多时候ƈ不仅仅是选DZ个masterQ还需要将q个master的地址告诉其它人或者保存某个信息,q种时候,使用Chubby中的文gQ不仅仅是提供锁功能Q还能在文g中记录下有用的信息(比如master的地址Q。所以,很多的开发h员通过使用Chubby来保存metadata和configuration?/span>
3. 一个基于锁的开发接口更Ҏ(gu)被开发h员所熟?zhn)。ƈ不是所有的开发h员都?jin)解consensus protocol的,但大部分人应该都用过锁?/span>
4. 一个consensus protocol一般来说需要用到好几台副本来保证HAQ详见Paxos法Q,而用ChubbyQ就只有一个client也能用?/span>
可以看出Q之所以用lock serviceq样的Ş式,是因为Chubby不仅仅想解决一致性问题,q可以提供更多更有用的功能。事实上QGoogle有很多开发h员将Chubby当做name service使用Q效果非常好?/span>
关于lock serviceQ还有两个名词需要提?qing)?/span>
一 个是advisory lock。Chubby中的lock都是advisory lock。所谓的advisory lockQD个例子,是说当有h某个文仉住以后,如果有其他的人想不解锁而直接访问这个文Ӟq种行ؓ(f)是不?x)被L的。和advisory lock对应的是mandatory lockQ即如果某个文g被锁住以后,如果有其他的人直接访问它Q那么这U行为是?x)生exception的?/span>
?nbsp;一个是coarse-grainedQ粗颗粒度的Q。Chubby的lock service是coarse-grainedQ就是说Chubby中的lock一般锁住的旉都比较长Q可能是几小时或者几天。与之对应的是fined-grainedQ这Ulock一般只l持几秒或者更。这两种锁在实现的时候是?x)有很多不同的考虑的,比如coarse-grained的lock service的负载要很多,因ؓ(f)加锁解锁q不?x)太频繁。其它的差别详见文献[1]?/span>
Chubby的架?/span>
上图是Chubby的系l架构?nbsp;
基本上分Z(jin)两部分:(x)服务器一端,UCؓ(f)Chubby cellQclient一端,每个Chubby的client都有一个Chubby library。这两部分通过RPCq行通信?/span>
client端通过Chubby library的接口调用,在Chubby cell上创建文件来获得相应的锁的功能?/span>
׃整个Chubbypȝ比较复杂Q且l节很多Q我个h又将整个pȝ分ؓ(f)?jin)三个部分?x)
Chubby cell的一致性部?/span>
分布式文件系l部?/span>
client与Chubby cell的通信和连接部?/span>
先从Chubby cell的一致性部分说赗?/span>
一般来_(d)一个Chubby cell׃台serverl成Q可以支持一整个数据中心(j)的上万台机器的lock service?/span>
cell中的每台server我们UC为replicasQ副本)(j)?/span>
当Chubby工作的时候,首先它需要从q些replicas中选DZ个master。注意,q其实也是一个distributed consensus problemQ也是说Chubby也存在着分布式的一致性问题。Chubby是通过采用consensus protocolQ很可能是Paxos法Q来解决q个问题的。所以,Chubby的client用Chubby提供的lock service来解决一致性问题,而Chubbypȝ内部的一致性问题则是用consensus protocol解决的?/span>
每个master都具有一定的期限Q成为master lease。在q个期限中,副本们不?x)再选D一个其它的master?/span>
?nbsp;?jin)安全性和定w的考虑Q所有的replicasQ包括masterQ都l护的同一个DB的拷贝。但是,只有master能够接受client提交的操作对DBq行d写,而其它的replicas只是和masterq行通信来update它们各自的DB。所以,一旦一个master被选D出来后,所有的client端都之和masterq行通信Q如图所C)(j)Q如果是L作,那么master一台机器就搞定?jin),如果是写操作Qmaster?x)通知其它的replicasq行update。这L(fng)话,一旦master意外停机Q那么其它的replicas也能够很快的选D出另外一个master?/span>
再说说Chubby的文件系l?/span>
?nbsp;文说q,Chubby的底层实现其实就是一个分布式的文件系l。这个文件系l的接口是类gUnixpȝ的。例如,对于文g?#8220;/ls/foo /wombat/pouch”Qls表示的是“lock service”Qfoo表示的是某个Chubby cell的名字,wombat/pouch则是q个cell上的某个文g目录或者文件名。如果一个client端用Chubby library来创样一个文件名Q那么这样一个文件就?x)在Chubby cell上被创徏?/span>
Chubby的文件系l由于它的特D用途做?jin)很?nbsp;的简化。例如它不支持文件的转移Q不记录文g最后访问时间等{。整个文件系l只包含有文件和目录Q统一UCؓ(f)“Node”。文件系l采用Berkeley DB来保存Node的信息,主要是一Umap的关pRKey是Node的名字,Value是Node的内宏V?/span>
q有一炚w要提?qing)?nbsp;是,Chubby cell和client之间用了(jin)event形式的通知机制。client在创Z(jin)文g之后?x)得C个handleQƈ且还可以订阅一pd的eventQ例 如文件内容修改的event。这L(fng)话,一旦client相关的文件内容被修改?jin),那么cell?x)通过机制发送一个event来告诉client该文件被 修改?jin)?/span>
最后谈谈client与cell的交互部?/span>
q里大致包含两部分的内容Qcache的同步机制和KeepAlive握手协议?/span>
?nbsp;?jin)降低client和cell之间通信的压力和频率Qclient在本C(x)保存?sh)个和自己相关的Chubby文g的cache。例如如果client通过Chubby library在cell上创Z(jin)一个文Ӟ那么在client本地Q也?x)有一个相同的文g在cache中创建,q个cache中的文g的内容和cell上文件的内容是一L(fng)。这L(fng)话,client如果惌问这个文Ӟ可以直接访问本地的cache而不通过|络去访问cell?/span>
cache有两个状态,有效和无效。当 有一个client要改变某个File的时候,整个修改?x)被master blockQ然后master?x)发送无效标志给所有cache?jin)这个数据的clientQ它l护?jin)这么一个表Q,当其它client端收到这个无效标?nbsp;后,׃(x)cache中的状态置为无效,然后q回一个acknowledgeQ当master定收到?jin)所有的acknowledge之后Q才完成整个modification?/span>
需要注意的是,masterq不是发送updatelclient而是发送无效标志给client。这是因为如果发送updatelclientQ那么每 一ơ数据的修改都需要发送一大堆的updateQ而发送无效标C的话,对一个数据的很多ơ修改只需要发送一个无效标C,q样大大降低?jin)通信量?/span>
至于KeepAlive协议Q则是ؓ(f)?jin)保证client和master随时都保持着联系。client和master每隔一D|间就?x)KeepAlive一ơ,q样的话Q如果master意外停机Qclient可以很快的知道这个消息,然后q速的转移到新的master上。ƈ且,q种转移对于client端的application是透明的,也就是说applicationq不?x)知道master发生?jin)错误。关于cache和KeepAliveq有很多?nbsp;l节Q想?jin)解的读文献[1]吧?/span>
ȝ
其实在我的这文章中Q还有一个很大的主题没有提及(qing)Q那是Chubby的容错机制。基本上Q容错这个思想贯穿?jin)文献[1]的始l,也正是因此,我很隑ְ 它单独提取出来解释,因ؓ(f)它散落在?jin)Chubbypȝ设计的所有角落。我个h感觉Q容错是一个分布式pȝ设计的核?j)思想Q在设计的时候要求考虑到所有可?nbsp;?x)发生的错误Q不仅仅包括?jin)硬件的错误Q网l的故障Q还包括?jin)开发h员可能出现的错误。我惻Iq是我读q篇文章[1]最大的收获?br />
/Files/mysileng/Paxos法深入分析.doc