zookeeper原理
角色划分
客户端（client）
服务端（server）：领导者（leader，可读可写可监听）+追随者（follower，可读可监听）+观察者（observer，不参与选举投票和提议投票，可读可监听）
zookeeper server状态
- LOOKING：正在选举leader
- LEADING：当前节点就是leader
- FOLLOWING：当前节点是follower
- OBSERVING：当前节点是observer
leader发送给follower消息类型
- PING：心跳消息
- PROPOSAL：发起提议消息
- COMMIT：提交提议消息
follower发送给leader消息类型
- PING：心跳消息
- REQUEST：请求消息（转发写请求）
- ACK：确认提议消息
znode
znode大小限制：1MB
znode删除限制：如果znode有子节点，则无法删除它
znode类型
- PERSISTENT：持久化目录节点
- PERSISTENT_SEQUENTIAL：持久化顺序目录节点
- EPHEMERAL：临时目录节点
- EPHEMERAL_SEQUENTIAL：临时顺序目录节点
zab协议
zab协议包含恢复模式和广播模式。
集群启动、leader崩溃、leader重启或leader失去多数follower时进入恢复模式，恢复模式完成后进入广播模式。
恢复模式
恢复模式包含集群选举和数据同步两个过程。
集群选举时每个节点会将自己的sid和zxid发送给其他节点，并接收其他节点发送的sid和zxid。
规则：先比较zxid，大的胜出；zxid相同，再比较sid，大的胜出。
集群启动时
场景：server A(sid01,zxid00) B(sid02,zxid00) C(sid03,zxid00)
- server A启动完成，发现其他节点都未启动，只能等着
- server B启动完成，与server A开始选举
- server A投自己(sid01,zxid00)，server B也投自己(sid02,zxid00)
- 由于zxid相同，server B sid大于server A sid，因此server A改投server B
- 此时server B支持数过半，成为leader，等待follower连接；server A成为follower
- server C启动完成，也投自己(sid03,zxid00)
- server C被告知已经有leader，因此拿leader信息，并与leader建立连接，server C成为follower
- follower连接后发送各自的zxid给leader
- leader选zxid最大的节点成为同步点开始同步状态
- leader同步状态后发送UPTODATE状态给所有follower
- follower开始同步状态
- 超过半数follower同步状态完成，进入广播模式
leader崩溃或重启时
leader崩溃或重启时选举情况基本同上，zxid越大当选几率越大；zxid相同，sid越大当选几率越大。
leader失去多数follower时
任何节点支持率都不会超过半数，因此集群停止对外提供服务，需要人工干预。
广播模式
client向leader发送读请求
leader直接返回结果给client
client向follower/observer发送读请求
follower/observer直接返回结果给client
client向leader发送写请求
- client发送请求给follower
- leader接收请求，发送PROPOSAL消息给所有follower
- follower接收PROPOSAL，发送ACK消息给leader
- leader接收ACK并计数，超过集群半数（不包含observer），视为通过
- leader执行写操作，写操作成功后发送COMMIT消息给follower
- follower接收COMMIT，执行写操作后返回结果给client
client向follower/observer发送写请求
- client发送请求给follower
- follower接收请求，发送REQUEST消息给leader（其实就多了这步）
- leader接收REQUEST，发送PROPOSAL消息给所有follower
- follower接收PROPOSAL，发送ACK消息给leader
- leader接收ACK并计数，超过集群半数（不包含observer），视为通过
- leader执行写操作，写操作成功后发送COMMIT消息给follower
- follower接收COMMIT，执行写操作后返回结果给client
Paxos协议 & zab协议
Paxos协议与zab协议相同点
集群中由一个leader负责协调工作
leader在执行写操作之前需要得到半数以上follower的认可
提议中包含一个唯一编号
Paxos协议与zab协议不同点
Paxos协议为状态机复制系统设计；zab协议为主备系统设计（zookeeper）
Paxos协议规定原leader宕机，新leader可以将未提交的请求处理顺序随意重排
zab协议规定原leader宕机，新leader必须按照原定的唯一编号顺序处理请求
事务
zookeeper client发送的请求分为事务请求（写请求）和非事务请求（读请求、watcher请求）
每个事务请求都由leader调度处理，所有提议都会加上唯一编号zxid作为事务ID，超过半数follower能够执行，leader才会执行。
zxid：高32位epoch，记录leader周期；低32位递增计数，记录事务ID。
watcher机制
watcher机制分为三个步骤
- 客户端注册watcher
- 服务端处理watcher
- 客户端回调watcher
watcher机制特性
- 一次性：服务端watcher处理前会删除；客户端watcher回调后会删除
- 服务端向客户端发送通知事件是异步的，客户端回调watcher过程是同步的
- 轻量级：服务端只告诉客户端发生了什么事件
- 在哪个节点注册watcher，就由哪个节点处理watcher
名词解释
ServerCnxn：实现了process接口，可以理解成一个watcher对象
WatchTable：键值对，key：数据节点路径，value：ServerCnxn对象
WatchedEvent：通知状态+事件类型+节点路径
客户端注册watcher
- 客户端发送请求：客户端调用getData()/getChildren()/exist()方法，传入watcher对象
- 服务端接收请求：服务端判断是否需要注册watcher，需要的话将节点路径和ServerCnxn，以键值对方式注册到ZKWatcherManager.WatchTable
- 服务端返回注册成功
服务端处理watcher
- 服务端执行写操作后
- 服务端封装WatchedEvent
- 根据节点路径去ZKWatcherManager.WatchTable查找
- 没有，不处理；有，取出并删除
- 调用ServerCnxn.process方法发送事件通知客户端
客户端回调watcher
- SendThread接收事件通知，交给EventThread线程回调watcher
- 触发后删除该watcher
watcher丢失的情况
客户端注册watcher
服务端接收到请求，注册watcher并返回成功
因网络抖动客户端没有收到成功
服务端监听znode发生变化，发送事件通知给客户端，此时客户端是收不到的
watcher丢失的情况二
客户端在server A注册watcher成功
因网络抖动客户端与server A断开连接
此时watcher的节点路径文件发生变化，客户端是收不到事件通知的
客户端与server B建立连接，并要重新注册watcher
来源：CSDN
作者：TonnyBryant
链接：https://blog.csdn.net/qq_37956177/article/details/104077025