《The Chubby lock service for loosely-coupled distributed systems》阅读笔记

Chubby架构

一个Chubby的cell一般由5个节点组成，并利用Paxos算法选举出一个master节点，客户端通过chubby库和master节点通信。Chubby内部维护了一个文件系统，文件系统中的每个文件都可以看成一个锁。其它服务利用Chubby选主时，谁先获得文件的锁，谁就master节点。

(1) 客户端利用Chubby选主

chubby提供了一系列操作文件系统的接口，利用chubby进行选主时，所有的节点调用Open()和Acquire()加锁，加锁成功的节点成为主节点，其它节点成为从节点。所有的节点都能打开文件成功，并获得一个handle。主节点将其标识写入到锁文件(告诉其它节点，我现在是主节点)，其它节点既可以通过GetContentsAndStat()接口主动获取内容，或者由文件更改事件机制通知给从节点。

(2) 文件系统维护

论文提到Chubby最开始使用Berkeley DB维护文件系统，路径名作为key，文件内容作为value。Berkeley DB使用分布式一致性协议将数据块复制到其它节点上。后期，Chubby开发人员使用write ahead log和快照机制实现了一个简单的数据块。(但是用数据库实现文件系统，遇到追加的情况，难道需要把value先读取出来，在内容中拼接在一起，然后再写到磁盘中吗？)

(3) Chubby 重新选主后，客户端如何知道新的master节点？

客户端通过向DNS中列出的副本发送master位置查询请求，来获得master位置信息。如果有任何一个副本故障，新加入的节点都会更新DNS列表，用新节点的IP地址代替故障的节点。master服务器会周期性地轮询DNS列表，因此会很快感知服务器地址的变更，然后Master就会将集群数据库中的地址列表做相应的变更，集群内部的其他副本服务器通过复制方式就可以获取到最新的服务器地址列表了。

(4) 一个客户端节点占有锁L，并发出请求R，还没等R到达服务器，客户端就故障了，然后另一个节点占有锁L，并执行一些操作，随后先前的请求R又到达，会使数据产生不一致的状态，Chubby如何处理这种情况？

在任何时候，锁持有者都可以请求一个序列器，一个不透明的描述锁在获取后的状态的字符串，不同锁的持有者的锁序列器是不同的。它包含锁的名称、获取锁的模式(独占或共享)和锁的生成号。如果期望操作被锁保护，则客户端应当发送序列器给服务器，服务器会检查序列器，如果不匹配就拒绝请求。
同时，Chubby也提供了一个不太完美，但是更容易减少延迟或者重新排序的请求到达服务器的问题。如果客户端正常释放一个锁，则该锁可以立即被其它客户端获取，然而如果一个锁因为持有者故障或不可访问而被释放，则锁服务器会在一段时间内阻止其它客户端获得该锁，这段时间叫做锁延迟时间，通常是1分钟。

(5) Chubby事件通知机制

Chubby客户端创建handle时能够订阅一些事件，这些事件可以由锁服务器异步的发送给客户端，主要包括：

文件内容更改
子节点增加、移除、梗概
Chubby master故障
handle无效
加锁成功
锁冲突
事件通知可以避免客户端不断询问服务器，减少了网络的压力。但是事件通知仅仅是通知事件的发生，比如，客户端收到文件内容更改事件后，仍然需要发起读请求去读取新的内容。文件内容更改的一个应用场景是获得主节点，当所有客户端进行选主时，都会订阅一个文件，主节点会向该文件写入本节点的标识，随后备节点都能知道该文件被更改，并主动读取该文件获得主节点的信息。

(6) 缓存

为了减少读传输量，Chubby客户端会缓存文件数据和节点元数据。客户端缓存依靠租约机制维护，并靠master发送的无效标志保持一致性，master保存了可能缓存的客户端列表。当文件数据或者元数据改变时，更改操作暂时阻塞住，master发送无效标志给缓存数据的客户端，满足以下两个条件，操作才会继续执行，(1) 客户端收到了所有带有缓存数据的客户端的回应，(2) 如果一个不能收到部分客户端的回应，就等待缓存租约过期。master发送的无效标志会搭载在keepalives消息上。

(7) 会话和keepalives

一个Chubby会话是Chubby单元和Chubby客户端之间的一种关系，它存在于么某个时间间隔内，并由称做KeepAlives的间歇性地握手来维持。客户端第一次和链接Chubby的master节点时会创建一个会话。每个会话都会有一个租约超时时间，租约超时时间内master不会单方面终止会话。
master在以下三个场景中会延长租约超时时间：(1) 会话创建时，(2) master故障，(3) 恢复客户端的KeepAlive时。master收到客户端的KeepAlive时，不会立马返回回应，而是阻塞这个RPC请求，直到客户端的上一个租约快过期时才返回回应。客户端收到master的回应后，要立马发送下一个KeepAlive，保证在master段总阻塞了一个KeepAlive请求(这有利于master通知事件给客户端)。
因为master端常常阻塞了一个KeepAlive请求，因此可以利用KeepAlive，向客户端传输事件和缓存无效标志。master允许搭载这些事件的KeepAlive回应消息立马返回给客户端，而不用等到租约快过期。
客户端本地也会维护一个本地的租约超时时间，小于但接近于master租约超时时间，因为客户端必须考虑KeepAlive回应消息的传播时间和master时钟前进的速度。为了保持一致性，要求服务器的时钟前进速度不能快于已知的常数因子，也不能快于客户机的常数因子。如果客户端的本地租约超时时间过期了，客户端会禁止缓存，这时会话处于危险期，客户端等待grace period时间(45s)，如果这段时间内客户端和master重新交换了KeepAlive，客户端重新开启缓存，否则客户端认为会话已经过期。

(8) 故障切换

如图所示，客户端开启一个lease C1，并向master发生keepalive(1)，master给该客户端再维护一个master lease M1，并当M1快结束时回复给客户端ACK(2)，并开启mater lease M2。客户端接收到ACK(2)后，开启lease C2，并向master发送Keepalive(3)。此时master故障，并重新选举。客户端在选举期间一直没有收到master的ACK，于是进入grace period阶段。在客户端处于grace period期间，master选举成功，检查到原先存在的会话，给该客户端开启一个master lease M3，客户端查询到新master的地址，并发送keepalive(4)。随后新master检查客户端发过来的master版本号，不匹配，并发送拒绝消息(5)。客户端收到拒绝消息后，以新master的版本号发送keepalive(6)，maser接收到keepalive后并不开启新的master lease，因此M3是一个保守值，足以在C3结束之前回复客户端ACK。随后客户端收到keepalive ACK(7)，开启客户端lease C3,并发送keepalive(8)。
新master在选举期间，客户端什么时候会向新master发送keepalive，是仅仅在grace period期间吗？这样的话如果还没进入grace period，选举就结束了，客户端不就白白等了一段时间。