深入Zookeeper技术

Zookeeper可以看作是Hadoop生态系统中各个组件的统一协调管理者（分布式协调技术）,主要解决分布式应用一致性问题，是为分布式应用所设计的高可用、高性能的开源协调服务：分布式锁服务—>解决分布式环境中的多个进程之间的同步控制，防止造成脏数据。
目的：增加集群的稳定性、持续性、有序性和高效性。
面临的问题:网络的不可靠性
特性：简单、富有表现力、高可用性、松耦合方式、资源库。
Zookeeper集群中各个节点分为 两个角色：Leader、Flower。
Leader可以接受Client请求，也可以接受其他Server转发的请求，负责更新系统的状态。Flower也可以接受Client请求，如果是写请求将转发给Leader来更新系统，读请求则由Flower的内存数据库直接相应。
Zookeeper的数据 结构也是采用树形层次结构，树当中的每个节点都被当作Zonde，类似文件但没有文件和目录,Znode（具有唯一的标识，自动编号）作为保存数据的容器，Znode中的数据可以有多个版本。其中/zookeeper用来保存Zookeeper的配额管理信息，不能删除。
Zookeeper的客户端和服务器采用长连接来通信，通过心跳机制保持连接，连接状态称为session，
每个Znode由三部分组成：
（1）stat：此为状态信息，描述Zonde的版本、权限等信息
（2）data：与Zonde关联的数据
（3）children：该Zonde的下的子节点
每个Zonde管理调度数据，很小，数据至多为1MB。
Zookeeper节点分为两种：临时节点和永久节点，节点的类型在创建时就已经确定，不可以改变。
临时节点：生命周期依赖于创建他们的会话，一旦会话（session）结束，临时节点就被自动删
除，临时节点不 被允许拥有子节点。
永久节点：不依赖于会话，且只有在客户端显示执行删除操作时，才可以被删除。
通过内部的计数器引入顺序节点来保证接节点名字的唯一性和顺序性。

---

Zxid：64位的数字，高32位是epoch用来标识leader关系是否改变，每个leader被选举出来，都会有一个新的epoch，低32位是递增计数。
致使Zookeeper节点状态改变的每一个操作都会使节点接受到一个Zxid格式的时间戳，并且这个时间戳是全局有序：每个节点的改变都将产生一个唯一的Zxid。实际上，Zookeeper的每个节点维护着三个Zxid值，分别为：
cZxid：节点创建时间对应的时间戳
mZxid：节点修改时间对应的时间戳
pZxid：最近一次节点修改时间对应时间的时间戳
在命令行输入：get /node ————-即可获得该节点的属性。
具体Zookeeper集群安装教程见：https://blog.csdn.net/qq_25948717/article/details/80958969