Chubby 大名鼎鼎的分布式锁

• GFS、Bigtable 都用他来解决分布式协助问题、元数据存储、Master选举等一系列问题
• 底层一致性实现就是Paxos

Chubby 是一个面向松耦合分布式系统的锁服务

• 提供高可用的分布式锁服务
• 一个分布式锁的目的是：
  • 允许客户端同步彼此的操作，并对当前所处环境的基本状态信息达成一致
• 粗粒度锁服务，不需要使用复杂的同步协议
• 设计成一个需要访问中心节点的分布式锁服务

分布式锁服务具有4个传统算法库所不具有的优点：

1. 对上层应用程序侵入性更小
   • 在系统用户达到一定规模前，高可用性并未被足够重视，
   • 达到一定规模后，开始重视，集群等措施加上去，一致性变得至关重要
   • 分布式锁服务比封装一致性协议的客户端库侵入性小
2. 便于提供数据的发布与订阅
   • 分布式锁非常适合提供该功能，二者实现上是相通的
3. 开发人员对基于锁的接口更为熟悉
   • Chubby 提供了一套近乎和单机锁机制一致的分布式锁服务
   • 远比一致性协议库来的更加友好
4. 更便捷的构建更可靠的服务
   • 分布式一致性算法，都要用Quorum机制来进行数据项值得选定
   • Quorum机制：指在一个集群中，一个数据项值得选定需要集群中过半数机器同意，只要集群中3台机器存在，就能提供正常的服务；
   • 而分布式一致性协议，只能交给开发人员自己处理，增加了开发成本

Chubby 设计目标：

1. 提供一个完整的、独立的分布式锁服务，而非一致性协议的客户库
2. 提供粗粒度的锁服务
   • Chubby 提供的是长时间持有的锁
3. 提供锁服务的同时，提供小文件的读写功能
   • 提供小文件的读写功能，可以使得被选举出来的Master ，在不依赖额外服务的情况下，非常方便的向所有客户端发布自己的状态信息。
4. 高可用高可靠
   • 只要三台以上就能提供正常服务
   • 支持小文件读写服务，进行Master 选举结果的发布订阅
5. 提供事件通知机制
   • 服务端数据变化，以事件通知的方式实时通知订阅的客户端

Chubby 技术架构

• Chubby 集群称为 Chubby  cell 通常由5台服务器组成。
• 副本服务器通过Paxos 协议，投票产生Master（票数过半）
• 一旦一台服务器称为Master，Chubby保证一段时间不会再有其他服务器成为Master（这段时间叫做“Master租期”）
• Master 服务器会不断延长租期的形式续租，一旦故障，重新选举
• 每台服务器都保存服务器数据库副本，只有Master 能写，其他与之保持同步
• 客户端如何定位Master
  • 首先向记录有服务端机器列表的DNS获取所有Chubby 服务
  • 挨个询问是否是Master，非Master 会把Master 返回给客户端
• 一旦定位到Master ，写请求会广播给所有服务器，过半接受了该请求就响应客户端，读请求Master 独立处理
• 如果Master 崩溃了
  • 其他服务器会在Master租期到期后，进入新一轮的选举（选举几秒钟结束）
• 如果非Master 崩溃
  • 不影响，自己重启即可
  • 长时间不能恢复，需要加入新的机器，配置DNS，Master是周期扫描DNS的，会很快感知到，其他服务器复制Master方式很快知道

目录与文件：

• Chubby 的数据结构是目录与文件组成的树
• ls是所有的前缀（根目录 lock service）
• foo 是Chubby 集群的名字
• 每个节点分为持久节点和临时节点
  • 持久节点需要显式的调用接口API进行删除
  • 临时节点和客户连接session 绑定，会话失效后，自动删除
    • 所以临时节点可以作为客户端有效性的判断依据
• 每个节点都包含少量元数据信息
  • 包括权限控制的访问控制列表（ACL）
  • 每个元数据还包括4个单调递增64位编号，分别是：
    • 实例编号：标示创建该实例节点的顺序（即便名字相同，也能区别俩节点）
    • 文件内容编号（只针对文件）：用于标示文件内容变化，文件内容被写入时增加
    • 锁编号：锁状态变更情况，节点锁在自由转到被持有时增加
    • ACL编号：ACL被写入时增加
    • 之外，还会提供64编号标识文件内容校验

• 锁与锁序列容器
  • 消息接受顺序紊乱
    • 解决方案：虚拟时间、虚拟同步
• Chubby 任意节点可以充当读写锁
  • 一种是排他模式持有锁
  • 另一种是共享锁
• Chubby 采用锁延时、锁序列器来解决消息延时和重排序引起的分布式锁问题
  • 正常释放锁，立即释放
  • 异常释放锁，进行锁延时
  • 锁序列器：
    • 客户端申请锁序列器
    • 锁名字、模式（排他、共享）、以及锁序号
    • 使用时，客户端将锁序列器发给服务端
      • 服务端会检查该锁序列是否存在，客户端是否处在合适的锁模式

Chubby 中的事件通知机制

• 客户端可以向服务端注册事件通知，当这些事件发生时通知客户端（消息异步发送）
• 常见事件：
  • 文件内容变更
    • BigTable 集群使用Chubby 确定哪台机器是Master
    • 获得锁的BigTable Master 会将自己信息写入Chubby对应文件中
    • BigTable 集群中其他机器通过关注Chubby 文件变化确认BigTable Master
  • 节点删除
    • 节点删除事件，通常临时节点出现比较多，可以此判断客户会话是否有效
  • 子节点新增删除
  • Master 服务器转移

Chubby 中的缓存

• 在客户端实现了缓存
• 会在客户端对文件内容和元数据进行缓存
  • 租期机制保证缓存的一致性
  • 缓存机制和Master的租期密切相关，Master维护客户端缓存，
  • 向客户端发送过期信息，保证客户端要么访问一致性数据、要么访问不到数据
    • 如果数据修改，Master先阻塞该操作，先向所有可能缓存的客户端发送过期信息，收到所有相关客户端的应答，再修改

会话和会话激活（KeepAlive）

会话超时

Chubby Master 故障恢复

• 客户端会话到期，Master 的keepAlive 回复未到，进入宽限期（默认45秒），客户端先清空缓存
• 新Master产生后，先确定新的Master周期
  • 之后开始拒绝别的Master周期编号的请求（即便新的Master 和旧的是同一台机器）
  • ，，，

Poxos 协议实现

• 容错日志系统就是采用paxos算法实现的
• 在此基础上实现一致的状态机副本，就是容错数据库
• 一旦故障，恢复仅仅需要按照日志再执行一遍
  • 根据本机日志恢复，不行就从其他节点获取

Hypertable

• Hypertable是C++开发的 开源、高性能、可伸缩数据库
• 目的是构建一个分布式海量数据的高并发数据库
• 目前只支持增删改查，不支持关联查询、事务处理等高级特性
• 优势：

主要包括四个部分：

• Hyperspace
  • 类似BigTable的Chubby
• RangeServer
  • 对外提供服务的组件单元，负责数据的读写
• Master 元数据管理中心
• DFSBroker
  • 底层分布式文件系统抽象层