基本概念

几个点：集群角色、会话、数据(子)节点（临时/持久）与版本（v cv av）、Watcher事件注册与通知、ACL权限控制

Ques:什么是zkp？

一个分布式应用协调程序(CP，选举过程中不A)，管理集群，根据节点反馈决定下一步操作。读：可被任意机器处理（会返回zxid），并可在此机器注册Watcher监听。写：请求会发给其余机器达成一致后再写。更新：有个version的东西，更新全局有序并持有一个新的zxid。

zkp的具体工作：命名服务（文件系统的路径获取唯一文件路径得到文件的地址）、配置管理（配置放在znode下，改变时通过watcher通知）、集群管理（机器入退与否并选举master）、分布式锁（临时节点前通知后）、队列管理（监听节点数目/通过持久sequential节点存储队列）

Ques:zkp文件系统？

通过树状结构znode（文件节点）设置关联数据，一个znode上限1M(ZooKeeper was not designed to be a general database or large object store.过大的数据会导致通信过长时间，建议存HDFS、redis等，zkp里存索引)

Ques:znode类型？

persist(_sequential)、ephemeral(_sequential);sequential的节点名后会追加父节点维护的自增型数字

Ques:Watcher机制？

用户在znode上注册watcher，znode变化时client收到通知（长TCP连接，所以能收到）

Ques:zkp的集群管理？

1.是否有机器退出和加入？所有机器在父节点下创建临时目录（sequential），并监听父节点变化消息，有机器挂掉就和zkp连接断开并删此临时目录，于是其余机器都收到了通知（新机器加入同理）

2.选master？选master的时候用目录编号最小的即可

Ques:zkp的分布式锁？

在节点下创建临时顺序节点，然后看自己创建的节点是不是序号最小的，如果是，就获取到了锁，不是，就在index-1的znode上创建watcher，等删了收到通知再判断是不是最小的

Ques:zkp数据复制？

 zkp通过在所有机器间做数据复制，加强了容错、提高系统扩容与负载并使得client可以就近访问节点提高速度。

ZAB协议

参考：https://blog.csdn.net/weixin_34194702/article/details/91378133?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

zxid：前32位递增proposal+后32位epoch

1.消息广播（更新数据到follower）

是一个简化版本的2PC

client发一个写request，leader收到后转成一个proposal（分配一个zxid），提交给对应follower的FIFO队列进行消息发送

follower(收到proposal先写进本地事务日志)看情况会回复ACK（要么ACK，要么直接抛弃proposal），如果ACK过半，发送commit给FIFO队列进行事务提交

缺点：Leader 崩溃数据不一致

2.崩溃恢复（leader崩溃了咋办，Leader 与过半的 Follower 无法正常通信即视为崩溃）

目的：1.快速选举出新leader 2.集群中其余服务器要快速感知到新leader

特性：1.确保所有服务器都提交已经被leader提交的事务 2.丢弃只在leader提出而未被提交的事务

因此这个新leader需要有最大的zxid，因此它一定包括了所有已经提交的提案。而且新选举出来的 Leader 不能包含未提交的 Proposal 。

若 Leader 在 commit 阶段崩溃，根据已完成的事务不能丢失的原则，这些事务应该继续完成。

因为集群中 ZXID 最大的提案是 Leader 崩溃前发出的最新的提案，所以应选择拥有 ZXID 最大的提案的节点做为新的 Leader。

新 Leader 会将自身日志中所有未提交事务重新生成提案并协调集群将其完成, 保证所有被发送的消息(delivered messages)都被处理。

若 Leader 在 proposal 阶段崩溃，根据未执行的事务不能继续的原则，节点应当丢弃这些事务。

当新 Leader 被选举之后会增加 ZXID 的 epoch 值，因此 epoch 值较小的提案可以直接丢弃。

选举阶段：

发起选举的节点会向所有可通信节点发送第一张选票，推举自己作为 Leader。

收到选票的服务器根据下列规则决定自己的投票:

• 若 epoch 大于自身 epoch 说明上一轮投票已结束，更新自身 epoch 值加入新一轮投票，并清除已结束轮次的数据。
• 选择自身已知 拥有最大ZXID 的服务器作为 Leader。即服务器本地保存(vote_sid, vote_zxid)并初始化为自身(sid, zxid), 若收到的选票中 vote_zxid 更大就更新本地数据，并根据最新数据投出选票。
• 若存在 zxid 相同则选择 vote_sid 最大的服务器。

若在某轮投票中某个节点收到过半数的相同选票，那么认为该服务器为新的 Leader 投票结束。

数据同步：

1）完成 Leader 选举后（新的 Leader 具有最高的zxid），在正式开始工作之前（接收事务请求，然后提出新的 Proposal），Leader 服务器会首先确认事务日志中的所有的 Proposal 是否已经被集群中过半的服务器 Commit。

2）Leader 服务器需要确保所有的 Follower 服务器能够接收到每一条事务的 Proposal ，并且能将所有已经提交的事务 Proposal 应用到内存数据中。等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过啦并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中。

Ques:zkp事务一致性？

事务会分配一个zxid，zxid的低32位递增计数。新产生proposal的时候，会依据数据库的两阶段过程，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

Ques:zkp中server工作状态？

looking，following，leading

ZKP watcher

看作是一种观察者模式在分布式场景下的实现方式。

client在服务器端注册watcher，server数据变化主动通知客户端，通过相关对应的回调来处理逻辑。

特点：一次性、顺序回调、轻量级（变化内容不通知）、时效性（重连成功依然可以收到消息）

Zookeeper 基础知识【1】

原文：https://www.cnblogs.com/tillnight1996/p/12915873.html