哈巴狗

Google Chubby Lock Service阅读笔记

1.简介
Chubby系统提供粗粒度的分布式锁服务，它基于松耦合分布式系统的可靠设计。
Chubby的使用者不需要使用复杂的同步协议，二是直接调用Chubby的锁服务，即可保证数据操作的一致性。
同时这种锁服务是建议性的，而非强制性的，这样能带来更大的灵活性。

Chubby具有广泛的应用场景，例如：
（1）GFS选主服务器；
（2）BigTable中的表锁；

2.背景
Chubby本质上是一个分布式文件系统，存储大量小文件。每个文件就代表一个锁，并且可以保存一些
应用层面的小规模数据。
用户通过打开、关闭、读取文件来获取共享锁或者独占锁；并通过通信机制，向用户发送更新信息。
例如：
一群机器需要选举master时，这些机器同事申请某个锁文件。成功获取锁得服务器当选主服务器，并在文件中写入自己的地址。其他服务器通过读取文件中的数据获取master的地址。

3.系统设计
3.1设计目标
Chubby系统设计的目标基于以下几点：
（1）粗粒度的锁服务；
（2）高可用、高可靠；
（3）可直接存储服务信息，而无需建立和维护另一个服务；
（4）高扩展性；

在实现时，使用了以下特性：
（1）缓存机制：使用一致性缓存，避免客户端频繁访问master；
（2）通信机制：服务器需要及时通知客户端服务变化；

3.2整体架构

chubby-system

图一：Chubby整体架构

如图所示，Chubby系统分为两个重要组件：
（1）Chubby库：客户端通过调用Chubby代码库，申请锁服务，并获取相关信息，同时通过租约保持与服务器的连接；
（2）Chubby服务器组：一个服务器组一般由五台服务器组成，其中一台master，服务维护与客户端的所有通信；
其他服务器不断和主服务器通信，获取用户操作。Chubby服务器组的所有机器都会执行用户操作，并将数据存放到文件系统。

4.系统实现
4.1文件系统
Chubby文件系统类似于简单的unix文件系统，但它不支持文件移动操作与硬连接。
文件系统由许多Node组成，每个Node代表一个文件，或者一个目录。
文件系统使用Berkeley DB来保存每个Node的数据。
文件系统提供的API如下：
FileSystem 创建一个文件系统，包含一个新的Berkeley DB文件；
CreateNewFile 创建文件，如果有路径的话，会自动创建路径
Mkdir 创建路径
Open 打开文件或路径
ReadFile 读取文件
ReadDir 读取路径
Write 写入文件
GetMetaDada 获取元信息
Size 获取文件大小
Delete 删除文件或路径
SyncToDisk 刷内存，将文件系统写入Berkeley DB
SyncFromDisk 将Berkeley DB中的数据同步到内存

4.2基于ICE的Chubby通信机制
一种基于ICE的RPC异步机制，核心就是异步，部分组件负责发送，部分组件负责接收。

4.3客户端与master的通信
要点如下：
（1）长连接保持连接，连接有效期内，客户端句柄、锁服务、缓存数据均一直有效；
（2）定时双向keep alive；
（3）出错回调是客户端与服务器通信的重点。
下面将说明正常、客户端租约过期、主服务器租约过期、主服务器出错等情况。

