3.1 Chubby

Googel Chubby 是大名鼎鼎的分布式锁服务，GFS 和Big Table 等大型系统用它解决分布式写作、元数据存储和Master选举等一些列分布式锁服务相关问题。

它的底层一致性实现是以Paxos为基础的。

3.1.1  概述

一个面向松耦合的分布式锁服务。

分布式锁服务的目的是允许它的客户端进程同步彼此的操作，并对当前所处环境的基本状态信息达成一致。

Chubby提供粗粒度锁服务，开发人员直接调用CHubby锁服务接口即可实现分布式系统多进程粗粒度的同步控制，保证数据一致性，不需要使用复杂的同步协议。

3.1.2  应用场景

GFS和Big Table 都是用它进行Master选举和元数据存储。

3.1.3  设计目标

• 提供完整独立的分布式锁服务，而不仅仅是一个一致性协议的客户端库
  对其他应用程序入侵性低
• 提供粗粒度锁服务
  针对长时间持有锁（数小时或数天）
• 提供所服务同时，提供对小文件的读写功能
  提供小文件读写服务，使选举出来的Master可以不依赖额外服务，方便向所有客户端发布自己的信息。具体的，大概一个护短获取到Chubby文件锁称为Master后，直接向chubby锁文件写入master信息，其他客户端读取该文件获取Master信息。
• 高可用、高可靠
  Chubby架构设计中，可以部署多台机器（一般5台）组成Chubby集群，保证集群高可用。基于Paxos算法的实现，对于5台机器的集群，保证3台正常就能对外提可用服务。
• 提供事件通知机制
  避免客户端轮询获取信息对服务其的压力和网络带宽问题

3.1.4  Chubby 技术架构

1.系统结构

整个系统主要由服务端和客户端两部分组成

一个典型的Chubby集群或称为Chubby Cell 通常由5台服务器组成。

只有Master才能对数据库进行写操作，其他服务器使用Paxos协议从Master上同步更新。

通过Paxos协议，投票方式获取过半投票服务器为Master。一段时间内不会有其他服务器称为Master---这段时间称为Master租期（Master lease）。通过不断续租的方式延长Master租期，若Master故障，余下服务器在Master租期到期后，进行新一轮Master选举，产生新Master，开始新的Master租期。

非Master崩溃，集群不会停止工作，奔溃服务器恢复后自动加入到Chubby集群中去。新加入的机器需要同步Chubby最新数据库数据，完成同步后，加入到正常Paxos运作流程中与其他服务器副本协同工作。

奔溃服务器无法回复，需加入新机器，同时更新DNS列表。Chubby更换副武器方式非常简单，只需要启动Chubby 客户端程序，然后更新DNS上机器列表（替换IP）即可。Chubby运行过程中，Master周期性轮询DNS列表，他会很快感知服务器列表地址变动，然后Master变更集群数据库中的地址列表，集群中其他副本通过复制获取新的服务器地址。

Chubby Client 需要先定位Master服务器，将所有请求发送给Master。针对写请求，Master会采用一致性协议将其龚波给集群中所有副本服务器，且在过半服务器接受该写请求后再响应Client正确的应答。对于读请求，不需要广播，直接由Master单独处理即可。

2.目录与文件

Chubby的数据结构可以看做由文件和目录组成的树 如下：

/ ls / foo / wombat / pouch

ls是所有Chubby节点共有取得前缀，代表锁服务，即Lock Service；foo指定了Chubby集群名字，从DNS可以查询到由一个或多个服务器组成的该Chubby集群；剩余部分路径/wombat/pouch则是包含业务含义的节点名字，由Chubby服务器内部解析定位到该数据节点。

Chubby节点包文件和目录；节点分为持久节点和临时节点。持久节点需显示调用API删除，临时节点会随着客户端会话失效自动删除（如果临时节点文件没有被任何客户端打开，他就会被删除，可以依次判断客户端回话有效性）。

Chubby上的每个数据节点都包含少量的元数据信息，其中包括权限控制的访问控制列表（ACL）信息。同时还包括4个单调递增的64位编号，如下：

1. 1. 实例编号，表示Chubby创建该节点的顺序，即使节点名字相同，实例编号也不同；创建时间晚该编号越大。
   2. 文件内容编号，只针对文件，标识文件内容的变化情况，该编号会在文件内容被写入时增加。
   3. 锁编号，标识节点锁状态变更情况，该编号在节点锁从free转变为held（持有）时增加
   4. ACL编号，表示节点ACL信息变更情况，该编号在节点ACL配置信息写入时增加。

3.锁与锁序列器

锁延迟释放尽管不够完美，但是有效保护出现消息延迟情况的数据不一致。

锁延迟和锁序列器解决消息延迟和重排序列引起的分布式锁问题

 4.Chubby中的事件通知机制

为避免大量客户端轮序Chubby服务器带来的压力

• • 文件变更
  • 节点删除
  • 子节点新增、删除
  • Master服务器转移

