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