【分布式】ZooKeeper论文总结

【分布式】ZooKeeper论文总结

文章目录

• 1. ZK是什么
• • 1.1 简介
  • 1.2 作用
  • 1.3 应用场景
• 2. ZK的关键技术
• • 2.1 共识算法和一致性
  • • 2.1.1 强一致性
    • • 2.1.1.1 顺序一致性
      • 2.1.1.2 线性一致性
      • 2.1.1.3 对比
    • 2.1.2 弱一致性
  • 2.2 znodes
  • 2.3 wait-free
  • 2.4 ZK服务组件
• 3.总结
• • • 参考

1. ZK是什么 1.1 简介

**论文中的原话**
本文描述分布式应用的协调服务：ZooKeeper。
ZooKeeper 是关键基础设施的一部分，其目标是给客户端提供简洁高性能内核用于构建复杂协调原语。

1.2 作用

• 分布式系统中需要的协调服务包括：配置、组成员关系、领导选举和锁服务。可以通过ZooKeeper的API自定义这些服务，从而用于协调进程，为分布式系统提供消息群发、共享寄存器、分布式锁这些中心化的服务。

1.3 应用场景

• 利用 ZooKeeper 可以非常方便构建一系列分布式应用中都会涉及到的核心功能。

数据发布/订阅
负载均衡
命名服务
分布式协调/通知
集群管理
Master 选举
分布式锁
分布式队列

• 多个开源项目中都应用到了 ZooKeeper，例如 Hbase，Spark，Flink，Storm，Kafka，Dubbo 等。
  

2. ZK的关键技术 2.1 共识算法和一致性

  一致性往往指分布式系统中**多个副本对外呈现的数据的状态**。如前面提到的顺序一致性、线性一致性，描述了多个节点对数据状态的维护能力。
  共识性则描述了分布式系统中**多个节点之间**，彼此对某个状态**达成一致结果的过程**。
  因此，一致性描述的是**结果状态**，共识则是一种**手段**。达成某种共识并不意味着就保障了一致性（这里的一致性指强一致性）。只能说共识机制，能够实现某种程度上的一致性。
  实践中，要保障系统满足不同程度的一致性，核心过程往往需要通过**共识算法**来达成。

• 一致性问题是分布式领域最为基础也是最重要的问题，常见的共识算法有 Paxos，Zab 和 Raft。
  ZK是基于Zab协议，ZK的一致性是顺序一致性。
• 总结一下，可以这么理解 ZooKeeper：从整体（read *** 作 + write *** 作）上来说是顺序一致性sequential consistency，写 *** 作实现了线性一致性Linearizability。
• ZooKeeper 有两个基本的顺序保证：
  线性化写入： 所有更新 ZooKeeper 状态的请求都是序列化的并且遵守优先级。
  先进先出客户端顺序： 对于一个客户端的所有请求，都会按客户端发送的顺序执行。

2.1.1 强一致性

• 强一致性又分为线性一致性和顺序一致性。其中前者对 safety 的约束更强，也是分布式系统中能保证的最好的一致性。

2.1.1.1 顺序一致性

• 如果一个并发执行过程所包含的所有读写 *** 作能够重排成一个全局线性有序的序列，并且这个序列满足以下两个条件，那么这个并发执行过程就是满足顺序一致性的：
  条件 I：重排后的序列中每一个读 *** 作返回的值，必须等于前面对同一个数据对象的最近一次写 *** 作所写入的值。
  条件 II：原来每个进程中各个 *** 作的执行先后顺序，在这个重排后的序列中必须保持一致。（保证 *** 作执行顺序，避免过程中的结果与预期不一致）

2.1.1.2 线性一致性