5.Chubby中的缓存

客户端对文件内容和元数据信息缓存，提高整体性能，带来了复杂性，主要问题就是保证缓存一致性。通过租期机制保证缓存一致性。

每个客户端缓存有一个租期，通过续租维持有效性。当文件或元数据信息被修改时，Chubby服务器先阻塞修改操作，后Master向所有可能缓存该数据的客户端发送过期信号，使缓存失效，等到Master接收到所有相关客户端针对该过期信号的应答（一种是客户端明确要求更新缓存，另一种是客户端允许缓存租期过期）后，再继续进行之前的修改操作。弱一致性容易出问题。，虽然强一致性对性能和系统吞吐量影响较大，但是仍然选择了强一致性。

6.会话和会话激活（KeepAlive）

Chubby 客户端和服务端通过穿件一个TCP连接来进行所有网络通信，将这一连接称为会话（session）。心跳检测保持会话活性，延迟会话周期，使回话周期得到延续，称这个过程为KeepAlive（会话激活）

 7.KeepAlive请求

Master收到KeepAlive请求阻塞到会话租期即将到期，才响应这个KeepAlive请求，并将最新回话租期超时事件反馈客户端。客户端收到Master续租响应后，立即发送一个新的KeepAlive请求。所以正常运行中，每个CHubby客户端总是有一个KeepAlive请求阻塞在Master上。

8.会话超时

 客户端需要考虑两方面因素：一方面，KeepAlive响应网络传输耗时；另一方面，Master服务端和Chubby客户端存在始终不一致。因此在Chubby会话中，存在Master端会话租期和客户端本地会话租期。

若客户端按照本地会话租期超时时间，检测到其会话租期已经过期但没有收到Master的KeepAlive响应，此时，客户端无法确定Master服务端是否已终止当前会话，此时客户端处于“危险状态”。Chubby客户端会清空本地缓存，并标记为不可用。但客户端会等待一个“宽限期”的时间周期（默认45s）。如果宽限期内，客户单和服务端成功进行KeepAlive，则客户端重启本地缓存，否者客户端认为会话已过期，终止本次回话。

进入危险状态的客户端会通过“jeopardy”事件通知上层应用程序。恢复正常，客户端以“safe”事件通知应用程序可以继续正常运行了。若客户端没有恢复过来，客户端以“expired”事件通知应用程序，当前Chubby会话已超时。这样可以很好地辅助上层应用程序在不明确Chubby会话状态的情况下，根据不同事件类型做出不同的处理。（对于短时间CHubby服务不可用，客户端可以等待，而不是重启，对于重启花费较大的系统来说很有帮助）。

9.Chubby Master 故障恢复

 Chubby的Master服务器运行着会话租期计时器，用来管理所有会话的生命周期。若Master故障，则计时器停止，直到新的Master产生，计时器才会继续计时，即旧Master崩溃到新Master产生花费的时间不会记入会话超时的计算中，这等价于延长了客户端的会话租期。短时间选举产生Master，那么客户端会在本地会话过期前与其创建连接。如果选举时间长，会导致客户端清空本地缓存，并进入宽限期进行等待。宽限期的存在，使得会话能够很好地在服务端Master转换过程中得到维持。

P50

新的Master选举出来之后，需要几个主要处理：

1. 1. 确定Master周期，永爱唯一标识Chubby集群Master通知轮次，区分不同的Master
   2. 新Maser能够立即对客户端的Master寻址请求响应，但不能立即开始处理会话请求的操作
   3. Master根据本地数据库存储的会话和锁信息，构建服务器内存状态
   4. 此时可以处理KeepAlive请求，仍不能处理相关会话的操作
   5. Master发送一个“Master故障切换”事件给每一个会话，客户端收到这个事件后，会清空它的本地缓存，并警告上层应用程序可能已经丢失了别的事件，之后向Master反馈应答
   6. Master等待所有客户单应答此切换事件
   7. 收到所有应答后开始处理请求的操作
   8. 如果客户端使用故障切换前创建的句柄，Master会重新为其创建这个句柄的内存对象，并执行调用。如果该句柄在之前Master周期中已经被关闭了，那么它就不能在这个Master周期内再被重建了------这一机制保证了即使由于网络原因使得Master接收到延迟或重发的网络数据包，也不会错误地重建一个已经关闭的句柄。

3.1.5 Paxos协议实现

Chubby服务端的基本架构大致分为三层：

• • 最底层是容错日志系统，通过Paxos算法能够保证集群中所有机器上的日志完全一致，同时具备较好的容错性
  • 日志层之上Key-Value 类型的容错数据库（Fault-Tolerant DB），其通过下层的日志来保证一致性的容错性
  • 存储层之上是Chubby对外提供的分布式锁服务的小文件存储服务

      

 

 Paxos 算法的作用在于保证集群内各个副本节点日志能够保持一致。

.

.

.