zookeeper

前言

极好的文章:https://dbaplus.cn/news-141-1875-1.html

zookeeper 作用

参考:https://blog.51cto.com/u_15127589/4294099

参考:https://zookeeper.apache.org/

1. 配置管理服务
2. 命字服务
3. 分布式协调同步服务
4. 组服务

存储的信息

参考:https://blog.csdn.net/q54244125/article/details/103036063

Column 1	Column 2
cZxid = 0x100000c06	创建的时,前32位(1 ,前面为0的就没有显示)是leader的纪元,就是第几个leader;后32位(00000c06)是事务递增序列
ctime = Mon Aug 29 05:57:15 EDT 2022	创建时间
mZxid = 0x100000c06	与cZxid同理,但是记录的是,此文件加下修改的递增
mtime = Mon Aug 29 05:57:15 EDT 2022	修改时间
pZxid = 0x100000c06	与cZxid同理,但是记录的是,此文件加下最后创建的序列号
ephemeralOwner = 0x0	如果是临时节点,那么值就记录的是创建该节点的sessionid

Paxos

在一个孤岛上选举的故事

ZAB协议-写Leader

1. 客户端向Leader发起写请求
2. Leader将写请求以Proposal的形式发给所有Follower并等待ACK
3. Follower收到Leader的Proposal后返回ACK
4. Leader得到过半数的ACK（Leader对自己默认有一个ACK）后向所有的Follower和Observer发送Commmit
5. Leader将处理结果返回给客户端

这里要注意：

1. Leader并不需要得到Observer的ACK，即Observer无投票权
2. Leader不需要得到所有Follower的ACK，只要收到过半的ACK即可，同时Leader本身对自己有一个ACK。上图中有4个Follower，只需其中两个返回ACK即可，因为(2+1) / (4+1) > 1/2
3. Observer虽然无投票权，但仍须同步Leader的数据从而在处理读请求时可以返回尽可能新的数据

ZAB协议-写Follower/Observer

1. Follower/Observer均可接受写请求，但不能直接处理，而需要将写请求转发给Leader处理
2. 除了多了一步请求转发，其它流程与直接写Leader无任何区别

ZAB协议- 读操作

Leader/Follower/Observer都可直接处理读请求，从本地内存中读取数据并返回给客户端即可

ZAB协议-选举

关键字:

1. 选举会发生在第一次启动集群,和leader故障的时候
2. Server id（或sid对应myid文件中的数字）：服务器ID
3. Zxid：事务ID
4. Epoch：逻辑时钟 也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的，每投完一次票这个数据就会增加。
5. Server状态(选举状态)：
   LOOKING，竞选状态。
   FOLLOWING，随从状态，同步leader状态，参与投票。
   OBSERVING，观察状态,同步leader状态，不参与投票。
   LEADING，领导者状态。

支持的领导选举算法-FastLeaderElection原理

在3.4.10版本中，默认值为3，也即基于TCP的FastLeaderElection。另外三种算法已经被弃用，并且有计划在之后的版本中将它们彻底删除而不再支持

1. myid
2. zxid
3. 服务器状态:
   LOOKING，竞选状态。
   FOLLOWING，随从状态，同步leader状态，参与投票。
   OBSERVING，观察状态,同步leader状态，不参与投票。
   LEADING，领导者状态。
4. 选票数据
5. 结构投票流程

ZooKeeper语义保证

1. 顺序性：客户端发起的更新会按发送顺序被应用到 ZooKeeper 上
2. 原子性：更新操作要么成功要么失败，不会出现中间状态
3. 单一系统镜像：一个客户端无论连接到哪一个服务器都能看到完全一样的系统镜像（即完全一样的树形结构）。注：根据上文《ZooKeeper架构及FastLeaderElection机制》介绍的 ZAB 协议，写操作并不保证更新被所有的 Follower 立即确认，因此通过部分 Follower 读取数据并不能保证读到最新的数据，而部分 Follwer 及 Leader 可读到最新数据。如果一定要保证单一系统镜像，可在读操作前使用 sync 方法。
4. 可靠性：一个更新操作一旦被接受即不会意外丢失，除非被其它更新操作覆盖
5. 最终一致性：写操作最终（而非立即）会对客户端可见

watch

所有对 ZooKeeper 的读操作，都可附带一个 Watch 。一旦相应的数据有变化，该 Watch 即被触发。
Watch 有如下特点：

1. 主动推送：Watch被触发时，由 ZooKeeper 服务器主动将更新推送给客户端，而不需要客户端轮询。
2. 一次性：数据变化时，Watch 只会被触发一次。如果客户端想得到后续更新的通知，必须要在 Watch 被触发后重新注册一个 Watch。
3. 可见性：如果一个客户端在读请求中附带 Watch，Watch 被触发的同时再次读取数据，客户端在得到 Watch 消息之前肯定不可能看到更新后的数据。换句话说，更新通知先于更新结果。
4. 顺序性：如果多个更新触发了多个 Watch ，那 Watch 被触发的顺序与更新顺序一致。

分布式锁

其他

1. 各个注册中心的对比
2. zookeeper的脑裂问题