一、什么是Zookeeper
1.1 概述
在我的印象中，zookeeper是可以作为注册中心来存在的，之前的微服务架构更多的是采用Dubbo+zookeeper来搭配着使用的，因此，zookeeper它是主要服务于分布式系统。
而分布式系统的特点就是会有多个节点存在，实时感知每个节点的状态，管理每个节点就变得尤为重要。而zookeeper的出现就解决了这个问题。 从设计模式角度来理解：它是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生了变化，zookeeper就负责通知已经在zookeeper上注册的那些观察者，让他们做出相应的反应。
因此，zookeeper可以概况为：文件系统+通知机制。
福利 福利 福利 免费领取Java架构技能地图 注意了是免费送
免费领取 要的+V 领取
工作机制：
- 1、服务端启动时去注册信息（创建的都是临时节点）
- 2、获取到当前在线服务器列表，并且注册监听
- 3、服务器节点下线
- 4、服务器节点下线事件通知
- 5、process重新再去获取服务器列表，并注册监听
1.2 特点
1、Zookeeper是设计模式是由一个领导者和多个跟随者组成的集群
2、半数原则：集群中只要有半数以上的节点存活，zookeeper集群就能正常服务
3、全局数据一致，每个server服务器保存一份相同的数据副本，client无论连接到哪个server，数据都一致
4、数据更新原子性：一次数据更新要么成功，要么失败。
5、实时性：在一定时间范围内，client能够读到最新数据。
1.3 数据结构
zookeeper的数据模型与linux文件系统很类似，整体可以看作是一棵树，每个节点称为znode，默认能够存储1Mb的数据，每个znode都可以通过其路径唯一标识： 
而这些节点可以分为两类：临时和持久。因此一个面试题产生了：zookeeper的节点类型有哪些？
- 临时普通节点
- 临时有序节点
- 持久普通节点
- 持久有序节点
1.4 zookeeper能干啥？
zookeeper 提供的服务包括：统一命名服务，统一配置管理，统一集群管理，软负载均衡，分布式锁。
1.4.1 统一命名服务
可以理解为访问域名：www.baidu.com 的时候，这个域名下面有很多台服务器：192.168.1.100，192.168.1.101，192.168.1.102等。别人只要访问这个域名，zookeeper就会把请求转发给注册过的某个服务器上。而用户并不用去记住访问哪个ip地址，只需要知道这个域名就可以了。
1.4.2 统一配置管理
把公共的配置文件抽取出来，分发给其他系统。
配置文件同步非常常见。一般要求一个集群中，所有的节点的配置信息是一致的，比如kafka集群，对配置文件修改后，希望能够快速同步到各个配置上。
1.4.3 统一集群管理
1)分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态进行调整。
2) zookeeper 可以实现实时监控节点状态变化。
- 可将节点信息写入zookeeper上的一个Znode
- 监听这个znode可获取它的实时状态变化。
1.4.4 软负载均衡
再zookeeper中记录每台服务器的访问数，让访问最少的服务器去处理最新的客户端请求。
1.4.5 分布式锁
如果有a、b、c多个客户端去抢一个zookeeper分布式锁。原理是这样的：
- 刚访问 /lock 锁节点的时候，大家都上来直接创建一个接一个的有序节点。例如a系统创建了001节点。b系统创建了002节点，c系统创建了003节点。
- 系统拿到所有的节点后，会比较自己的节点是不是最小的，如果是，则得到锁，如果不是，就对上个节点加监听器，监视它。
- 只要上一个节点释放锁，自己就排到前面去了，相当于一个排队机制。
用临时节点 第一个用意：如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系，zookeeper感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。
二、zookeeper安装
2.1 本地模式安装部署
1、步骤：
- 配置修改：conf下的zoo_sample.cfg修改为zoo.cfg
- 在zookeeper目录下创建dataDir文件夹，存放数据的存储目录。
- 在zookeeper下面添加数据存放路径：
dataDir=/opt/module/zookeeper-3.5.7/zkData
复制代码- 启动
[root@hadoop101 zookeeper-3.5.7]# bin/zkServer.sh start
复制代码- 查看状态
[root@hadoop101 zookeeper-3.5.7]# bin/zkServer.sh status
复制代码- 启动客户端 连接指定的host的zk服务
[root@hadoop101 zookeeper-3.5.7]# bin/zkCli.sh -server host:port
复制代码- 停止
[root@hadoop101 zookeeper-3.5.7]# bin/zkServer.sh stop
复制代码2.2 配置参数解读
1）tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒 Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。 它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。 (session的最小超时时间是2*tickTime)
2）initLimit =10：LF初始通信时限 集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。
3）syncLimit =5：LF同步通信时限 集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。
4）dataDir：数据文件目录+数据持久化路径 主要用于保存Zookeeper中的数据。
5）clientPort =2181：客户端连接端口 监听客户端连接的端口
三、Zookeeper内部原理
3.1 节点类型（Znode）
持久：客户端和服务器断开后，创建的节点不删除。
1）普通持久节点
2）带序号的持久节点（序号zookeeper自己维护）
短暂：客户端和服务器断开连接后，创建的节点自己删除。
1）普通短暂节点
2）带序号的短暂节点（序号zookeeper自己维护）
3.2 Stat结构体
描述每个ZNode的状态信息
[zk: localhost:2181(CONNECTED) 12] stat /zookeeper
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -2
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 2
复制代码（1）czxid-创建节点的事务zxid 每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。 事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。
（2）ctime - znode被创建的毫秒数(从1970年开始)
（3）mzxid - znode最后更新的事务zxid
（4）mtime - znode最后修改的毫秒数(从1970年开始)
（5）pZxid-znode最后更新的子节点zxid
（6）cversion - znode子节点变化号，znode子节点修改次数
（7）dataversion - znode数据变化号
（8）aclVersion - znode访问控制列表的变化号
（9）ephemeralOwner- 如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0。
（10）dataLength- znode的数据长度
（11）numChildren - znode子节点数量
3.3 监听器原理
1、原理
- 首先要有一个main（）线程
- 在main线程中创建zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）
- 通过connect线程将注册的监听事件发送给zookeeper
- 在zookeeper的注册监听列表中将注册的监听事件添加到列表中
- zookeeper监听到有数据或路径变化，就会把这个消息发送
- listener线程内部调用了process（）方法
2、常见的监听
- 监听节点数据的变化：get path
- 监听子节点增减的变化：ls path
3.4 选举机制
3.4.1 ZAB协议：
基于消息传递且保证数据一致性的一种算法（协议）
协议目标：
1、没有leader的情况下选举leader
2、有leader的情况，去尽可能保证数据一致。
3.4.2 zj集群
（1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
（2）Zookeeper 虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
3.4.3 机制概念
1、Serverid： 服务器id 比如有三台服务器，编号分别是1，2，3
2、Zxid：数据ID
服务器中存放的最大数据ID ：值越大说明数据越新，在选举算法中数据越新权重越大。
3、Epoch：逻辑时钟
或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到返回的投票信息的数值相比，根据不同的值做出不同的判断。
4、Server状态：选举状态
- LOOKing：竞选
- FOLLOWING：随从状态
- OBSERVING：观察状态，
- LESDING：领导者状态。
3.4.4选举过程
假设有五台服务器组成的Zookeeper 集群，它们的id从1-5 ，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这点上，都是一样的。
投票原则：
- 自私原则（服务器刚注册的时候都会投自己一票）
- 墙头草随风倒原则：（发现有其他服务器比自己厉害，就投其他服务器）比较的东西可以为zxid 时间戳，哪个服务器有最新的数据就投它。
过程：
（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；
（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
（5）服务器5启动，同4一样当小弟。
3.4.5 leader故障后选举
当集群工作中，leader故障后，只要剩下的机器数大于半数，集群能够正常工作，但是需要重新选举leader。选举的过程还是进行投票，因为集群是在工作中，因此每台机器的id有可能不同。那么每次投出的票（myid，zxid），先比较zxid，再比较myid，因此集群中剩余的机器中zxid最大的当选leader，如果zxid都一样，理论情况下myid最大的胜出。
zxid 时间戳，最新的数据。某种意义上，可以表示当前机器中存储的数据完整度。
3.5 写数据流程
1）客户端连接zk集群的任意一台机器，发送写请求
2）如果客户端连接的zk集群部署leader，则当前这台机器会将客户端的写请求转发给leadet
3）当leader接收到写请求后，会将当次的写操作构造成一个事务，对应一个zxid
4）每个follower接收到写操作后，先将写操作存入队列中，并向leader反馈
5）当leader接收到集群中半数以上的follower的反馈，则代表本次写操作可以正常进行，
leader会再次广播给各个follower，让follower将写操作进行commit（真正写数据）
四、最后
有关zookeeper的内容还远不止这些，这篇更多的是介绍一些zookeeper的概念，少许客户端的命令操作就每放上来了，今天我们知道zookeeper的存储节点和监听机制，就可以实现很多功能。目前阶段了解这些就够了，有机会再深入的话，会写后续的文章来介绍。