zk干货

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的监控包括下面几个方面：
一、机器的CPU、内存、负载、硬盘IO利用率等基础监控，这些都可以网管系统实现；
二、ZK日志目录所在磁盘空间监控，这能够针对性的监控；
三、各节点的进程监控，配置自动拉起等；
四、各节点的链接数监控，配置峰值告警；
五、各节点的Watcher数监控，配置峰值告警；
六、使用四字命令，对每一个节点进行检查，确保进程不僵死；
七、节点存活个数监控；

zk几个实际的应用及优化建议案例
https://data.qq.com/article?id=2863