- 1.什么是Chubby？
- 2.Chubby中的Paxos算法
- 3.Chubby的系统设计
- 4.Chubby的文件系统
- 5.Chubby的通信协议
- 6.Chubby的相关特点
- Chubby是Google设计的提供粗粒度锁服务的一个文件系统，它基于松耦合分布式系统，解决了分布的一致性问题。
- 通过使用Chubby的锁服务，用户可以确保数据操作过程中的一致性。
- Chubby还可以作为一个稳 定的存储系统存储包括元数据在内的小数据。
Paxos算法是Leslie Lamport最先提出的一种基于消息传递（Messages Passing）的 一致性算法，用于解决分布式系统中的一致性问题。
- 最底层是一个容错的日志，该日志对于数据库的正确性提供了重要的支持。不同副本上日志的一致性正是通过Paxos算法来保证的。副本之间通过特定的Paxos协议进行 通信，同时本地文件中还保存有一份同Chubby中相同的日志数据。
- 最底层之上是一个容错的数据库，这个数据库主要包括一个快照（Snapshot） 和一个记录数据库操作的重播日志（Replay-log），每一次的数据库操作最终都将提交至日志中。和容错的日志类似的是，本地文件中也保存着一份数据库数据副本。
- Chubby构建在这个容错的数据库之上，Chubby利用这个数据库存储所有的数据。Chubby的客户端通过特定的Chubby协议和单个的Chubby副本进行通信。
-
设计目标
- 高可用性和高可靠性
- 高扩展性
- 支持粗粒度的建议性锁服务
- 服务信息的直接存储
- 支持通报机制
- 支持缓存机制
-
考虑的问题
- 通常情况下开发者在开发的初期很少考虑系统的一致性问题，但是随着开发的 不断进行，这种问题会变得越来越严重。
- 系统中很多事件的发生是需要告知其他用户和服务器的，使用一个基于文件系 统的锁服务可以将这些变动写入文件中。
- 基于锁的开发接口容易被开发者接受。虽然在分布式系统中锁的使用会有很大 的不同，但是和一致性算法相比，锁显然被更多的开发者所熟知。
-
基本架构
5.Chubby的通信协议Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统，它所有的操作 都是在文件的基础上完成的。
客户端和主服务器之间的通信是通过KeepAlive握手协议来维持的
- 客户端租约过期
- 刚开始时，客户端向主服务器发出一个KeepAlive请求（见图2-10中的1）
- 如果有需要通知的事件时则主服务器会立刻做出回应
- 否则主服务器并不立刻对这个请求做出回应，而是等到客户端的租约期C1快结束的时候才做出回应（见图2-10中的2），并更新主 服务器租约期为M2。
- 主服务器出错
- 产生一个新的纪元号以便今后客户端通信时使用，这能保证当前的主服务器不 必处理针对旧的主服务器的请求。
- 只处理主服务器位置相关的信息，不处理会话相关的信息。
- 构建处理会话和锁所需的内部数据结构。
- 允许客户端发送KeepAlive请求，不处理其他会话相关的信息。
- 向每个会话发送一个故障事件，促使所有的客户端清空缓存。
- 等待直到所有的会话都收到故障事件或会话终止。
- 开始允许执行所有的操作。
- 如果客户端使用了旧的句柄则需要为其重新构建新的句柄。
- 一定时间段后（1分钟），删除没有被打开过的临时文件夹。
-
一致性
前面提到过每个Chubby单元是由五个副本组成的，这五个副本中需要选举产生一个主服务器，这种选举本质上就是一个一致性问题。在实际的执行过程中，Chubby使用 Paxos 算法来解决这个问题。
-
安全性
Chubby采用的是ACL形式的安全保障措施。
-
性能优化
为了满足系统的高可扩展性，Chubby目前已经采取了一些措施，比如：提高主服务器默认的租约期、使用协议转换服务将Chubby协议转换成较简单的协议、客户端一致性缓存等。
