zookeeper概览

zookeeper概览

zookeeper是当前分布式系统重要组件。在kafka中你会见到它，在dubbo中会见到它，在分布式锁中会见到，当然面试中也会问道。了解zookeeper核心概览，及工作原理是当前开发的基本技能。

1. zookeeper基本概念

1. 什么是zookeeper

   ZooKeeper 是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性的问题，例如怎样避免同时操作同一数据造成脏读的问题。ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树种 的节点进行有效管理。从而来维护和监控你存储的数据的状态变化。将通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。

2. zookeeper的角色

   • leader, 负责进行投票的发起和决议，更新系统状态

   • learner

     • follower, follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
     • observer, 可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度

   • client, 请求发起方

3. zookeeper核心机制说明

   • zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
   • 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。
   • 每个Server在工作过程中有三个状态：

     • LOOKING:当前Server不知道leader是谁，正在搜寻

     • LEADING:当前Server即为选举出来的leader

     • FOLLOWING: leader已经选举出来，当前Server与之同步

     • OBSERVING: 观察者状态，表明当前服务器角色是Observer

4. Leader选举过程

   参考

5. Watcher机制

   参考

   参考

6. 数据一致性与paxos(派克骚死)算法

   • 据说Paxos算法的难理解与算法的知名度一样令人敬仰，所以我们先看如何保持数据的一致性，这里有个原则就是：
   　　• 在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。
   　　• Paxos算法解决的什么问题呢，解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个
   　　 全局写队列，所有写操作都必须 放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一
   　　　致性。没错，就是这样，可是如果master挂了呢。
   　　• Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，
   　　　只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一
   　　　轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点接受了一个
   　　　编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己 数据
   　　　不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。
   　 总结
   　　• Zookeeper 作为 Hadoop 项目中的一个子项目，是 Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，

   如它管理 Hadoop 集群中的 NameNode，还有 Hbase 中 Master Election、Server 之间状态同步等。\

   关于Paxos算法可以查看文章 Zookeeper全解析——Paxos作为灵魂

   推荐书籍：《从Paxos到Zookeeper分布式一致性原理与实践》

7. zxid

   • znode节点的状态信息中包含czxid, 那么什么是zxid呢?
   • ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生。 创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加。

8. 数据模型

   • 层次化的目录结构，命名符合常规文件系统规范
   • 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
   • 节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
   • Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
   • 客户端应用可以在节点上设置监视器
   • 节点不支持部分读写，而是一次性完整读写

9. zookeeper的读写机制

   • Zookeeper是一个由多个server组成的集群

   • 一个leader，多个follower

   • 每个server保存一份数据副本

   • 全局数据一致

   • 分布式读写

   • 更新请求转发，由leader实施

10. zookeeper的保证

    • 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行

    • 数据更新原子性，一次数据更新要么成功，要么失败

    • 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的

    • 实时性，在一定事件范围内，client能读到最新数据

11. Observer

    • Zookeeper需保证高可用和强一致性；

    • 为了支持更多的客户端，需要增加更多Server；

    • Server增多，投票阶段延迟增大，影响性能；

    • 权衡伸缩性和高吞吐率，引入Observer

    • Observer不参与投票；

    • Observers接受客户端的连接，并将写请求转发给leader节点；

    • 加入更多Observer节点，提高伸缩性，同时不影响吞吐；

12. Zookeeper的节点

    • Znode有两种类型，短暂的（ephemeral）和持久的（persistent）

    • Znode的类型在创建时确定并且之后不能再修改

    • 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点

    • 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除

    • Znode有四种形式的目录节点

      • PERSISTENT（持久的）

      • EPHEMERAL(暂时的)

      • PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）

      • EPHEMERAL_SEQUENTIAL（暂时化顺序编号目录节点）

13. 为什么zookeeper集群的数目，一般为奇数个？

    • Leader选举算法采用了Paxos协议；
    • Paxos核心思想：当多数Server写成功，则任务数据写成功如果有3个Server，则两个写成功即可；如果有4或5个Server，则三个写成功即可。
    • Server数目一般为奇数（3、5、7）如果有3个Server，则最多允许1个Server挂掉；如果有4个Server，则同样最多允许1个Server挂掉由此，

    我们看出3台服务器和4台服务器的的容灾能力是一样的，所以为了节省服务器资源，一般我们采用奇数个数，作为服务器部署个数。

2. zookeeper应用场景

参考

3. 总结

​ zookeeper原理看起来很复杂，作为一名合格的开发，需要了解其特性即可，知道什么场景使用它或者其典型应用场景。本文摘取网上总结，匆匆总结一下。后面有机会，再深入细节。加油，打工人。

4. 补充

zookeeper图形管理工具
zooInspector

其他参考

参考1