zookeeper 使用场景
1.分配式配置中心，如kafka 元数据等等，注册中心
2.分布式协调服务，比如可以通过watch 机制来协调各个节点的行为
3.分布式锁/队列，可以实现分布式的数据结构
zookeeper 实现分布式锁
1.两种方案
zookeeper分布式锁的两种实现-CSDN博客
zookeeper 有哪些类型节点
临时节点（会话，失去就消失）
永久结点
临时序列节点
永久序列结点
zookeeper 是cp,还是ap
通常分布式系统会保证P(分布可用性)，zk作为保证分布式系统里专门保存元数据里的，选了cp,也就是保证数据的一致性，失去了可用性，在一些业务系统里，往往会使用ap,保证可用性，对于数据的一致性，会有一些取失，毕竟数据最终一致就行
如何防止脑裂的
1.首先节点要是奇数
2.选举成leader要得到一半的选票
如果有leader 节点因为网络原因，没有感知到已经有新leader产生后，即使老leader能写，老leader 写请求复制到其它节点时，也会因为epoch,导致写入失败，然后变成follower
数据结构是啥样的
树型结构，类型linux 文件系统
zk的节点，分别有哪些角色
leader 节点
follower 和observer 节点
observer 节点没有投票权
这里想一下为啥没有投票权，主要是因为如果zk cluster 节点多的话，每个写请求都要超过一半的节点写入才能认为是成功，影响效率
zk读写分别是哪些节点
leader 节点负责读写
follower 负责转发写和直接读
observer 负责转发写和直接读
常用的分布式组件失去zookeeper 异常会有哪影响
zk watch 机制
理解Zookeeper的Watch机制 - 掘金
zk 数据一致性的协议
ZAB 协议的基本工作原理：
-
**Leader 选举：**在 ZooKeeper 集群启动时，各个节点会通过选举算法选出一个主节点（Leader）。这个主节点负责处理所有的写操作。
-
**写操作处理：**所有的写操作都必须经过主节点。当一个客户端请求写操作时，它会发送给主节点。主节点接收到写操作后，会生成一个全局唯一的递增的事务 ID，并将这个写操作转化成一个提案（proposal）。
-
**提案广播：**主节点会将这个提案发送给所有的从节点（Followers）。从节点收到提案后，会进行投票，表明它们是否同意这个提案。
-
**过半复制：**一旦主节点收到过半数从节点的确认投票，就意味着这个提案被通过。主节点会将这个提案写入日志，并向所有的从节点发送提交消息。
-
**提交消息：**从节点收到提交消息后，会将主节点的写操作应用到自己的状态机中。这样，所有的节点都达到了相同的状态，数据保持一致。
-
**故障恢复：**如果主节点出现故障，剩余的从节点会再次进行选举，选出新的主节点来接管写操作。
ZAB 协议的关键特性包括原子广播、阻塞式一致性和主从复制。通过这些特性，ZooKeeper 能够保证数据的一致性和顺序性，即使在节点故障或网络分区的情况下也能够保持高可用性。这使得 ZooKeeper 成为许多分布式系统中的重要组件，用于实现诸如配置管理、分布式锁、命名服务等功能。
