分布式协调系统 Chubby

未知
未知
2014-08-17
红薯

MapReduce 很多人已经知道了,但关于Chubyy似乎熟悉它的就非常有限,这倒是不奇怪,因为MapReduce是一个针对开发人员的 ProgrammingModel,自然会有很多人去学习它,而Chubby更多的是一种为了实现MapReduce或者Bigtable而构建的内部的 工具,对于开发人员来说基本上是透明的。文献[1]我反复读了至少有两三天,但感觉也只是一个囫囵吞枣的结果,里面有很多工程实现上的细节,如果不是自己 亲自去设计或者实现,很难体会到其中的道理和奥妙。但是,对于这样一个分布式service的研究,还是让我对一个分布式系统的结构和设计思想有了更加直 观的感觉。

从distributed consensus problem说起

distributed consensus problem(分布的一致性问题)是分布式算法中的一个经典问题。它的问题描述大概是这样的:在一个分布式系统中,有一组的Process,它们需要确 定一个Value。于是每个Process都提出了一个Value,consensus就是指只有其中的一个Value能够被选中作为最后确定的值,并且 当这个值被选出来以后,所有的Process都需要被通知到。
表面上看,这个问题很容易解决。比如设置一个server,所有的process都 向这个server提交一个Value,这个server可以通过一个简单的规则来挑选出一个Value(例如最先到达的Value被选中),然后由这个 server通知所有的Process。但是在分布式系统中,就会有各种的问题发生,例如,这个server崩溃了怎么办,所以我们可能需要有几台 server共同决定。还有,Process提交Value的时间都不一样,网络传输过程中由于延迟这些Value到达server的顺序也都没有保证。
为 了解决这个问题,有很多人提出了各种各样的Protocol,这些Protocol可以看做是一组需要遵循的规则,按照这些规则,这些Process就能 够选举出一个唯一的Value。其中,最有名的一个Protocol就是Paxos算法。(八卦一下,Paxos的提出者叫做Lamport,有很多分布 式的算法都是他提出的,他还是Latex的作者,大牛啊...)。想更加了解Paxos算法可以参考文献[2],很漂亮的一篇文章。

那么 这些和Chubby有什么关系呢?其实Chubby就是为了这个问题而构建出来的。只是它并不是一个Protocol或者是一个算法,而是google精 心设计的一个service。这个service不仅能够解决一致性问题,还有其它的一些很实用的好处,会在下文慢慢介绍。

一个实例

在Google File System(GFS)中,有很多的server,这些server需要选举其中的一台作为master server。这其实是一个很典型的consensus问题,Value就是master server的地址。GFS就是用Chubby来解决的这个问题,所有的server通过Chubby提供的通信协议到Chubby server上创建同一个文件,当然,最终只有一个server能够获准创建这个文件,这个server就成为了master,它会在这个文件中写入自己 的地址,这样其它的server通过读取这个文件就能知道被选出的master的地址。

Chubby是什么


从 上面的这个实例可以看出,Chubby首先是一个分布式的文件系统。Chubby能够提供机制使得client可以在Chubby service上创建文件和执行一些文件的基本操作。说它是分布式的文件系统,是因为一个Chubby cell是一个分布式的系统,一般包含了5台机器,整个文件系统是部署在这5台机器上的。
但是,从更高一点的语义层面上,Chubby是一个 lock service,一个针对松耦合的分布式系统的lock service。所谓lock service,就是这个service能够提供开发人员经常用的“锁”,“解锁”功能。通过Chubby,一个分布式系统中的上千个client都能够 对于某项资源进行“加锁”,“解锁”。
那么,Chubby是怎样实现这样的“锁”功能的?就是通过文件。Chubby中的“锁”就是文件,在上例 中,创建文件其实就是进行“加锁”操作,创建文件成功的那个server其实就是抢占到了“锁”。用户通过打开、关闭和读取文件,获取共享锁或者独占锁; 并且通过通信机制,向用户发送更新信息。

