Paxos的工程实践

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
  • 底层分布式文件系统抽象层