ZooKeeper 知识点

• zookeeper 命令：

命令	说明
./zkServer.sh start	启动ZooKeeper（终端执行）
./zkServer.sh stop	停止ZooKeeper（终端执行）
./zkCli.sh	启动cli（终端执行）
create [znode-path] [desc]	创建znode，默认为永久znode（desc不能省略）
create -s [znode-path] [desc]	添加顺序znode（desc不能省略）
create -e [znode-path] [desc]	添加临时znode（desc不能省略）
get [znode-path]	获取znode相关数据和元数据
set [znode-path] [desc]	设置znode
stat [znode-path]	获取znode元数据（不显示相关数据）
ls [znode-path]	列出和显示znode的 children
rmr [znode-path]	删除该znode及其所有子节点
delete [znode-path]	只适用于删除没有子节点的znode

• ZooKeeper的架构组成：

组成部分	描述
client	客户端。一旦连接到节点，客户端将以定期间隔向节点发送心跳，以确保连接不会丢失。
Ensemble	ZooKeeper服务器组。
server	服务器。分为server leader和server follower。向客户端发送确认，通知服务器处于活动状态。
server leader	服务器领导者节点。在服务启动时选举产生。
server follower	服务器跟随节点。

• 分层命名空间
  ZooKeeper节点称为 znode 。 每个znode由一个名称标识，并用路径(/)序列分隔。
  在图中，首先有一个根 znode 以“/"分隔。 在根目录下，您有两个逻辑命名空间 config 和 workers 。
  config 命名空间用于集中配置管理， workers 命名空间用于命名。
  在 config 命名空间下，每个znode最多可存储1MB的数据。 这类似于UNIX文件系统，除了父znode也可以存储数据。 这种结构的主要目的是存储同步数据并描述znode的元数据。 此结构称为 ZooKeeper数据模型。
  

• ZooKeeper数据模型中的每个znode都维护着一个 stat 结构。 stat仅提供znode的元数据。 它由版本号，操作控制列表(ACL)，时间戳和数据长度组成

1. 版本号 - 每个znode都有版本号，这意味着每次与znode关联的数据发生更改时，其对应的版本号也会增加。 当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用很重要。
2. 操作控制列表(ACL) - ACL基本上是访问znode的认证机制。 它管理所有znode读取和写入操作。
3. 时间戳 - 时间戳表示创建和修改znode所经过的时间。 它通常表示为毫秒。 ZooKeeper标识“事务ID"(zxid)对znode的每个更改。 Zxid 是唯一的，并且为每个事务维护时间，以便您可以轻松地确定从一个请求到另一个请求的时间。
4. 数据长度 - 存储在znode中的数据总量是数据长度。 您最多可以存储1MB的数据。

• Znode的类型有：永久znode、临时znode、顺序znode。
  默认情况下，除非另有说明，否则所有znode都是永久znode类型。
  临时znode在领导选举中发挥重要作用。当会话过期或客户端断开连接时，临时znode (flag: e)将被自动删除。
  顺序znode可以是持久node类型或临时znode类型。 顺序znode在锁定和同步中起重要作用。

• 会话
  会话对于ZooKeeper的操作非常重要。 会话中的请求按FIFO顺序执行。 一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。
  客户端以特定的时间间隔发送心跳以保持会话有效。 如果ZooKeeper集合没有从客户端接收到超过在服务启动时指定的时间段(会话超时)的心跳，则它决定客户端死亡。
  会话超时通常用毫秒表示。 当会话由于任何原因结束时，在该会话期间创建的临时znode也会被删除。

• 观察者
  观察者(Watcher)是一种简单的机制，使客户端得到关于ZooKeeper组中的更改的通知。客户端可以在读取特定znode时设置Watcher。Watcher会向注册的客户端发送任何znode(客户端注册表)更改的通知。
  Znode更改是与znode的相关数据的修改或znode的孩子的更改。 只触发一次watcher。 如果客户端想要再次通知，则必须通过另一个读取操作来完成。
  当连接会话过期时，客户端将与服务器断开连接，相关联的watcher也将被删除。

• 如果客户端想要读取特定的znode，会向具有znode路径的节点发送读取请求，并且节点通过从其自己的数据库获取该znode来返回给客户端。
  如果客户端想要将数据存储在ZooKeeper集合中，它会将znode路径和数据发送到服务器。 连接的服务器将该请求转发给领导者，然后领导者将向所有的跟随者重新发出写入请求。 如果只有大多数节点成功响应，则写请求将成功，并且成功的返回码将被发送到客户端。 否则，写入请求将失败。 严格的大多数节点被称为 Quorum 。

• ZooKeeper服务器组，写入过程比读取过程昂贵，因为所有节点都需要在其数据库中写入相同的数据。
  因此，与具有用于平衡环境的大量节点相比，具有更少数量的节点(3、5、7)是更好的。

• Zookeeper 工作流
  

组成部分	描述
Write	写过程由领导节点处理。 领导者将写请求转发到所有znode，并等待znode的答案。 如果znode的一半回复，则写入过程完成。
Read	读取由特定连接的znode在内部执行，因此不需要与群集交互。
复制数据库	它用于在zookeeper中存储数据。 每个znode都有自己的数据库，每个znode在一致性的帮助下每次都有相同的数据。
Leader	Leader是负责处理写入请求的Znode。
Follower	关注者从客户端接收写请求并将它们转发到领导znode。
请求处理器	只存在于领导节点。 它管理来自从节点的写请求。
原子广播	负责将从领导节点到从节点的变化广播。

• leader的选择机制，zookeeper提供了三种方式：
  LeaderElection
  AuthFastLeaderElection
  FastLeaderElection
  默认的算法是FastLeaderElection

• FastLeaderElection 选举流程简述：
  目前有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成为小弟。