[大数据]如果你还不知道Apache Zookeeper？你凭什么拿大厂Offer！！

很多同学或多或少都用到了Zookeeper，并知道它能实现两个功能

• 配置中心，实现表分片规则的统一配置管理
• 注册中心，实现sharding-proxy节点的服务地址注册

那么Zookeeper到底是什么？以及为什么能实现这样的功能？接下来我们就来了解一下Zookeeper。

Zookeeper的前世今生

Apache ZooKeeper是一个高可靠的分布式协调中间件。它是Google Chubby的一个开源实现，那么它主要是解决什么问题的呢？那就得先了解Google Chubby

Google Chubby是谷歌的一个用来解决分布式一致性问题的组件，同时，也是粗粒度的分布式锁服务。

分布式一致性问题

什么是分布式一致性问题呢？简单来说，就是在一个分布式系统中，有多个节点，每个节点都会提出一个请求，但是在所有节点中只能确定一个请求被通过。而这个通过是需要所有节点达成一致的结果，所以所谓的一致性就是在提出的所有请求中能够选出最终一个确定请求。并且这个请求选出来以后，所有的节点都要知道。

这个就是典型的拜占庭将军问题

拜占庭将军问题说的是：拜占庭帝国军队的将军们必须通过投票达成一致来决定是否对某一个国家发起进攻。但是这些将军在地里位置上是分开的，并且在将军中存在叛徒。叛徒可以通过任意行动来达到自己的目标：

1. 欺骗某些将军采取进攻行动

2. 促使一个不是所有将军都统一的决定，比如将军们本意是不希望进攻，但是叛徒可以促成进攻行动

3. 迷惑将军使得他们无法做出决定

如果叛徒达到了任意一个目标，那么这次行动必然失败。只有完全达成一致那么这次进攻才可能胜利

拜占庭问题的本质是，由于网络通信存在不可靠的问题，也就是可能存在消息丢失，或者网络延迟。如何在这样的背景下对某一个请求达成一致。

为了解决这个问题，很多人提出了各种协议，比如大名鼎鼎的Paxos； 也就是说在不可信的网络环境中，按照paxos这个协议就能够针对某个提议达成一致。

所以：分布式一致性的本质，就是在分布式系统中，多个节点就某一个提议如何达成一致

这个和Google Chubby有什么关系呢

在Google有一个GFS(google file system)，他们有一个需求就是要从多个gfs server中选出一个master server。这个就是典型的一致性问题，5个分布在不同节点的server，需要确定一个master server，而他们要达成的一致性目标是：确定某一个节点为master，并且所有节点要同意。

而GFS就是使用chubby来解决这个问题的。

实现原理是：所有的server通过Chubby提供的通信协议到Chubby server上创建同一个文件，当然，最终只有一个server能够获准创建这个文件，这个server就成为了master，它会在这个文件中写入自己 的地址，这样其它的server通过读取这个文件就能知道被选出的master的地址。

分布式锁服务

从另外一个层面来看，Chubby提供了一种粗粒度的分布式锁服务，chubby是通过创建文件的形式来提供锁的功能，server向chubby中创建文件其实就表示加锁操作，创建文件成功表示抢占到了锁。

由于Chubby没有开源，所以雅虎公司基于chubby的思想，开发了一个类似的分布式协调组件Zookeeper，后来捐赠给了Apache。

所以，大家一定要了解，zookeeper并不是作为注册中心而设计，他是作为分布式锁的一种设计，而注册中心只是他能够实现的一种功能而已。

Zookeeper的安装和部署

安装

zookeeper有两种运行模式：集群模式和单击模式。

下载zookeeper安装包：https://mirrors.bfsu.edu.cn/apache/zookeeper/zookeeper-3.6.3/apache-zookeeper-3.6.3-bin.tar.gz

下载完成，通过tar -zxvf解压

常用命令

1. 启动ZK服务:

   bin/zkServer.sh start

2. 查看ZK服务状态:

   bin/zkServer.sh status

3. 停止ZK服务:

   bin/zkServer.sh stop

4. 重启ZK服务:

   bin/zkServer.sh restart

5. 连接服务器

   zkCli.sh -timeout 0 -r -server ip:port

单机环境安装

一般情况下，在开发测试环境，没有这么多资源的情况下，而且也不需要特别好的稳定性的前提下，我们可以使用单机部署；

初次使用zookeeper，需要将conf目录下的zoo_sample.cfg文件copy一份重命名为zoo.cfg

修改dataDir目录，dataDir表示日志文件存放的路径（关于zoo.cfg的其他配置信息后面会讲）

集群环境安装（后续再讲）

在zookeeper集群中，各个节点总共有三种角色，分别是：leader，follower，observer

集群模式我们采用模拟3台机器来搭建zookeeper集群。分别复制安装包到三台机器上并解压，同时copy一份zoo.cfg。

1. 修改配置文件

   1. 修改端口
   2. server.1=IP1:2888:3888 【2888：访问zookeeper的端口；3888：重新选举leader的端口】
   3. server.2=IP2.2888:3888
   4. server.3=IP3.2888:2888

2. server.A=B：C：D：其 中

   1. A 是一个数字，表示这个是第几号服务器；
   2. B 是这个服务器的 ip地址；
   3. C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；
   4. D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。
   5. 在集群模式下，集群中每台机器都需要感知到整个集群是由哪几台机器组成的，在配置文件中，按照格式server.id=host:port:port，每一行代表一个机器配置。id: 指的是server ID,用来标识该机器在集群中的机器序号

3. 新建datadir目录，设置myid

   在每台zookeeper机器上，我们都需要在数据目录(dataDir)下创建一个myid文件，该文件只有一行内容，对应每台机器的Server ID数字；比如server.1的myid文件内容就是1。【必须确保每个服务器的myid文件中的数字不同，并且和自己所在机器的zoo.cfg中server.id的id值一致，id的范围是1~255】

4. 启动zookeeper

Zookeeper的数据模型

如果我们把zookeeper当成是一个内存数据库的话，那么crud就是对zookeeper内存数据库进行一个数据的增删改查操作，那zookeeper的数据结构是什么样的呢？如图9-4所示，zookeeper的视图结构和标准的文件系统非常类似，每一个节点称之为ZNode， 是zookeeper的最小单元。每个znode上都可以保存数据以及挂载子节点，构成一个层次化的树形结构

节点类型

Zookeeper中包含4种类型的节点，分别说明如下。

持久化节点

持久化节点可以细分为两种节点，分别是：

• PERSISTENT：持久化，不会随客户端的断开而自动删除,默认类型，如图9-5所示

  

  图9-5

• PERSISTENT_SEQUENTIAL：带序号的持久化，znode的名字将被附加一个单调递增的数字，如图9-6所示

  nohup "$JAVA" $ZOO_DATADIR_AUTOCREATE "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \
      "-Dzookeeper.log.file=${ZOO_LOG_FILE}" "-Dzookeeper.extendedTypesEnabled=true" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
      -XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p' \
      -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &

create [-s] [-e] [-c] [-t ttl] path [data] [acl]

delete [-v version] path

set [-s] [-v version] path data

get [-s] [-w] path

  get -w /node
  # 在其他窗口执行下面命令，会触发相关事件
  set /node 123
  delete /node

  ls -w /node
  # 在其他窗口执行下面命令，会触发相关事件
  create /node/node1
  delete /node/node1