0. Chubby 协议

• 面向松耦合分布式系统的锁服务, 解决分布式中的一致性问题.

• 锁服务:
  • 粗粒度的锁服务: 客户端会长时间持有锁.
  • 锁在分布式系统中的用途:
    • 允许客户端进程同步彼此的操作, 并对当前所处环境的基本信息达成一致.
• 通过”文件”实现锁:
  • 首先, Chubby 是一个分布式文件系统, 对其而言: 锁就是文件.
  • 创建文件就是进行”加锁”操作, 而成功创建文件的服务器就抢占到了”锁”.
  • 用户通过打开, 关闭, 读取文件获取共享锁或者独占锁.
  • 文件有更新时, 会通知相关的用户.

• 系统架构图

  

  • 分为两个部分: 服务器称为Chubby cell；�每个client都有一个Chubby library。
    • 两端使用RPC 进行通信.
    • 客户端通过Chubby library 的接口调用, 在 Chubby cell 上创建文件来获取锁.
• 优势
  • 开发人员对基于锁的接口更为熟悉, 远比一致性协议的库更为友好.
  • 对上层应用程序的侵入性更小, 易于保持系统已有的程序结构和网络通信模式.
  • 便于提供数据的发布与订阅, 以让客户端实时地感知到Master 的变化.
  • 允许客户端在�服务器上进行小文件的读写操作.
  • 更便捷地构建更可靠的服务. 需要Quorum 机制进行数据项值的选定.
• Master 服务器
  • master lease
    • mater在运行过程中,不断续租来延长lease.
  • 客户端向记录有服务器机器列表的DNS来请求所有的服务器,然后逐个询问是否为Master
    • 非Master会将当前Master表示回馈给客户端, 达到了非常快的定位.
  • 若集群中服务器崩溃且无法恢复, 则需要加入新机器, 并更新DNS 列表(启动服务端程序,更新DNS 上的机器列表).
    • Master会周期性轮训DNS 列表, 并很快感知到服务器地址的变更, 然后通知集群.

1. Ensemble

为了达到高可用性, 会同时运行多个Zookeeper 服务器, 称为ensemble.

zookeeper_ensemble.png

• 复制服务.
  • 需要服务器集中中大多数机器正常工作, 才能提供服务.
  • 崩溃掉的服务器, 可以使用crash-recovery 协议来恢复并重新进入到ensemble.
• primary 服务器接收并执行所有的请求, 然后传播执行结果.
  • 当primary 崩溃掉后, 执行恢复协议来统一一致性状态, 并建立新的primary.
  • 所有读操作都是in-memory 的, 拥有很高的速度.
• 每个服务器会在内存中维持一个(代表ensemble 节点组成的)分布式文件系统的副本.
• 每个client 一个到服务器的session. 并由ensemble 提供以下特性:
  • 自动且透明化的故障转移.
  • 自动化的keep-alive.
  • 客户请求超时.

2. 数据一致性

• 最终一致性(Eventual Consistency)
  • followers may lag(迟于) leader.
• 顺序的一致性(Sequential Consistency)
  • 客户端的更新请求, 会以请求发送的顺序来被应用.

3. �节点

• 临时的(Ephemeral)节点
  • 会话过期时消亡.
  • 由其生命周期决定, 并不会有子节点.
  • 使用场景: 组成员, leader 选举.
• 持久化的(Persistent)节点可以含有子节点, 类似于目录.
• 节点的用途:
  • 节点可以持有(小于1M的)数据, 类似于文件.
  • 提供像 创建,删除, 检查存在性的基本节点操作.
• 由节点构成Group Membership
  • 提供事件驱动模型, 客户端可以监听特定节点的变化.
  • 对外暴露的是文件系统模型, 有层级的命名空间.

4. Replication

• 复制是以软件手段来增加数据的可用性.

• 常用于数据库和分布式系统中, 提供合理的性能, 并维持数据一致性.
• 在数据库中,使用延迟(deferred)更新模型.
  • 事务由本地的服务器(replica manager)处理, 并在提交时, 转发给其它服务器.
  • 与之相对的是立即更新模型, 它会在所有的服务器间同步事务.

• 复制数据库模型

  

  • 由一系列运行在不同处理器上的process 组成.
  • 每个process 都有数据库的一个副本, 被称为replica manager.
  • 每个process 有两种状态: Up && Down.

• 终止协议(Termination Protocol).

  

  • 向其它process 提交事务, 并确认该动作.
  • 在CS 分布式系统中, 使用原子广播(atomic broadcast).
  • 可以向多个process 发送同一消息, 并且保证消息顺序为发送顺序.
  • certifier 向Data Manager 询问已提交事务的信息, 如果该事务已经被验证通过, 它的写操作会被提交给Lock Manager.

5. Zookeeper 的典型应用场景

5.1 配置中心: 数据的发布/订阅

• 推拉结合的方式:
  • 客户端注册的关注节点发送数据变更时, 会向客户端发送watch 事件通知.
  • 客户端在接收到通知后, 需要主动向服务索取最新数据.
• 将配置信息放到Zookeeper上进行集中管理,
  • 应用在启动时主动向Zookeeper 服务器索取配置, 同时监听配置的变化.
  • 典型场景: 全局配置信息
    • 包含: 机器列表, 运行时开关配置, 数据库配置.
    • 特性: 数据量小; 运行时动态变化; 各机器共享; 配置一致.

5.2 负载均衡

• 动态DNS服务. 超大规模的分布式(域名到IP的)映射表.
  • 使用本地host 绑定可以实现域名解析.
    • 但是当主机规模庞大, 或需要更新域名时,有致命缺陷.
  • Dynamic DNS. 创建一个节点进行域名配置.
    • 域名解析过程�需要每个应用自己负责.

5.3 命名服务.

• 资源定位不是真正的实体资源.
• 分布式全局唯一ID的分配机制.
  • UUID的缺陷:长度过长,含义不明.
• 通过调用Zookeeper节点创建API可以创建顺序节点, 并在API返回值中会返回这个节点的完整名字.
  • 创建顺序子节点时, 自动以后缀形式在子节点上添加序号.

5.4 分布式协调/通知

• MySQL数据复制总线. Mysql_Replicator.
  • 在不同MySQL 实例间进行异步数据复制和数据变化通知.
  • 让不同的机器都在Zookeeper 的�指定节点下创建临时节点, 不同机器间根据这个临时节点判断对应的客户端机器是否存活.
    • 解耦了检测和被检测系统.
    • 同时可实时地将自己任务执行进度写入临时节点.

5.5 集群管理

• 集群监控(运行时状态的收集)和集群控制(上下线操作).
• 基于Agent 体系的集群管理:
  • 每台机器上的Agent 主动向指定的监控中心系统汇报状态.
  • 当集群规模变大后会造成问题:
    • 大规模升级困难; 统一的agent无法满足定制需求; 编程语言多样性.
• 特性:
  • 当客户端对数据节点注册watcher 监听后, 当数据节点的内容或子节点列表发生变更时,会收到通知.
  • 临时节点会在客户端与服务器的会话失效后,被自动清除.
• 分布式日志收集系统.
  • 把所有需要收集的日志机器分为多个组, 每个组对应一个后台机器作为收集器.
  • �特性: 变化的日志源机器, 变化的收集器机器.�达到了快速合理动态地为每个收集器分配对应的日志源机器..