疏漏总结(二十四)——Zookeeper

首先，什么是ZK？

zookeeper是我们经常会去使用的一个服务一致性组件，主要用来解决一些关于数据管理的问题。Zookeeper也可以作为一个数据库，但是和其他数据库的区别在于，zk不适合去存储海量的数据，主要还是用于去进行服务一致性的调度，此外，它还具备发布和订阅功能。

zk的读请求可以由任何一台机器去完成，但是写请求，需要所有节点打成一致之后才能执行，所以，当机器变多的时候，吞吐量就会下降了。

此外，有序性也是zk的一个非常重要的特性，这个在zk的分布式锁中也是非常有体现的，zk的所有更新都是有序进行的，因为所有的更新都配备了一个时间戳，叫做zxid，而读请求只会相对于写请求是有序进行的。

关于zk的文件系统

zk的结点可以叫做znode，所有的znode都可以去存储数据，并且可以任意存储任意类型的数据，但是有一个问题就是，这种树形结构，导致zk的每一个znode不能存储太多的数据，上限是1MB。

znode一共有四种类型，它们都拥有自己的特性：

• persistent-持久化目录结点

客户端和zk断开连接之后，这个结点依旧存在

• persistent-sequential-持久化顺序编号目录结点

客户端和zk断开连接之后，这个结点依旧存在，只是zk给该结点进行顺序编号

• ephemeral-临时目录结点

客户端和zk断开连接之后，这个结点不存在了

• ephemeral-sequential-临时顺序目录结点

客户端和zk断开连接之后，这个结点不存在，只是zk给该结点进行顺序编号

那么znode除此之外还有什么作用吗？

znode可以在集群启动的时候和客户端建立一个watcher连接，客户端可以监听到结点的状态，当结点的状态发生改变的时候，客户端可以根据状况作出相应的逻辑判断。

那么到底什么是watcher机制呢？

说白了就是对znode进行一个监听，发生改变了立马告知客户端。

其特点如下：

zk是如何实现配置管理的

我们一般都会将程序的一些配置信息存储在znode上，在配置改变的时候，我们可以通过watcher机制，通知给其他节点，进行一个配置管理的同步。

zk的分布式锁是如何实现的

其实zk的分布式锁和文件系统是有很强关联的，zk的分布式锁分为两类，一个是保持独占，一个是控制时序。

第一种情况，我们可以将znode看成是一把锁，通过createZode方法去创建，然后创建成功的也就获取到了锁，用完删除，就ok了。

第二种情况，我们针对要获取锁的的客户端创建临时顺序编号，顺序最小的获取锁。

具体的过程是，createnode之后，用getChildren方法来获取所有的子节点的path，如果发现自己创建的这个node是序号最小的，就直接获取到锁，如果不是，就要对那个更小的结点用exist()方法去找，然后把当前关注节点删除，然后不断这样找到最小的去获取到锁

Zookeeper的工作原理是什么

zk的工作核心其实就在于是原子广播，这个机制保证了各个节点的同步，也就是ZAB协议，ZAB协议有两种，一种是恢复，一种是广播。在服务启动的时候，会进入恢复，当领导者被选举出来并且大多数的状态信息也完成之后，就会进入到广播模式。

zk是如何保证顺序一致性的？

zk 里面其实也是有transaction id的，每次发起一个执行请求后，就会生成一个zxid(位)，其中高32位叫做epoch，如果leader变了，会自增，低32位递增技术，当产生一个事务请求的时候，如果确定其他的结点都可以执行，那么才会执行。

zk的选举过程

当失去leader或者是失去了大量的follower的时候就会重新选举leader，选举的方法有两种，第一种是basic paxos，第二种是fast paxos。

• basic paxos

首先Server会推出一个选举线程专门用于选举，然后这个选举线程会针对每一个server进行一个询问，记录下他们的myid和zxid，再采集他们期望的leader的myid和zxid添加到选举列表，然后按照zxid排序，从大到小找出选举自己次数大于1/2的的时候，那么所对应的情况就是，这个server就是新的老大。

• fast paxos

直接向其他server提议自己成为leader，然后挨个进行询问和恢复，总能选出老大来。