zookeeper概述
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.zookeeper概述
1>.什么是zookeeper
zookeeper是一个开源的分布式的，为分布式应用提供微服务的Apache项目,它是由之前雅虎公司开源的。
zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架。
zookeeper负责存储和管理大家都关心的数据，然后接收观察者的注册，一旦这些数据的状态发生变化，zookeeper将负责通知已经在zookeeper上注册的那些观察者做出相应的反应。
综上所述，我们可以说：zookeeper = 文件系统 + 通知机制。
2>.zookeeper的特点
zookeeper是一个领导者(Leader)和多个跟随者(Follower)组成的集群,集群中只要有半数以上节点存活，zookeeper集群就能正常服务。
全局数据一致:
每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
更新请求顺序进行:
来自一个Client的更新请求按其发送顺序依次运行。
数据更新原子性:
一次数据更新要么成功，要么失败。
实时性:
在一定时间范围内，Client能读到最新数据。
3>.zookeeper数据模型
zookeeper的数据模型的结构与unix文件系统很类似，整体上可以看作是一棵树，每个节点称作一个Znode。
每一个Znode默认能够存储1MB(1M的数据已经很大的，因为它仅存放配置信息)的数据，每个ZNode都可以通过其路径唯一标识。
温馨提示:
zookeeper和Linux系统目录结构在逻辑上有一个很大的区别在于Linux是有目录和文件的区分，而zookeeper并不区分文件和目录,只有znode。
zookeeper每一个Znode既可以存储数据也可以有子znode。
4>.应用场景
统一命名服务: 在分布式环境下，经常需要对应用/服务进行统一命名，便于标识。例如:IP地址不容易记住，而域名容易记住。 统一配置管理; 1>.在分布式环境下，配置文件同步非常常见: (a)一般要求一个集群中，所有节点的配置信息是一致的，比如kafka集群; (b)对配置文件修改后，希望能够快速同步到各个节点上; 2>.配置管理可交由zookeeper实现 (a)可将配置信息写入zookeeper上的一个ZNode; (b)各个客户端服务器监听这个ZNode; (c)一旦Znode中的数据被修改，zookeeper将通知已经在其注册的各个客户端服务器; 主备选举: 大数据集群大多数都是分布式集群,以HDFS,YARN集群的主备选举都可以基于zookeeper来实现。 统一集群管理: 1>.分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整; 2>.zookeeper可以实现实时监控节点状态变化 (a)可将节点信息写入zookeeper上的一个Znode; (b)监听这个Znode可获得它的实时状态变化; 服务器节点动态上下线; 客户端服务器能实时洞察到服务器上下线的变化。 软负载均衡: 在zookeeper中记录每台服务器的访问数,让访问数量最少的服务器去处理新的客户端请求。
5>.下载zookeeper
官方地址: https://zookeeper.apache.org/ 下载地址: https://zookeeper.apache.org/releases.html 官方文档: https://zookeeper.apache.org/doc/current/index.html
二.zookeeper的znode类型
持久(Persistent)化znode:
客户端与zookeeper断开连接后，该节点依旧存在。即只要你不手动删除，它就会一直存在。默认创建的就是持久的znode。
持久化顺序编号znode:
客户端与zookeeper断开连接后，该节点依旧存在，只是zookeeper给该znode名称进行顺序编号。
临时(Ephemeral)znode:
客户端与zookeeper断开连接后，该节点被删除。
临时顺序编号znode:
客户端与zookeeper断开连接后，该znode被删除，只是zookeeper给该znode名称末尾进行顺序编号。
温馨提示:
创建znode时设置顺序标识，znode名称会附加一个值(顺序号)，该值是一个单调递增的计数器，由父节点维护。
在分布式系统中，顺序号可以被用于所有的时间进行全局排序，这样客户端可以通过顺序号推断时间的顺序。
三.znode状态信息
[zk: hadoop102.yinzhengjie.org.cn(CONNECTED) 9] stat /yinzhengjie cZxid = 0x10000000c ctime = Tue May 12 07:17:12 CST 2020 mZxid = 0x10000001a mtime = Tue May 12 07:41:00 CST 2020 pZxid = 0x10000001e cversion = 4 dataVersion = 2 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 8 numChildren = 4 [zk: hadoop102.yinzhengjie.org.cn(CONNECTED) 10] [zk: hadoop102.yinzhengjie.org.cn(CONNECTED) 10] ls /yinzhengjie [test1, test2, test30000000002, test40000000003] [zk: hadoop102.yinzhengjie.org.cn(CONNECTED) 11] 以上是stat命令的输出结果，以下对每个键值对的概要说明: cZxid: 创建节点的事务zxid.每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。 事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。 cZxid是由64bits(8个字节)组成，我们以"0x10000000c"为例,这是一个十六进制数字,从左到右第一个数字1表示的是在zookeeper第几次启动的,后面的"0000000c"表示在第13次创建的该节点,换句话说，在zookeeper的第一次启动的第13次操作时创建的/yinzhengjie这个znode。 尽管我们修改了该znode的数据也不会修改该值。 ctime: 表示znode被创建的毫秒数(从1970年开始) mzxid: 表示znode最后更新的事务zxid mtime: znode最后修改的毫秒数(从1970年开始) pZxid: znode最后更新的子节点zxid cversion: znode子节点变化号，znode子节点修改次数 dataversion: znode数据变化号 aclVersion: znode访问控制列表的变化号，0表示没有配置ACL。 ephemeralOwner: 如果是临时znode，这个是znode拥有者的session id。如果不是临时节点则是0。 dataLength: znode的数据长度 numChildren: znode子节点数量
四.监听器原理
(1)在main线程中创建Zookeeper客户端(new ZooKeeper),这时会创建两个线程，一个是负责网络连接通信(sendThread),一个负责监听(eventThread)；
(2)通过客户端sendThread线程将注册的监听事件发送给服务端zookeeper集群;
(3)在服务端zookeeper集群的注册监听列表中将注册的监听事件添加到列表中;
(4)服务端zookeeper监听到有数据或路径变化，就会将这个消息发送给客户端的eventThread线程;
(5)客户端的eventThread线程内部调用了process()方法;
五.ZAB协议
1>. paxos算法
Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。 Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》。 自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。 然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。 博主推荐阅读: https://zhuanlan.zhihu.com/p/31780743
2>.zab协议
Zab协议的全称是 Zookeeper Atomic Broadcast （Zookeeper原子广播）。Zookeeper是通过Zab协议来保证分布式事务的最终一致性。 Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议 ，是Zookeeper保证数据一致性的核心算法。Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。 在Zookeeper中主要依赖Zab协议来实现数据一致性，基于该协议，zk实现了一种主备模型（即Leader和Follower模型）的系统架构来保证集群中各个副本之间数据的一致性。
这里的主备系统架构模型，就是指只有一台客户端（Leader）负责处理外部的写事务请求，然后Leader客户端将数据同步到其他Follower节点。 Zookeeper客户端会随机的链接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。 Zab协议的特性： Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。 Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。 博主推荐阅读: https://www.jianshu.com/p/2bceacd60b8a
3>.博主推荐阅读
分布式协调服务Zookeeper扫盲篇: https://www.cnblogs.com/yinzhengjie/p/10742994.html
六.选举机制
在选举leader节点时，首先会比较事务id，其次比较myid，如果集群中已经有一半机器参加选举，那么此leader就是整个集群中的leader。
为了方便理解，我画了两幅图，便于理解上面的一句话，当事物id一致时推选leader如下：
当事物id不一致时推选leader如下：
七.写数据流程
(1)Client向zookeeper的Server上写数据,就会发送一个写请求;
(2)如果server不是Leader角色，那么该server会把接受到的请求进一步转发给Leader,因为zookeeper集群的每台Server里面都记录着Lader节点,这个Leader会将写请求发广播给各个Server，比如s101和s102，各个Server会将该写请求加入待写队列吗，并向Leader发送成功消息;
(3)当Leader收到半数以上Server的成功信息，说明该写操作可以执行。Leader回想各个Server发送提交消息，各个Server收到信息后会落实队列里的写请求，此时写成功;
(4)Sever会进步通知Client数据写成功了，这时九任务整个写操作成功。