zookeeper学习总结

引言

因为最近的项目使用到了kafka,而kafka又依赖于zookeeper,磨刀不误砍柴工，所以打算先学习zookeeper。学习过程中参考了以下的资料：

• W3Cschool zookeeper教程：

https://www.w3cschool.cn/zookeeper/zookeeper_applications.html

• 黑马程序员 zookeeper教程：

https://www.bilibili.com/video/BV1PW411r7iP

• 尚硅谷 Zookeeper教程:

https://www.bilibili.com/video/BV1PW411r7iP

学习过程中先阅读了一下W3C的教程，对zookeeper有了一个大致的了解。接下来听了黑马的视频教程，讲的比较细致全面，通俗易懂，适合入门。最后看一下尚硅谷的课程，贴近实战与面试。

zookeeper的架构

ZooKeeper为“客户端-服务器架构”，掌握zookeeper有助于我们更好的理解接下来的内容。
Client（客户端）：分布式应用集群中的一个节点，从服务器访问信息。对于特定的时间间隔，每个客户端向服务器发送消息以使服务器知道客户端是活跃的。当客户端连接时，服务器发送确认码。如果连接的服务器没有响应，客户端会自动将消息重定向到另一个服务器。
Server（服务器）：ZooKeeper总体中的一个节点，为客户端提供所有的服务。向客户端发送确认码以告知服务器是活跃的。

在windows上安装zookeeper

懒得安装虚拟机，所以在Windows上安装一个zookeeper。首先zookeeper服务端是运行在JVM上的，所以要保证电脑上安装了jdk。具体过程可以参考这篇文章：

http://www.mamicode.com/info-detail-1350141.html

zookeeper的数据模型

理解zookeeper的数据模型对理解zookerper十分重要。zookeeper的数据节点为树状结构，树中的各节点被称为 znode，一个znode可以有多个子节点，使用路径path来定位某个znode。
znode，兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时 间戳等数据结构，又像目录一样可以作为路径标识的一部分。

Sessions（会话）

客户端连接到服务器，将建立会话并向客户端分配会话ID 。客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合在超过服务器开启时指定的期间（会话超时）都没有从客户端接收到心跳，则它会判定客户端死机。
会话超时通常以毫秒为单位。当会话由于任何原因结束时，在该会话期间创建的临时节点也会被删除。持久化节点则不会受会话的影响。

znode的节点类型

zookeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即 被确定，并且不能改变。
临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临 时节点将被自动删除，当然可以也可以手动删除。ZooKeeper的临时节 点不允许拥有子节点。
持久化节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作 的时候，他们才能被删除

还有一种节点类型为顺序节点：顺序节点可以是持久的或临时的。当一个新的znode被创建为一个顺序节点时，ZooKeeper通过将10位的序列号附加到原始名称来设置znode的路径。顺序节点在锁定和同步中起重要作用。

事件监听机制

监视是一种简单的机制，使客户端收到关于ZooKeeper集合中的更改的通知。客户端可以在读取特定znode时设置Watches。Watches会向注册的客户端发送任何znode（客户端注册表）更改的通知。

Znode更改是与znode相关的数据的修改或znode的子项中的更改。只触发一次watches。如果客户端想要再次通知，则必须通过另一个读取操作来完成。当连接会话过期时，客户端将与服务器断开连接，相关的watches也将被删除。

zookeeper伪集群搭建

在windows上搭建了一个zookeeper伪集群，具体操作参见教程：

https://blog.csdn.net/ceasadan/article/details/52343734

注意双斜杠，路径不加双斜杠提示找不到myid路径。

leader选举机制

服务器状态：

looking：寻找leader状态。当服务器处于该状态时，它会认为当前集群中没有 leader，因此需要进入leader选举状态。

leading： 领导者状态。表明当前服务器角色是leader。

following： 跟随者状态。表明当前服务器角色是follower。

observing：观察者状态。表明当前服务器角色是observer。不参与集群的leader选举。

以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的 Zookeeper 集群，它们的 id 从 1-5，同时它们都是最新启动的，设这些服务器依序启动。
（1）服务器 1 启动，发起一次选举。服务器 1 投自己一票。此时服务器 1 票数一票，
不够半数以上（3 票），选举无法完成，服务器 1 状态保持为 LOOKING。
（2）服务器 2 启动，再发起一次选举。服务器 1 和 2 分别投自己一票并交换选票信息：
此时服务器 1 发现服务器 2 的 ID 比自己目前投票推举的（服务器 1）大，更改选票为推举服务器 2。此时服务器 1 票数 0 票，服务器 2 票数 2 票，没有半数以上结果，选举无法完成，服务器 1，2 状态保持 LOOKING。
（3）服务器 3 启动，发起一次选举。此时服务器 1 和 2 都会更改选票为服务器 3。此次投票结果：服务器 1 为 0 票，服务器 2 为 0 票，服务器 3 为 3 票。此时服务器 3 的票数已经超过半数，服务器 3 当选 Leader。服务器 1，2 更改状态为 FOLLOWING，服务器 3 更改状态为 LEADING。
（4）服务器 4 启动，发起一次选举。此时服务器 1，2，3 已经不是 LOOKING 状态，不会更改选票信息。交换选票信息结果：服务器 3 为 3 票，服务器 4 为 1 票。此时服务器 4服从多数，更改选票信息为服务器 3，并更改为FOLLOWING；
（5）服务器 5 启动，同 4 一样当小弟。