Zookeeper总结与源码解析

概要

1、主要用于统一命名服务，统一配置服务（利用了ZK是一致性，KAFKA、HBase等这些都是使用ZK的统一配置服务的，KAFKA的Leader和Flower，KAFKA的ISR都是使用的这个）、统一集群管理（其实跟统一配置服务没啥区别，都是使用的ZK的watch机制）

2、启动时，如果超过TicketTime * limitLimit秒，Leader和Flower没有心跳，证明挂了

启动完后，超过tickettime * syncLimit秒，Leader和Flower没有心跳，证明挂了

3、节点类型：

持久节点：断开连接，节点依旧存在。

临时节点：若节点掉线，创建的节点自己删除。memcached分布式缓存可以使用短暂类型，若有个memcached节点挂了，从集群中移除，缓存客户端就不会再到这个节点上获取缓存了。

4、一个Leader跟随多个Flower，有半数以上的节点存活，整个集群还能工作。数据在所有节点都一致，所以ZK是遵循CAP原则的CP原则，数据的原子性和分区容忍性，不遵循可用性。因为Leader挂掉后，Leader重新选举需要30S—120S的时间，在这段时间内集群是不可用的，所以不满足A可用性；他可用让集群的一个或者多个节点挂掉，只要半数以上节点正常工作，整个集群就正常工作，所以满足P分区容忍性；根据ZK的写入原理，Leader会通知所有Flower节点写入，需要有一半写入成功才算写入成功，满足强一致性C

4、同一个Client的请求串行执行。

工作机制

观察者模式，一个人盯着另一个人，若另一个人干了啥事，ZK就开始通知观察的那些人，就开始干点啥事。比如KAFKA将leader注册到ZK，flower也注册在上面，flower在观察着，若leader挂了，ZK就通知flower说leader挂了，你赶紧来篡位吧。

选举机制

一般的集群都是通过配置Leader的，但是ZK是通过选举产生的。

每个节点启动后先选自己，若自己票数没够，就选票数多的节点，若票数都一样，就选myid比自己大的节点，直到有票数超过节点总数一半的节点，这就是Leader

监听原理

1、监听注册一次，有效一次，下次还想收到数据变化，得重新注册一次。监听命令 get /node1 watch；ls /node1 watch

2、客户端main函数（比如说zkCli.sh）启动后，启动一个连接zkServer的线程connect，一个监听的线程listener；

3、connect线程将listener事件发送给zkServer，zkServer将事件添加到列表

4、zkServer有数据或节点发送变化后（常用监听有监听数据节点和数据内容的变化），将消息发送给listener线程

5、listener调用自己的process()方法处理事件逻辑。

写数据流程

1、Client向zkServer发送请求，若server不是leader，将server转给Leader。

2、Leader将写请求广播给各个Flower写操作。Flower写成功后通知Leader，只要有半数以上的节点写成功了，就返回写成功给客户端。

ZAB协议详解

leader选举的时候将myid和zxid发送到各个flower，先比对zxid，有最新的zxid的就选为leader，若都一样，就选myid最大的。

源码解析