• 在顺序一致性基础之上，多了一个条件。
• 三个条件：
  条件 I：重排后的序列中每一个读 *** 作返回的值，必须等于前面对同一个数据对象的最近一次写 *** 作所写入的值。
  条件 II：原来每个进程中各个 *** 作的执行先后顺序，在这个重排后的序列中必须保持一致。
  条件 III：不同进程的 *** 作，如果在时间上不重叠，那么它们的执行先后顺序，在这个重排后的序列中必须保持一致。（保证读到最新的值）

2.1.1.3 对比

• 在顺序一致性中，我们有可能读到旧版本的数据。
• 它们都保证了程序执行顺序不会被打乱。体现在条件 II 对于进程内各个 *** 作的排序保持上。
• 线性一致性考虑了时间先后顺序，而顺序一致性没有。
• 满足线性一致性的执行过程，肯定都满足顺序一致性；反之不一定。
• 线性一致性隐含了时效性保证（recency guarantee）。它保证我们总是能读到数据最新的值。

2.1.2 弱一致性

• 弱一致性是指系统在数据成功写入之后，不承诺立即可以读到最新写入的值，也不会具体承诺多久读到，但是会尽可能保证在某个时间级别之后，可以让数据达到一致性状态。

2.2 znodes

• Zookeeper 给客户端提供了数据节点集（znodes）抽象表示，数据节点集以层次化命名空间的形式组织。例如，使用 /A/B/C 给出 znode C 的路径，C 的父节点是 B，B 的父节点是 A。所有 znodes 都存储数据，除了临时 znode，所有 znode 都可以有孩子节点。
  
• ZooKeeper以库的形式向客户端提供API，库也负责客户端到ZooKeeper服务器的连接。ZooKeeper中的数据节点称为znode，以树型命名空间组织。客户端连接服务器后建立会话，通过会话句柄发送请求。

2.3 wait-free

• wait-free：对于一个客户端，它的请求无需等待其他客户端的请求，虽然这个请求完成的可能很慢。使用了 watch 机制来达成 wait-free。
• ZooKeeper实现了观测(watch)机制，能够在数据对象更新后通知客户端，观测只会触发一次。

2.4 ZK服务组件

• ZooKeeper的组件如下图所示，ZooKeeper的数据副本保存在每一个服务器上，写 *** 作需要通过一致性协议提交到数据库，而读取请求可以直接访问服务器本地数据库获得。ZooKeeper在应用修改到数据库之前会写入到磁盘，故障后采用快照加日志的方式进行故障（例如，对于 2f+1 个服务器，可以允许 f 个故障）。根据一致协议，写入请求会转发到领导(leader)节点。
  读 *** 作可以在任何一个节点上，写 *** 作只能在 leader 上。
  

3.总结

• 关键词
  文件系统结构、Zab共识算法、快照加日志故障恢复
• 几大特性
  wait-free：对于一个客户端，它的请求无需等待其他客户端的请求，虽然这个请求完成的可能很慢。使用了 watch 机制来达成 wait-free。
  Linearizable writes：所有更新 zk 状态的请求是可串行化的，存在一个请求次序，按照这个次序执行，可以产生和原来并行执行请求一样的结果。
  FIFO client order：对于一个客户端，它的请求是按照发送的顺序来执行的。
  读写：所有的节点都可以读取，但是只有 leader 节点可以写入。在 follower 节点上不保证读取到最新的数据，但是保证读取的顺序，读取到了较新的数据，就不会读取在这以前的数据。使用 sync *** 作，可以等待当前请求之前尚未完成的更新 *** 作全部完成，在执行当前 *** 作。加入更多的服务器，可以使到读取速度提高，但是写入速度会变慢，因为共识算法需要保证 majority。
  读 *** 作：速度快，但是不保证可以得到最新的数据。相当于 CAP 中舍弃了 C。因为有 FIFO 这个 guarantee，同一个客户端的读取 *** 作一定是保证可以读到自己前面写入的内容的。

参考

【1】共识算法
【2】ZooKeeper解读
【3】ZooKeeper论文
【4】ZooKeeper论文笔记
【5】ZooKeeper 的应用场景