一、概念

提供存储服务并为其他基础设施(GFS和Bigtable) 提供协调服务

提供粗粒度的分布式锁

提供一个文件系统，为小文件提供可靠存储，补充GFS提供的服务做Google内部的名字服务
核心服务:提供分布式共识解决方案

二、用途

Google没有直接实现包含Paxos算法的函数库来保持数据一致性，而是设计实现了锁服务Chubby

单独的锁服务可以保证原有系统架构不发生改变
避免应大量系统组件之间的事件通信导致的系统性能下降
系统中很多事件的发生需要告知其它用户和服务器，使用基于文件系统的锁服务可以将变动写入文件，从而需要了解变动的用户和服务器直接访问文件，
相比一致性算法，基于锁的开发接口容易被开发者接受
单独的锁服务使用一台服务器可以保证高可用性
实现chubby服务采用多台服务器实现高可用性，而外部用户则需一台服务器保证高可用性
Chubby采用建议性锁而不是强制性锁
当用户访问拥有锁的文件时，强制性锁阻止访问，而建议性锁不会阻止。

两个部分: client和server, 通过RPC通信

客户端每个客户有一个Chubby library,客户端应用调用这个库中的函数
服务端称作Chubbycell,通常由5个副本组成，其中一个副本被指定为主副本(master),并且一段时间只有一个master。
这段时间成为master lease

每个副本维护一个小型数据库，管理Chubby命名空间中的实体，即目录和锁

数据库的一致性使用底层的共识协议、(Paxos算法)实现

基于操作日志

支持创建快照snapshots (在给定时间点上完整的系统状态)

Chubby提供基于文件系统的抽象，每一个数据对象是一个文件，文件组织成层次的命名空间，采用目录结构，所有操作在文件的基础上完成
Chubby的名字空间结构类似于文件系统，这样就使得可以为应用提供特定的API,也可以使用他文件系统的接口，例如GFS
文件系统与Unix文件系统类似，文件名形式: /s/chubby_ cell/directory_ name/–/file_ name
Is指锁服务lock service, 指明是chubby系统的一部分
Chubby_ cell 是chubby系统的一个特定实例的名字
名字空间由文件和目录组成，统称为node。每个node在一个Chubby cell单元中只有一个名称与之关联。
实现时，文件系统由多个节点组成，分为永久型和临时型，每个节点是一个文件或目录，包含元数据，三个访问控制列表(ACLs):用于控制读、写操作及修改节点的访问控制列表(ACL)。
每个节点的元数据还包含4个严格递增的64位数字，通过它们客户端可以很方便的检测出变化
●实例号
●内容生成号
●锁生成号
●ACL生成号

本文地址：https://blog.csdn.net/Findyoulucky/article/details/107193353