zk是干什么的？？？？？
分布式服务架构，解决统一命名，状态同步，集群管理，分布式应用配置项管理
为了减轻分布式应用程序所承担的协调任务,比如hadoop中多个NameNode节点，怎么管理与节点间信息同步，Hbase中master与slaver之间状态同步。
怎么干的？？？
既然是为了减轻协调任务，产生了角色，有老大leader，跟随的follower，观察的observer
leader，负责投票的发起和决议，更新系统参数状态。
follower，参与系统投票，接受返回客户端的请求
observer，接收写请求，转发给leader，不参与投票
为什么要选举？？？？？
心跳机制：Leader与Follower利用PING来感知对方的是否存活，当Leader无法相应PING时，将重新发起Leader选举。即Leader over了。
怎么样才能成为Leader？？？？
成为Leader的必要条件： Leader要具有最高的zxid；当集群的规模是n时，集群中大多数的机器（至少n/2+1）得到响应并follow选出的Leader。
服务器的选举状态，分为looking，leading，following和observer
looking:寻找leader状态，处于该状态需要进入选举流程
leading:leader状态，表明当前服务角色为leader
following:跟随者状态，leader已经选举出，表明当前为follower角色
observer:观察者状态
ZXID（zookeeper transaction id）：每个改变Zookeeper状态的操作都会形成一个对应的zxid，并记录到transaction log中。 这个值越大，表示更新越新
myid：服务器SID，一个数字,通过配置文件配置，唯一
SID：服务器的唯一标识
选举有两种情况，一是服务器启动的投票，二是运行期间的投票。
服务启动的投票：
每个服务器都发送一个投票（SID，ZXID），开始的时候都是选举自己当Leader，集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。针对每个投票，依据规则与自己的投票进行pk，pk后根据情况是否更新投票，再发送给其他机器，
规则：
优先检查ZXID，较大的优先成为Leader，
如果ZXID一样，SID较大的优先成为Leader，
统计票结果，是否满足要求选举了Leader，一旦确定了，每个服务器都更新自己的状态，Leader变更为Leading，Follower变更为following。
运行期间投票：
当Leader宕机后，余下的所非Observer的服务器都会将自己的状态变更为Looking，然后开启新的Leader选举流程，生成新的(SID,ZXID)信息，后续就与气动一样了，
选举实现的核心思想是：首先创建一个 EPHEMERAL 目录节点，例如“ /election ”。然后。每一个 ZooKeeper 服务器在此目录下创建一个 SEQUENCE| EPHEMERAL 类型的节点，例如“ /election/n_ ”。在 SEQUENCE 标志下， ZooKeeper 将自动地为每一个 ZooKeeper 服务器分配一个比前一个分配的序号要大的序号。此时创建节点的 ZooKeeper 服务器中拥有最小序号编号的服务器将成为 Leader 。
在实际的操作中，还需要保障：当 Leader 服务器发生故障的时候，系统能够快速地选出下一个 ZooKeeper 服务器作为 Leader 。一个简单的解决方案是，让所有的 follower 监视 leader 所对应的节点。当 Leader 发生故障时， Leader 所对应的临时节点将会自动地被删除，此操作将会触发所有监视 Leader 的服务器的 watch 。这样这些服务器将会收到 Leader 故障的消息，并进而进行下一次的 Leader 选举操作。但是，这种操作将会导致“从众效应”的发生，尤其当集群中服务器众多并且带宽延迟比较大的时候，此种情况更为明显。
在 Zookeeper 中，为了避免从众效应的发生，它是这样来实现的：每一个 follower 对 follower 集群中对应的比自己节点序号小一号的节点（也就是所有序号比自己小的节点中的序号最大的节点）设置一个 watch 。只有当 follower 所设置的 watch 被触发的时候，它才进行 Leader 选举操作，一般情况下它将成为集群中的下一个 Leader 。很明显，此 Leader 选举操作的速度是很快的。因为，每一次 Leader 选举几乎只涉及单个 follower 的操作。
————————————————————————————————
这个的意思就是：比如一个节点5watch节点4，当4开始有动作的时候5才开始，而不至于Leader有问题，同时所有的节点都发起投票。
这里有一个问题就是如何保证这个投票的ZXID？？？？
Paxos算法解决的什么问题呢，解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个全局写队列，所有写操作都必须 放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一致性。没错，就是这样，可是如果master挂了呢。
Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一
轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点接受了一个
编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己 数据不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。
这个是里边有几个zk术语写的不错
https://juejin.im/post/5bab525df265da0aa74f2f73
这个总结的知识点多，比较散不系统，可以看看
https://youzhixueyuan.com/architecture-design-and-application-scenario-of-zookeeper.html
zk的核心：Zab协议：恢复和广播，
这个连接比较详细
https://zhuanlan.zhihu.com/p/60352367
zk的watch机制就是实现管理分布式配置的，https://www.jianshu.com/p/abde992b9060
节点配置信息发生更改，watch管理器就会向客户端发起回调，实现管理分布式更新。
zk的监控可以用淘宝的或者zkui，
zkui安装需要用到maven环境，如果有bin模式的最好下载bin模式，不要用源码自己安装，配置连接：https://blog.csdn.net/yy1300326388/article/details/45027775
下载地址；https://maven.apache.org/download.cgi
注意，提前监测javac命令是否存在，
echo stat | nc 127.0.0.1 2181 可能提示命令没有在whitelist里边，需要给zkServer.sh配置一个参数
ZOOMAIN="-Dzookeeper.4lw.commands.whitelist=* ${ZOOMAIN}"
重启zkServer.sh restart即可
Zookeeper监控
对于zookeeper的监控，我们可以使用zk提供的4字命令返回的内容进行解析监控
当然，你也可以使用淘宝的开源工具TaoKeeper进行监控。Zookeeper的监控包括下面几个方面：
1、机器的CPU、内存、负载、硬盘IO利用率等基础监控，这些均可以网管系统实现；
2、ZK日志目录所在磁盘空间监控，这可以针对性的监控；
3、各节点的进程监控，配置自动拉起等；
4、各节点的连接数监控，配置峰值告警；
5、各节点的Watcher数监控，配置峰值告警；
6、使用四字命令，对每个节点进行检查，确保进程不僵死；
7、节点存活个数监控；
zk几个实际的应用及优化建议案例
https://data.qq.com/article?id=2863来源：51CTO
作者：aklaus
链接：https://blog.51cto.com/aklaus/2452450