zookeeper工作原理
简介
ZooKeeper 是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性的问题.
ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树种 的节点进行有效管理。从而来维护和监控存储的数据的状态变化。将通过监控这些数据状态的变化，从而可以达到基于数据的集群管理
架构图
Leader： ZooKeeper 集群工作的核心 事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务的调度者。 对于 create，setData，delete 等有写操作的请求，则需要统一转发给 leader 处理，leader 需要决定编号、执行操作，这个过程称为一个事务。
Follower： 处理客户端非事务（读操作）请求，转发事务请求给 Leader 参与集群 leader 选举投票2n-1台可以做集群投票 此外，针对访问量比较大的 zookeeper 集群，还可以新增观察者角色
Observer： 观察者角色，观察ZooKeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器处理 不会参与任何形式的投票只提供服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力，即增加并发的请求
Server：ZooKeeper总体中的一个节点，为客户端提供所有的服务。向客户端发送确认码以告知服务器是活跃的。
Ensemble：zooKeeper服务器组,形成ensemble所需的最小节点数为3。
作用
命名服务 - 按名称标识集群中的节点。它类似于DNS，但仅对于节点。
配置管理 - 加入节点的最近的和最新的系统配置信息。
集群管理 - 实时地在集群和节点状态中加入/离开节点。
选举算法 - 选举一个节点作为协调目的的leader。
锁定和同步服务 - 在修改数据的同时锁定数据。此机制可帮助你在连接其他分布式应用程序（如Apache HBase）时进行自动故障恢复。
高度可靠的数据注册表 - 即使在一个或几个节点关闭时也可以获得数据
存储结构
zookeeper存储模型
在图中，首先有一个由“/”分隔的znode。在根目录下，你有两个逻辑命名空间 config 和 workers 。
config 命名空间用于集中式配置管理，workers 命名空间用于命名。
在 config 命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，除了父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。此结构称为 ZooKeeper数据模型。
znode
zode组成
[zk: localhost:2181(CONNECTED) 9] stat /config/topicscZxid = 0x11ctime = Fri Nov 20 15:11:12 CST 2020mZxid = 0x11mtime = Fri Nov 20 15:11:12 CST 2020pZxid = 0x3dcversion = 2dataVersion = 0aclVersion = 0ephemeralOwner = 0x0dataLength = 0numChildren = 2
每个Znode由三个部分组成:
stat：此为状态信息，描述该Znode版本、权限等信息。
data：与该Znode关联的数据
children：该Znode下的节点
版本号 - 每个znode都有版本号，这意味着每当与znode相关联的数据发生变化时，其对应的版本号也会增加。当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用就很重要。
操作控制列表(ACL) - ACL基本上是访问znode的认证机制。它管理所有znode读取和写入操作。
时间戳 - 时间戳表示创建和修改znode所经过的时间。它通常以毫秒为单位。ZooKeeper从“事务ID"(zxid)标识znode的每个更改。Zxid 是唯一的，并且为每个事务保留时间，以便你可以轻松地确定从一个请求到另一个请求所经过的时间。
数据长度 - 存储在znode中的数据总量是数据长度。你最多可以存储1MB的数据
znode类型
Znode被分为持久（persistent）节点，顺序（sequential）节点和临时（ephemeral）节点。
持久节点 - 即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。默认情况下，除非另有说明，否则所有znode都是持久的。
临时节点 - 客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。因此，只有临时节点不允许有子节点。如果临时节点被删除，则下一个合适的节点将填充其位置。临时节点在leader选举中起着重要作用。
顺序节点 - 顺序节点可以是持久的或临时的。当一个新的znode被创建为一个顺序节点时，ZooKeeper通过将10位的序列号附加到原始名称来设置znode的路径。例如，如果将具有路径
/myapp 的znode创建为顺序节点，则ZooKeeper会将路径更改为 /myapp0000000001 ，并将下一个序列号设置为0000000002。如果两个顺序节点是同时创建的，那么ZooKeeper不会对每个znode使用相同的数字。顺序节点在锁定和同步中起重要作用
Sessions（会话）
会话对于ZooKeeper的操作非常重要。会话中的请求按FIFO顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。
客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合在超过服务器开启时指定的期间（会话超时）都没有从客户端接收到心跳，则它会判定客户端死机。
会话超时通常以毫秒为单位。当会话由于任何原因结束时，在该会话期间创建的临时节点也会被删除。
Watches（监视）
监视是一种简单的机制，使客户端收到关于ZooKeeper集合中的更改的通知。客户端可以在读取特定znode时设置Watches。Watches会向注册的客户端发送任何znode（客户端注册表）更改的通知。
Znode更改是与znode相关的数据的修改或znode的子项中的更改。只触发一次watches。如果客户端想要再次通知，则必须通过另一个读取操作来完成。当连接会话过期时，客户端将与服务器断开连接，相关的watches也将被删除。
zookeeper工作过程
一旦ZooKeeper集合启动，它将等待客户端连接。客户端将连接到ZooKeeper集合中的一个节点。它可以是领导或跟随者节点。一旦客户端被连接，节点将向特定客户端分配会话ID并向该客户端发送确认。如果客户端没有收到确认，它将尝试连接ZooKeeper集合中的另一个节点。 一旦连接到节点，客户端将以有规律的间隔向节点发送心跳，以确保连接不会丢失。
如果客户端想要读取特定的znode，它将会向具有znode路径的节点发送读取请求，并且节点通过从其自己的数据库获取来返回所请求的znode。为此，在ZooKeeper集合中读取速度快。
如果客户端想要将数据存储在ZooKeeper集合中，则会将znode路径和数据发送到服务器。连接的服务器将该请求转发给领导者，然后领导者将向所有的跟随着重新发出写入请求。如果只有大部分节点成功响应，而写入请求成功，则成功返回代码将被发送到客户端。 否则，写入请求失败。绝大多数节点被称为 Quorum 。
节点数规则
zookeeper最好有奇数个节点（3，5，7），因为：
有单个节点，那么当该节点失败时，ZooKeeper集群就会失效。不建议在生产环境中使用它，会导致"单点故障"。
有两个节点和一个节点故障，没有多数，因为两个节点中有一个不是多数节点。
有三个节点而一个节点故障，有大多数，这是最低要求。ZooKeeper集群在实际生产环境中必须至少有三个节点。
有四个节点而两个节点故障，将再次故障。类似于有三个节点，额外节点不用于任何目的，因此，最好添加奇数的节点，例如3，5，7。
工作流
Leader选举过程
Zookeeper 节点状态
LOOKING：寻找 Leader 状态，处于该状态需要进入选举流程
LEADING：领导者状态，处于该状态的节点说明是角色已经是 Leader
FOLLOWING：跟随者状态，表示 Leader 已经选举出来，当前节点角色是 follower
OBSERVER：观察者状态，表明当前节点角色是 observer
事务Id
ZooKeeper 状态的每次变化都接收一个 ZXID（ZooKeeper 事务 id）形式的标记。ZXID 是一个 64 位的数字，由 Leader 统一分配，全局唯一，不断递增。ZXID 展示了所有的ZooKeeper 的变更顺序。每次变更会有一个唯一的 zxid，如果 zxid1 小于 zxid2 说明 zxid1 在 zxid2 之前发生。
初始化Leader选举
若进行 Leader 选举，则至少需要两台机器，这里选取 3 台机器组成的服务器集群为例。初始化启动期间 Leader 选举流程如下图所示。
在集群初始化阶段，当有一台服务器 ZK1 启动时，其单独无法进行和完成 Leader 选举，当第二台服务器 ZK2 启动时，此时两台机器可以相互通信，每台机器都试图找到 Leader，于是进入 Leader 选举过程。选举过程开始，过程如下：
每个Server发出一个投票。由于是初始情况，ZK1 和 ZK2 都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的 myid 和 ZXID，使用(myid, ZXID)来表示，此时 ZK1 的投票为(1, 0)，ZK2 的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自 LOOKING 状态的服务器。
处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行比较，规则如下
- 优先检查 ZXID。ZXID 比较大的服务器优先作为 Leader。- 如果 ZXID 相同，那么就比较 myid。myid 较大的服务器作为Leader服务器。 对于 ZK1 而言，它的投票是(1, 0)，接收 ZK2 的投票为(2, 0)，首先会比较两者的 ZXID，均为 0，再比较 myid，此时 ZK2 的 myid 最大，于是 ZK2 胜。ZK1 更新自己的投票为(2, 0)，并将投票重新发送给 ZK2。
统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 ZK1、ZK2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出 ZK2 作为Leader。
改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为 FOLLOWING，如果是 Leader，就变更为 LEADING。当新的 Zookeeper 节点 ZK3 启动时，发现已经有 Leader 了，不再选举，直接将直接的状态从 LOOKING 改为 FOLLOWING。
运行态Leader选举
在 Zookeeper 运行期间，如果 Leader 节点挂了，那么整个 Zookeeper 集群将暂停对外服务，进入新一轮Leader选举。假设正在运行的有 ZK1、ZK2、ZK3 三台服务器，当前 Leader 是 ZK2，若某一时刻 Leader 挂了，此时便开始 Leader 选举。选举过程如下图所示。
变更状态。Leader 挂后，余下的非 Observer 服务器都会讲自己的服务器状态变更为 LOOKING，然后开始进入 Leader 选举过程。
每个Server会发出一个投票。在运行期间，每个服务器上的 ZXID 可能不同，此时假定 ZK1 的 ZXID 为 124，ZK3 的 ZXID 为 123；在第一轮投票中，ZK1 和 ZK3 都会投自己，产生投票(1, 124)，(3, 123)，然后各自将投票发送给集群中所有机器。
接收来自各个服务器的投票。与启动时过程相同。
处理投票。与启动时过程相同，由于 ZK1 事务 ID 大，ZK1 将会成为 Leader。
统计投票。与启动时过程相同。
改变服务器的状态。与启动时过程相同。