Zookeeper相关

Zookeeper相关知识点总结

相关概念：

zookeeper是为分布式应用提供协调服务的Apache项目

基于观察者模式设计的分布式服务管理框架，负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，zookeeper就负责通知已经在zookeeper上注册的观察者做出相应的反应。

特点：

Zookeeper工作在集群中，对集群提供分布式协调服务，它提供的分布式协调服务具有如下的特点：

一个领导者（Leader），多个跟随者（Followers）组成的集群；

只要有半数以上的节点存活，zookeeper集群就可以正常服务。

顺序一致性

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

原子性

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

单一视图

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

可靠性

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

实时性

zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性。

数据结构：

zookeeper是一个树形结构

zookeeper的数据模型也可以理解为 linux/unix的文件目录：/usr/local

每一个节点称之为znode，它可以有子节点，也可以有数据

每一个节点分为临时节点和永久节点，临时节点在客户端断开后消失

每个zk节点都有各自的版本号，可以通过命令行来显示节点信息

每当结点数据发生变化，那么该节点的版本号会累加

删除/修改 过时节点，版本号不匹配则会报错

每个zk节点存储的数据不宜过大，几k即可

结点可以设置权限 acl， 可以通过权限来限制用户的访问
 

应用场景：

1、命名服务

在zookeeper的文件系统里创建一个目录，即有唯一的path,在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path,通过path即能互相探索发现。

2、配置管理

分布式环境下，需要进行配置文件的同步

1 一般要求同一个集群中，所有节点的配置信息是一致的，如Kafka集群

2 对配置文件修改后，希望能快速同步到各个节点

通过zookeeper实现配置管理

1 将配置信息写入zookeeper的一个ZNode中；

2 各个客服端服务器监听这个Znode；

3 一旦Znode中的数据被修改，zookeeper将通知到各个客服端服务器；

3、集群管理

分布式环境下，需要实时掌握每个节点的状态

    根据节点的实时状态进行一些调整

通过zookeeper实时监控节点状态

1 将节点信息写入zookeeper的一个ZNode中；

2 监听这个Znode获取实时状态变化；

4、服务器动态上下线        客户端实时洞察服务器上下线状态

5、分布式锁

        有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

        对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。厕所有言：来也冲冲，去也冲冲，用完删除掉自己创建的distribute_lock 节点就释放出锁。

        对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。

6、队列管理

两种类型的队列：

1、 同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。

2、队列按照 FIFO 方式进行入队和出队操作。

第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。

第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。 

7、软负载均衡

记录每台服务器的访问数，让访问数最少的服务器处理最新的客户端请求

选举机制：

选举流程简述

目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

• 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
• 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
• 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
• 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
• 服务器5启动，后面的逻辑同服务器4成为小弟。

节点类型：

PERSISTENT                持久化节点

客户端与zookeeper断开连接后，该节点依旧存在

PERSISTENT_SEQUENTIAL     顺序自动编号持久化节点，

客户端与zookeeper断开连接后，该节点依旧存在，这种节点会根据当前已存在的节点数自动加 1（顺序标号）

EPHEMERAL                 临时节点，

客户端session超时这类节点就会被自动删除

EPHEMERAL_SEQUENTIAL      临时自动编号节点

客户端与zookeeper断开连接后，该节点被删除，客户端session超时这类节点就会被自动删除

监听器原理：

（1）在Zookeeper的API操作中，创建main()主方法即主线程；

（2）在main线程中创建Zookeeper客户端（zkClient），这时会创建两个线程：

         线程connet负责网络通信连接，连接服务器；

         线程Listener负责监听；

（3）客户端通过connet线程连接服务器；

         图中getChildren("/" , true) ，" / "表示监听的是根目录，true表示监听，不监听用false

（4）在Zookeeper的注册监听列表中将注册的监听事件添加到列表中，表示这个服务器中的/path，即根目录这个路径被客户端监听了；

（5）一旦被监听的服务器根目录下，数据或路径发生改变，Zookeeper就会将这个消息发送给Listener线程；

（6）Listener线程内部调用process方法，采取相应的措施，例如更新服务器列表等。
 

https://www.cnblogs.com/shuaiandjun/p/9383655.html

https://www.cnblogs.com/dream-to-pku/p/9513188.html

https://www.cnblogs.com/zpb2016/p/5791632.html

https://blog.csdn.net/xiaojie_570/article/details/85683350