1. 设计目标2. 使用场景3. Zookeeper特性
3.1 会话3.2 数据模型3.3 节点类型3.4 节点状态属性3.5 ACL机制 4. 常用命令
4.1 服务端常用命令4.2 客户端常用命令4.3 ACL常用命令
4.3.1 Scheme4.3.2 id4.3.3 Permission4.3.4 ACL 命令 4.4 四字命令 5. 查看日志6. 集群
6.1 集群特点6.2 集群角色6.3 一致性协议
6.3.1 消息广播6.3.2 崩溃恢复 6.4 Server 状态
1. 设计目标简单的数据结构：共享的树形结构，类似文件系统，存储于内存；可以构建集群：避免单点故障，3-5 台机器就可以组成集群，超过半数正常工作就能对外提供服务；顺序访问：对于每个读请求，zk 会分配一个全局唯一的递增编号，利用这个特性可以实现高级协调服务；高性能：基于内存操作，服务于非事务请求，适用于读操作为主的业务场景。3 台 zk集群能达到 13w QPS； 2. 使用场景
数据发布订阅负载均衡命名服务Master选举集群管理配置管理分布式队列分布式锁 3. Zookeeper特性
Zk 的特性包括会话、数据节点，版本，Watcher，ACL 权限控制，集群角色等， 常用特性数据节点与 Watcher 3.1 会话
客户端与服务端的一次会话连接，本质是 TCP 长连接，通过会话可以进行心跳检测和数据传输；客户端和服务端之间的任何交互操作都与会话有关
Zk 客户端和服务端成功连接后，就创建了一次会话，ZK 会话在整个运行期间的生命周期中，会在不同的会话状态之间切换，这些状态包括：
CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE一旦客户端开始创建 Zookeeper 对象，那么客户端状态就会变成 ConNECTING 状态， 同时客户端开始尝试连接服务端，连接成功后，客户端状态变为 CONNECTED，通常情况下，由于断网或其他原因，客户端与服务端之间会出现断开情况，一旦碰到这种情况，Zookeeper 客户端会自动进行重连服务，同时客户端状态再次变成 CONNCTING，直到重新连上服务端后，状态又变为 CONNECTED，在通常情况下，客户端的状态总是介于 ConNECTING 和 ConNECTED 之间。但是，如果出现诸如会话超时、权限检查或是客户端主动退出程序等情况，客户端的状态就会直接变更为 CLOSE 状态
3.2 数据模型
ZooKeeper 的视图结构和标准的 Unix 文件系统类似，其中每个节点称为“数据节点”或 ZNode，每个 znode 可以存储数据，还可以挂载子节点，因此可以称之为“树”每一个 znode 都必须有值，如果没有值，节点是不能创建成功的。
在 Zookeeper 中，znode 是一个跟 Unix 文件系统路径相似的节点，可以向这个节点中存储或获取数据通过客户端可对 znode 进行增删改查的操作，还可以注册 watcher 监控 znode 的变化 3.3 节点类型
- 持久节点（PERSISTENT）
create /node1 value create /node1/child1 value
持久节点可以创建子节点，而且会话断开节点还会继续存在
- 持久顺序节点（PERSISTENT_SEQUENTIAL）
create -s /node1 value
会自动在node1后面添加一个自动加 1 的序号
- 临时节点（EPHEMERAL）
create -e /node1 value
临时节点在会话断开后，节点就没有了；临时节点下面不能创建子节点
- 临时顺序节点（EPHEMERAL_SEQUENTIAL）
create -e -s /node1 value
对于持久节点和临时节点，同一个znode下，节点的名称是唯一的！创建 znode 时设置顺序标识，znode 名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序 3.4 节点状态属性
stat /node13.5 ACL机制
scheme:id:permissions，第一个字段表示采用哪一种机制，第二个id表示用户，permissions表示相关权限（如只读，读写，管理等）。zookeeper提供了如下几种机制（scheme）：world: 它下面只有一个id, 叫anyone, world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的auth: 它不需要id, 只要是通过authentication的user都有权限（zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)digest: 它对应的id为username:base64(SHA1(password))，它需要先通过username:password形式的authenticationip: 它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段 4. 常用命令 4.1 服务端常用命令
# 启动ZK服务 bin/zkServer.sh start # 查看ZK服务状态 bin/zkServer.sh status # 停止ZK服务 bin/zkServer.sh stop # 重启ZK服务 bin/zkServer.sh restart4.2 客户端常用命令
使用 zkCli.sh -server 127.0.0.1:2181 连接到 ZooKeeper 服务，连接成功后，系统会输出 ZooKeeper 的相关环境以及配置信息
1、显示根目录下、文件： ls / 使用 ls 命令来查看当前 ZooKeeper 中所包含的内容
2、显示根目录下、文件： ls -s / 查看当前节点数据并能看到更新次数等数据
3、创建文件，并设置初始内容： create /zk “test” 创建一个新的 znode节点“ zk ”以及与它关联的字符串
4、获取文件内容： get /zk 确认 znode 是否包含我们所创建的字符串
5、修改文件内容： set /zk “zkbak” 对 zk 所关联的字符串进行设置
6、删除文件： delete /zk 将刚才创建的 znode 删除，如果存在子节点删除失败
7、递归删除：deleteall /node1 将含有子节点的 znode 删除，同时将子节点一起删除
8、退出客户端： quit
9、所有命令：随便输错一个命令，就会有命令提示
world：默认方式，相当于全世界都能访问
auth：代表已经认证通过的用户(可以通过 addauth digest user:pwd 来添加授权用户)
digest：即用户名:密码这种方式认证，这也是业务系统中最常用的
ip：使用 Ip 地址认证
id 是验证模式，不同的 scheme，id 的值也不一样。
scheme 为 auth 时: username:password
scheme 为 digest 时: username:base64(SHA1(password))
scheme 为 ip 时: 客户端的 ip 地址。
scheme 为 world 时: anyone。
4.3.3 Permission
CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限，这 5 种权限简写为 crwdaCREATE：创建子节点的权限DELETE：删除节点的权限READ：读取节点数据的权限WRITE：修改节点数据的权限ADMIN：设置子节点权限的权限 4.3.4 ACL 命令
getAcl: 获取指定节点的ACL信息
create /node1 node1 # 创建一个节点 create /node1/child1 child1 # 创建一个子节点 getAcl /node1/child1 # 获取该节点的 acl 权限信息
setAcl: 设置指定节点的ACL信息
setAcl /node1 world:anyone:crwa # 设置该节点的 acl 权限，这里设置没有删除权限 getAcl /node1 # 获取该节点的 acl 权限信息 delete /node1/child1 # 由于没有 d 权限，所以提示无法删除
addauth: 注册会话授权信息
addauth digest user1:123456 # 需要先添加一个用户，然后才可以拿着这个用户去设置需要用户名密码访问的权限 setAcl /node1 auth:user1:123456:crwa getAcl /node1 create /node1/child2 child2 delete /node1/child2 # 由于没有 d 权限，所以提示无法删除
重新登录客户端，在创建子节点
ls /node1 # 没有权限无法访问 create /node1/child3 child3 # 没有权限无法创建子节点 addauth digest user1:123456 # 重新新增权限后可以访问了
auth 与 digest 的区别就是，前者使用明文密码进行登录，后者使用密文密码进行登录
setAcl /node1 auth:user1:HYGa7IZRm2PUBFiFFu8xY2pPP/s=:crwa # 加密方法 base64(SHA1(password))
限制ip
setAcl /node1 ip:192.168.42.100:crwa4.4 四字命令
ZooKeeper 支持某些特定的四字命令字母与其的交互。用来获取 ZooKeeper 服务的当前状态及相关信息。可通过 nc 向 ZooKeeper 提交相应的命令需要提前安装nc
yum install nc
将这些指令添加在白名单里，在bin目录下的zkServer.sh脚本中添加下面的代码，否则会提示stat is not executed because it is not in the whitelist.错误
#添加ＶＭ环境变量-Dzookeeper.4lw.commands.whitelist=*
ZOOMAIN="-Dzookeeper.4lw.commands.whitelist=* ${ZOOMAIN}"
echo stat|nc 127.0.0.1 2181 # 查看哪个节点被选择作为follower或者leader
echo ruok|nc 127.0.0.1 2181 # 测试是否启动了该Server，若回复imok表示已经启动。 echo dump| nc 127.0.0.1 2181 # 列出未经处理的会话和临时节点。 echo kill | nc 127.0.0.1 2181 # 关掉server echo conf | nc 127.0.0.1 2181 # 输出相关服务配置的详细信息。 echo cons | nc 127.0.0.1 2181 # 列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息 echo envi |nc 127.0.0.1 2181 # 输出关于服务环境的详细信息（区别于 conf 命令）。 echo reqs | nc 127.0.0.1 2181 # 列出未经处理的请求。 echo wchs | nc 127.0.0.1 2181 # 列出服务器 watch 的详细信息。 echo wchc | nc 127.0.0.1 2181 # 通过 session 列出服务器 watch 的详细信息，它的输出是一个与 watch 相关的会话的列表。 echo wchp | nc 127.0.0.1 2181 # 通过路径列出服务器 watch 的详细信息。它输出一个与 session 相关的路径。5. 查看日志
dataDir，存放了数据快照文件（snapshot.xxxx）和事务日志文件（log.xxxx）
事务日志，使用 bin/zkTxnLogToolkit.sh ，然后指定文件
bin/zkTxnLogToolkit.sh -d /zookeeper/data/single/version-2/log.3
数据快照，使用 bin/zkSnapShotToolkit.sh ，然后指定文件
bin/zkSnapShotToolkit.sh -d /zookeeper/data/single/version-2/snapshot.2f6. 集群 6.1 集群特点
顺序一致性：客户端的更新顺序与它们被发送的顺序相一致。原子性：更新操作要么成功要么失败，没有第三种结果。单一视图：无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。可靠性：一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。实时性：连接上一个服务端数据修改，所以其他的服务端都会实时的更新，不算完全的实时，有一点延时角色轮换避免单点故障：当 leader 出现问题的时候，会选举从 follower 中选举一个新的 leader 6.2 集群角色
Leader：集群工作机制中的核心
事务请求的唯一调度和处理者，保证集群事务处理的顺序性
集群内部个服务器的调度者(管理 follower，数据同步)Follower：集群工作机制中的跟随者
处理非事务请求，转发事务请求给 Leader
参与事务请求 proposal 投票
参与 leader 选举投票Observer 观察者：3.30 以上版本提供，和 follower 功能相同，但不参与任何形式投票
处理非事务请求，转发事务请求给 Leader
提高集群非事务处理能力
6.3 一致性协议配置：server.3=192.168.0.102:2888:3888:observer
少数服从多数；2. 角色轮换避免单点故障
ZAB 协议是为 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来解决分布式系统的数据一致性问题；zab 协议核心是在整个 zookeeper 集群中只有 leader 节点将所有客户端的写操作转化为事务（提议 proposal），leader 节点在数据写完之后，向所有的 follower 节点发送数据广播请求（数据复制），等所有的 follower 节点的反馈，只要超过半数的 follower 节点反馈 ok，leader 节点会向所有 follower 服务器发送 commit 消息，既将 leader 节点上的数据同步到 follower 节点之上。
zab 可以分成两部分，包括消息广播和崩溃恢复。
正常情况下，当客户端对 zk 有写的数据请求时，leader 节点会把数据同步到 follower 节点，这个过程其实就是消息的广播模式。在新启动的时候，或者 leader 节点奔溃的时候会要选举新的 leader，选好新的 leader 之后会进行一次数据同步操作，整个过程就是奔溃恢复。 6.3.1 消息广播
为了保证分区容错性，zookeeper 是要让每个节点副本必须是一致的
- 在 zookeeper 集群中数据副本的传递策略就是采用的广播模式Zab 协议中的 leader 等待 follower 的 ack 反馈，只要半数以上的 follower 成功反馈就好， 不需要收到全部的 follower 反馈。
消息广播的具体步骤如下
1、客户端发起一个写操作请求，leader 将请求转化为事务proposal 提案，同时分配一个全局唯一的64位自增ID，即ZXID，通过ZXID的大小比较即可实现有序的特性；
2、leader与follower之间有一个队列，leader将带有ZXID的事务提案（proposal）作为消息发送到队列中；
3、follower从队列中读取消息，将事务提案写入本地事务日志后，向leader发送ACK确认；
4、当leader收到半数以上的follower的ACK后，就向所有follower发送COMMIT命令；
5、follower收到COMMIT命令后，就会执行该消息。
zookeeper 采用 ZAB 协议的核心就是只要有一台服务器提交了 proposal，就要确保所有的服务器最终都能正确提交 proposal。leader 服务器与每个 follower 之间都有一个单独的队列进行收发消息，使用队列消息可以做到异步解耦。leader 和 follower 之间只要往队列中发送了消息即可。
6.3.2 崩溃恢复
zookeeper 集群中为保证任何所有进程能够有序的顺序执行，只能是 leader 服务器接受写请求，即使是 follower 服务器接受到客户端的些请求，也会转发到 leader 服务器进行处理；集群机器的数量必须是奇数。
如果 leader 服务器发生崩溃(重启是一种特殊的崩溃，这时候也没 leader)，则 zab 协议要求zookeeper 集群进行崩溃恢复和 leader 服务器选举。
崩溃恢复要求满足如下 2 个要求：
1、确保已经被 leader 提交的 proposal 必须最终被所有的 follower 服务器提交
2、确保丢弃已经被 leader 发送，但是没有被提交的 proposal。
新选举出来的 leader 不能包含未提交的 proposal，即新选举的 leader 必须都是已经提交了的
proposal 的 follower 服务器节点。同时，新选举的 leader 节点中含有最高的 ZXID。ZXID越大，说明数据越新，这样做的好处就是可以避免了 leader 服务器检查 proposal 的提交和丢弃工作。
1、每个 Server 会发出一个投票,第一次都是投自己。投票信息：（myid，ZXID）
2、收集来自各个服务器的投票
3、处理投票并重新投票，处理逻辑：优先比较 ZXID，然后比较 myid
4、统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定 leader
5、改变服务器状态
LOOKING：寻找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader， 因此需要进入 Leader 选举状态。FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。LEADING：领导者状态。表明当前服务器角色是 Leader。OBSERVING：观察者状态。表明当前服务器角色是 Observer。
