chubby——用于松耦合分布式系统的锁服务

朱雀 2022-08-18 01:55 557阅读 0赞

**chubby——用于松耦合分布式系统的锁服务**

首先，Chubby是什么？Chubby主要用于解决分布式一致性问题。在一个分布式系统中，有一组的Process，它们需要确定一个Value。于是每个Process都提出了一个Value，一致性就是指只有其中的一个Value能够被选中作为最后确定的值，并且当这个值被选出来以后，所有的Process都需要被通知到。这就是一致性问题。  
       其次，它是一个粗粒度的分布式锁服务。本质上，Chubby是Google设计的提供粗粒度锁服务的文件系统，存储大量小文件。每个文件就代表一个锁。在GFS中，创建文件就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁”。用户通过打开、关闭、读取文件来获取共享锁或者独占锁；并通过通信机制，向用户发送更新信息。一群机器需要选举master时，这些机器同时申请某个锁文件。成功获取锁得服务器当选主服务器，并在文件中写入自己的地址。其他服务器通过读取文件中的数据获取master的地址。其他分布式系统可以使用它对共享资源的访问进行同步。同时这种锁服务是建议性的，而非强制性的，这样能带来更大的灵活性。  
       Chubby的设计目标基于以下几点：高可用性、高可靠性、支持粗粒度的建议性锁服务、支持小规模文件直接存储，这些当然是拿高性能与存储能力tradeoff来的。  
       图1是Chubby的整体架构，容易看出几点。一，Chubby共有5台服务器，其中一个是master，客户端与服务器之间使用RPC交互。我们会问，其他服务器是干什么的？没错，它们纯粹是作为master挂掉后的替代品。Zookeeper的多余服务器均是提供就近服务的，也就是，服务器会根据地理位置与网络情况来选择对哪些客户端给予服务。Chubby的这些Replica并不能提供这类服务。由此可见，Google佬的东西我们也不应该什么都盲目崇拜。Google也坦言，在设计Chubby时是战战兢兢的，生怕master挂掉就大手笔准备了5台。

![Center][]

Master服务端会运行着会话租期计时器，用来管理所有的会话的生命周期，如果Master在运行过程中出现故障，那么该计时器就会停止，直到新的Master选举产生后，计时器才会继续计时，即从旧的Master崩溃到新的Master选举产生所花费的时间将不计入会话超时的计算中，这就等价于延长了客户端的会话租期，如果Master在短时间内就选举产生了，那么客户端就可以在本地会话租期过期前与其创建连接，而如果Master的选举花费了较长的时间，就会导致客户端只能清空本地的缓存而进入宽限期进行等待，由于宽限期的存在，使得会话能够很好地在服务端Master转化的过程中得到维持，整个Master的故障恢复过程中服务端和客户端的交互情况如下

![Center 1][]

如上图所示，一开始在旧的Master服务器上维持了一个会话租期lease M1，在客户端上维持对应的lease C1，同时客户端的KeepAlive请求1一直被Master服务器阻塞着。一段时间后，Master向客户端反馈了KeepAlive响应2，同时开始了新的会话租期lease M2，而客户端在接收到该KeepAlive响应后，立即发送了新的KeepAlive请求3，并同时也开始了新的会话租期lease C2。至此，客户端和服务端的交互都是正常的，随后，Master发生了故障，从而无法反馈客户端的KeepAlive请求3，在此过程中，客户端检测到会话租期lease C2已经过期，它会清空本地缓存并进入宽限期，这段时间内，客户端无法确定Master上的会话周期是否也已经过期，因此它不会销毁它的本地会话，而是将所有应用程序对它的API调用都阻塞住，以避免出现数据不一致的现象。同时，在客户端宽限期开始时，客户端会向上层应用程序发送一个“jeopardy”事件，一段时间后，服务器开始选举产生新的Master，并为该客户端初始化了新的会话租期lease M3，当客户端向新的Master发送KeepAlive请求4时，Master检测到该客户端的Master周期号已经过期，因此会在KeepAlive响应5中拒绝这个客户端请求，并将最新的Master周期号发送给客户端，之后，客户端会携带上最新的Master周期号，再次发送KeepAlive请求6给Master，最终，整个客户端和服务端之间的会话就会再次回复正常。

在Master转化的这段时间内，只要客户端的宽限足够长，那么客户端应用程序就可以在没有任何察觉的情况下，实现Chubby的故障恢复，但如果客户端的宽限期设置得比较短，那么Chubby客户端就会丢弃当前会话，并将这个异常情况通知给上层应用程序。

一旦客户端与新的Master建立上连接之后，客户端和Master之间会通过互相配合来实现对故障的平滑恢复，新的Master会设法将上一个Master服务器的内存状态构建出来，同时，由于本地数据库记录了每个客户端的会话信息，以及持有的锁和临时文件等信息，因此Chubby会通过读取本地磁盘上的数据来恢复一部分状态。一个新的Master服务器选举之后，会进行如下处理。

① 确定Master周期。Master周期用来唯一标识一个Chubby集群的Master统治轮次，以便区分不同的Master，只要发生Master重新选举，就一定会产生新的Master周期，即使选举前后Master是同一台机器。

② 新的Master能够对客户端的Master寻址请求进行响应，但是不会立即开始处理客户端会话相关的请求操作。

③ Master根据本地数据库中存储的会话和锁信息来构建服务器的内存状态。

④ 至此，Master已经能够处理客户端的KeepAlive请求，但仍然无法处理其他会话相关的操作。

⑤ Master会发送一个Master故障切换事件给每一个会话，客户端接收到这个事件后，会清空它的本地缓存，并警告上层应用程序可能已经丢失了别的事件，之后再向Master反馈应答。

⑥ 此时，Master会一直等待客户端的应答，直到每一个会话都应答了这个切换事件。

⑦ Master接收了所有客户端的应答之后，就能够开始处理所有的请求操作。

⑧若客户端使用了一个故障切换之间创建的句柄，Master会重新为其创建这个句柄的内存对象，并执行调用，如果该句柄在之前的Master周期中就已经被关闭了，那么它就不能在这个Master周期内再次被重建了，这一机制就确保了由于网络原因使得Master接收到那些延迟或重发的网络数据包也不会错误的重建一个已经关闭的句柄。

若想进一步了解Chubby，请阅读Mike Burrows, Google Inc. 撰写的论文 《The Chubby lock service for loosely-coupled distributed systems》 。

[Center]: /images/20220731/291c568ab470453d9868e22b7ee659b7.png
[Center 1]: /images/20220731/afe3be63e89445e0b8aed4db90e71013.png