数据结构的设计：
session和lease是维持客户端与服务器通信的标识，session是一个虚概念，真正起作用的实体是lease。
客户端与master之间的lease的维持是通过定期keep alive来保持的。
session在两端的作用规则不同，故client端得CSession与master server端的SSession结构也有所不同。
CSession主要处理来自master的keep alive消息，该消息可能携带不同事件，CSession的callback函数需要对各事件进行处理，例如节点变更，或失败后重连等。
master端得SSession会保持一个handle，及对其发送相应的消息。
（1）正常情况
keep alive是周期性发送的一种消息，它有两方面功能：延长租约有效期，携带事件信息告诉客户端更新。
事件包括：文件内容修改、子节点增删改、master出错等。
正常情况下，租约会由keep alive一直不断延长。
（2）客户端租约过期
客户端没有收到master的keep alive，租约随之过期，则将会进入一个“危险状态”。
由于此时不能确定master是否已经终止，客户端必须主动让cache失效，同时，进入一个寻找新的master的阶段。
这个阶段中，客户端会轮询Chubby Cell中非master的其他服务器节点，已获得新的视图。
当客户端收到一个肯定的答复时，他会向新的master发送keep alive信息，告之自己处于“危险状态”，并和新的master建立session，
然后把cache中的handler发送给master刷新。一段时间后，例如45s，新的session仍然不能建立，客户端立马认为session失效，将其终止。
当然这段时间内，不能更改cache信息，以求保证数据的一致性。
（3）master租约过期
master一段时间没有收到客户端的keep alive，则其进入一段等待期，此期间内仍没有响应，则master认为客户端失效。
失效后，master会把客户端获得的锁，机器打开的临时文件清理掉，并通知各副本，以保持一致性。
（4）主服务器出错
master出错，需要内部进行重新选举，各副本只响应客户端的读取命令，而忽略其他命令。
新上任的master会进行以下几步操作：
a，选择新的视图编号，不再接受旧master的消息；
b，只处理master位置相关消息，不处理session相关消息；
c，等待处理“危险状态”的客户端keep alive；
d，响应客户端的keep alive，建立新的session，同时拒绝其他session相关操作；同事向客户端返回keep alive，警告客户端master fail-over，客户端必须更新handle和lock；
e，等待客户端的session确认keep alive，或者让session过期；
f，再次响应客户端所有操作；
g，一段时间后，检查是否有临时文件，以及是否存在一些lock没有handle；如果临时文件或者lock没有对应的handle，则清除临时文件，释放lock，当然这些操作都需要保持数据的一致性。

4.4服务器间的一致性操作
这部分考虑的问题是：当master收到客户端的请求时（主要是写），如何将操作同步，以保证数据的一致性。
（1）系统
一般来说，服务器节点数为5，如果临时有节点被拿走，可预期不久的将来就会加进来。
副本个数必须在>=3个以上。
（2）视图
视图的建立，实际上是一个选主的过程。
相互交换服务器之间最后提交的请求，拥有最新请求的服务器为master。
然后master将视图的信息发送给各个服务器，以确保最终各个服务器上的视图信息都是最新的。
（3）复制
服务器接受客户端请求时，master将请求会复制到所有成员，并在消息中添加最新被提交的请求序号。
member收到这个请求后，获取master处被提交的请求序号，然后执行这个序列之前的所有请求，并把其记录到内存的日志里。
由于这个请求没有被master接受，故暂不能执行。
各member会向master发送消息，master收到>=3个以上的消息，才能够进行确认，发送commit给各member，执行请求，并返回客户端。
如果某个member出现暂时的故障，没有收到部分消息也无碍，在收到来自master的新请求后，
主动从master处获得已执行的，自己却还没有完成的日志，并进行执行。
最终，所有成员都会获得一致性的数据，并且，在系统正常工作状态中，至少有3个服务器保持一致并且是最新的数据状态。

4.5Chubby系统锁机制
客户端和服务器除了要保存lease对象外，服务器和客户端还需要保存另一张表，用于描述已经加锁的文件及相关信息。
由于Chubby系统所使用锁是建议性而非强制性的，这代表着如果有多个锁请求，后达的请求会进入锁等待队列，直到锁被释放。

5.Chubby使用例子
5.1选master
（1）每个server都试图创建/打开同一个文件，并在该文件中记录自己的服务信息，
任何时刻都只有一个服务器能够获得该文件的控制权；
（2）首先创建该文件的server成为主，并写入自己的信息；
（3）后续打开该文件的server成为从，并读取主的信息；

5.2进程监控
（1）各个进程都把自己的状态写入指定目录下的临时文件里；
（2）监控进程通过阅读该目录下的文件信息来获得进程状态；
（3）各个进程随时有可能死亡，因此指定目录的数据状态会发生变化；
（4）通过事件机制通知监控进程，读取相关内容，获取最新状态，达到监控目的；

6.总结
Chubby提供粗粒度锁服务，是一个基于松耦合分布式设计的文件系统。
开发者不需要复杂的同步协议，直接调用库来取得锁服务，并保证了数据的一致性。
这种锁是建议性的，而非强制性的，具有更大的灵活性。
为了支持更大规模的访问，使用客户端缓存，减少对master的访问。
客户端与master之间使用keep alive往返机制，保持通讯。
最终Chubby系统代码共13700多行，其中ice自动生成6400行，手动编写约8000行。