综上所述,Chubby是一个lock service,通过这个lock service可以解决分布式中的一致性问题,而这个lock service的实现是一个分布式的文件系统。

可能会有人问,为什么不是直接实现一个类似于Paxos算法这样的Protocol来解决一致性问题,而是要通过一个lock service来解决?文献[1]中提到,用lock service这种方式有几个好处:
1. 大部分开发人员在开始开发service的时候都不会考虑到这种一致性的问题,所以一开始都不会使用consensus protocol。只有当service慢慢成熟以后,才开始认真对待这个问题。采用lock service可以使得在保持原有的程序架构和通信机制的情况下,通过添加简单的语句就可以解决一致性问题;
2. 正如上文实例中所展现,很多时候并不仅仅是选举出一个master,还需要将这个master的地址告诉其它人或者保存某个信息,这种时候,使用 Chubby中的文件,不仅仅是提供锁功能,还能在文件中记录下有用的信息(比如master的地址)。所以,很多的开发人员通过使用Chubby来保存 metadata和configuration。
3. 一个基于锁的开发接口更容易被开发人员所熟悉。并不是所有的开发人员都了解consensus protocol的,但大部分人应该都用过锁。
4. 一个consensus protocol一般来说需要使用到好几台副本来保证HA(详见Paxos算法),而使用Chubby,就算只有一个client也能用。
可以看出,之所以用lock service这样的形式,是因为Chubby不仅仅想解决一致性问题,还可以提供更多更有用的功能。事实上,Google有很多开发人员将Chubby当做name service使用,效果非常好。

加载中

评论(2)

老盖
老盖
这就是zookeeper的原型? Chubby
Ryan-瑞恩
Ryan-瑞恩
!!! #Chubby#

暂无资讯

暂无问答

Google利器之Chubby

写完了Google Cluster,该轮到Chubby了。 参考文献: [1] The Chubby lock service for loosely-coupled distributed systems [2] Paxos Made Simple 声明 文中大部分的观点来自于文献[1]中的...

2014/11/28 11:37
43
0
Paxos的工程实践

Chubby 大名鼎鼎的分布式锁 GFS、Bigtable 都用他来解决分布式协助问题、元数据存储、Master选举等一系列问题 底层一致性实现就是Paxos Chubby 是一个面向松耦合分布式系统的锁服务 提供高可...

2018/11/07 14:18
33
0
微服务架构下的服务注册中心

HTTP & RPC: 两者出发点不同: ①.http是为了解决网络通信的问题; ②.RPC是为了解决服务与服务之间的调用 为什么要使用服务注册中心: 例如一个大型的电商系统要叫进行若干个子系统的拆分(e.g....

08/11 15:00
19
0
十年回顾:Hadoop老矣,尚能饭否?

摘自:易搜社区 http://bbs.easysoo.cn/?p=532 Hadoop,十岁生日快乐!于2006年1月28日诞生的它改变了企业对数据的存储、处理和分析的过程,加速了大数据的发展,形成了自己的极其火爆的技术...

2017/10/20 14:39
2
0
Zookeeper的前世今生

zookeeper简介 Apache zookeeper是一个高性能的分布式协调中间件。设计思想只要源于google chubby,是chubby的一个开源实现,google chubby是一个用来解决分布式一致性的组件,同时也是一个粗...

10/11 18:01
3
0
为什么要使用ZooKeeper

记得在大约在2006年的时候Google出了Chubby来解决分布一致性的问题(distributed consensus problem),所有集群中的服务器通过Chubby最终选出一个Master Server ,最后这个Master Server来协调...

2015/03/19 11:06
146
0
Apache ZooKeeper入门2

作者: H.E. | 您可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明 网址: http://www.javabloger.com/article/zookeeper-hapood-apache.html 记得在大约在2006年的时候Goo...

2010/12/18 16:36
2.5K
0
一致性算法Paxos和Raft

分布式一致性算法Paxos和Raft

2015/07/22 13:57
42
0

没有更多内容

加载失败,请刷新页面

返回顶部
顶部