深入浅出ZooKeeper（1）--- 基本介绍

ZooKeeper的官方站为https://zookeeper.apache.org/releases.html，其为Apache的一个子项目。
截至2020.09.13 最新的版本为3.6.2. 官方对Zookeeper的权威定义如下：

ZooKeeper is a distributed, open-source coordination service for distributed applications. It exposes a simple set of primitives that distributed applications can build upon to implement higher level services for synchronization, configuration maintenance, and groups and naming. It is designed to be easy to program to, and uses a data model styled after the familiar directory tree structure of file systems. It runs in Java and has bindings for both Java and C.

翻译成中文就是, ZooKeeper 是一个分布式的，开源的，协调分布式应用的一个服务。Zookeeper通过提供一些简单基础的功能和指令，从而帮助分布式系统在其上层实现数据同步，配置维护，组以及命名空间的管理。 ZooKeeper的数据结构非常的简单，类似文件系统的目录结构，Zookeeper是运行在JVM上，但是其底层是结合了Java和C语言实现的。

其内部的实现组件如下图所示意。其由三大块组成：
#1）请求处理器
每个客户端只连接到集群中的一台服务器进行提交请求，如果是读请求的话，很简单，直接当前的服务器就处理了，如果是写请求，就比较复杂一下，其需要通过一致性同意协议进行处理，大白话就是其会联系leader节点，由leader节点通过ZAX协议广播到其Followers节点，进行更新，只有半数以上的Followers节点都更新成功后，才算成功。具体大家可以参考此博客：https://blog.csdn.net/liyiming2017/article/details/83035157

#2) 原子广播（ZAB Zookeeper Atomic Broadcast）组件
ZAB协议是Zookeeper的特有的协议，其主要用来进行消息的写同步的广播，leader的选举已经leader下线后的通知等。因为消息层是原子的，zooKeeper能够保证本地的复制永远不会分叉。

#3) 复制同步的内存数据库
请求的数据会更新会同步到磁盘，以防止万一发生故障时能快速恢复。而且数据先是写到磁盘上，然后才写入内存数据库，这就为什么其读性能能够达到其写性能的10倍。

1. 设计原则

1.1 KISS 原则

Keep It Stupid and Simple。 主要体现在其数据结构和API的设计上，从下面的ZooKeeper服务器上保存的数据结构可以看出，其服务器端存储的数据模型就类似于一个标准的文件系统。我们可以把其叫做path（路径），每个路径只有一个直接的父路径，但是可以有很多的子路径。ZooKeeper的数据在服务器端是保存在内存里面的，所以能够保持其在高吞吐量的情况下的性能，下面有一个章节会特别说明。

ZooKeeper提供的API也非常的简单，只提供了下面的操作

• create : 在一棵树里面创建一个节点
• delete : 删除一个节点
• exists : 测试当前节点是否存在
• get data :
  读取节点上的数据
• set data : 把数据写入节点 get children : 获得当前节点的所有子节点
• sync :等待数据被传播

具体的语义，大家不用着急，后续文章会给大家具体进行分享。

1.2. 高可用的主从复制的原则

Zookeeper是一个主从复制的典型结构，其分成Leader，Follower， Observer的角色。Leader节点是通过选举产生的，所有的写入都必须通过Leader节点进行分发，但是读的话，所有的节点都支持。Follower节点和Observer节点的区别是，Follower能参与选举，Observer不能参与选举，只能为了扩展读性能。

1.3 消息是有顺序的

Zookeeper会为每次更新分配一个全局唯一的顺序号，这个顺序号就是Zookeeper处理事务的顺序号

1.4 非常的快

小李飞刀和傅红雪的小刀大刀已经非常快了，ZooKeeper的速度更快。特别是读的效率在整个业界同类产品里面是顶呱呱的，否则也不可能有这么多的分布式系统用它来进行服务器集群的管理，分布式锁和事务的处理，HBase, Kalfka 等都是其忠实的粉丝，其读的速度是写的速度的十分之一的时间。

3.性能

那有同学会问，其性能怎么样呢？ 有图有真相，由三个服务器组成的集群，在910个客户端同时连接的情况下，其每秒读的吞吐量能够达到9万次/秒，如果集群里的服务器越多，则其吞吐量越大，只要你有足够的本钱去买服务器。

4.使用场景

• 数据订阅和发布

这个功能是一个基本的功能，使用者可以把要使用的公共的元数据，存储在Zookeeper的服务器上，利用Zookeeper的强大的高并发的读写能力，从而快速读取和共享元数据，注意的是，大家不要把数据量比较大的业务数据放到上面去。

• 分布通知/协调

ZooKeeper 中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对 ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能 够收到通知，并作出相应处理。

• 分布式锁
  在分布式的系统中，经常遇到多个同类型的Job任务，为了防止Job的任务被重复执行多次，这个时候，可以用Zookeeper作为分布式锁来进行使用，比如你有一个job，可以同时在节点上创建一个标识已经在处理的资源的唯一ID，这样别的Job读取到了这个ID，就可以跳过这条资源的处理，否则就会处理！

• 集群管理
  比如通过创建一个临时节点，服务器在的事情，临时节点就在，服务器下线的时候，临时节点就下线。

5. 总结

本文是一篇ZooKeeper的基本介绍，主要介绍了ZooKeeper的作用，设计原则，性能，已经其使用场景。接下来的文章会详细介绍，ZooKeeper的安装配置，基本命令的使用，客户端代码的调用，使用场景探索等。敬请关注。

参考文献

https://zookeeper.apache.org/doc/r3.6.2/zookeeperOver.html#zkPerfRW
https://blog.csdn.net/king866/article/details/53992653/
https://blog.csdn.net/liyiming2017/article/details/83035157
https://blog.csdn.net/Bruceleexiaokan/article/details/7849601