ZooKeeper整体介绍

https://segmentfault.com/a/1190000016349824

https://blog.csdn.net/gwd1154978352/article/details/78239633

 

1. ZooKeeper是什么

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

典型应用：

1）服务治理（适用于小型系统，大公司和大业务不适合）

2）配置管理（watch机制动态通知）

3）集群管理（Kafka & Hadoop & HBase）

4）分布式锁（有坑）

 

只要集群半数以上的节点可用，ZK对外就是可用的，通常节点个数推荐为奇数

 

顺序一致性

从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到ZooKeeper中。

原子性

所有事务请求的结果在集群中所有机器上的应用情况是一致的，也就是说要么整个集群所有集群都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。

单一视图

无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。

可靠性

一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。

实时性

通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

 

2. ZK数据存储 https://www.cnblogs.com/leesf456/p/6179118.html

1）ZK数据的数据结构是Tree结构，每个节点都有唯一的path，在内存中，所以性能很高，由单独的内存数据库ZKDatabase进行维护，ZKDatabase会定时dump 数据到硬盘作为snapshot

2）各个节点的数据是一致的（不过没法保证连续两次读取结果相同，因为数据会更新的），但是对于每次更新，要么成功，要么失败，没有中间状态

3）各节点启动时，会从硬盘加载snapshot数据，并跟leader比较做部分更新，最终跟leader一致

 

3. ZK数据节点

ZK数据节点是以ZNode的方式存在，大类分为两类，临时节点和永久节点，编号的一种使用场景可以用来对监控集群选master，比如选编号最小的做master

1）持久节点（PERSISTENT） 所谓持久节点，是指在节点创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。

2）持久顺序节点（PERSISTENT_SEQUENTIAL）其实就是多了个编号

在ZK中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序。基于这个特性，在创建子节点的时候（注意：在此节点下的子节点是由顺序的），可以设置这个属性，那么在创建节点过程中，ZK会自动为给定节点名加上一个数字后缀，作为新的节点名。这个数字后缀的上限是整型的最大值。

3）临时节点（EPHEMERAL）客户端没了，他就没了

和持久节点不同的是，临时节点的生命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提到的是会话失效，而非连接断开。另外，在临时节点下面不能创建子节点，注意是更具Session会话的失效时间来设定的。

4）临时顺序节点（EPHEMERAL_SEQUENTIAL）

临时顺序节点的特性和临时节点一致，同时是在临时节点的基础上，添加了顺序的特性。

 

 4. ZK集群中角色

1）Leader 负责所有的写请求、发起决议，当然也提供读请求服务

2）Learner有两种，Follower和Observer，处理读请求，把写请求转发给Leader；Follower可以在Leader选举中投票，Observer只能读数据主要是增加ZK系统的吞吐