Zookeeper 定义
ZooKeeper是一个开源的分布式协调服务，它为分布式应用提供一致性服务。ZooKeeper通过提供高效且可靠的数据存储、数据同步以及集群管理等功能，帮助开发者构建高可用的分布式系统。在分布式环境中，ZooKeeper常用于解决分布式数据一致性、分布式锁、命名服务、配置管理等问题。
Zookeeper 工作机制
从设计模式的角度来看，ZooKeeper基于观察者模式设计。它维护一个共享的、树状的数据结构，并允许客户端注册为某个数据节点的观察者。当这些数据节点的状态发生变化时，ZooKeeper会通知所有注册的观察者，使得它们能够做出相应的反应。这种机制使得ZooKeeper在分布式系统中能够高效地协调不同节点之间的通信和协作。
Zookeeper 特点
- 集群架构：ZooKeeper集群由一个领导者（Leader）和多个跟随者（Follower）组成。这种架构确保了系统的高可用性和容错性。
- 高可用性：只要ZooKeeper集群中有一半以上的节点存活，集群就能正常提供服务。因此，为了最大化系统的可用性，通常建议安装奇数台服务器来构建ZooKeeper集群。
- 全局数据一致：ZooKeeper集群中的每个节点都保存一份相同的数据副本，确保了数据的全局一致性。
- 顺序一致性：ZooKeeper保证来自同一个客户端的更新请求会按照其发送顺序依次执行。
- 数据更新原子性：ZooKeeper保证每次数据更新操作要么成功，要么失败，不会出现部分更新的情况。
- 实时性：ZooKeeper能够在一定时间内保证客户端能够读取到最新的数据。
Zookeeper 数据结构
ZooKeeper的数据模型类似于Linux文件系统，整体上可以看作是一棵树，每个节点称为ZNode。每个ZNode默认能够存储1MB的数据，并通过其路径唯一标识。ZNode可以分为持久节点和临时节点两种类型，分别用于存储持久数据和临时数据。
Zookeeper 选举机制
第一次启动选举机制：
- 当第一台服务器启动时，它会发起一次选举并投自己一票。由于票数不足半数，选举无法完成，服务器状态保持为LOOKING。
- 当第二台服务器启动时，它会再次发起选举并与第一台服务器交换选票信息。根据选票规则（如服务器ID较大的获胜），第二台服务器可能会成为领导者或继续保持LOOKING状态。
- 当第三台服务器启动时，它会继续发起选举并与前两台服务器交换选票信息。最终，根据选票规则，一台服务器会成为领导者，其他服务器成为跟随者。
非第一次启动选举机制：
- 当ZooKeeper集群中的一台服务器出现初始化启动或无法与领导者保持连接时，它会开始进入Leader选举流程。
- 如果集群中已经存在一个领导者，则新加入的服务器会尝试与领导者建立连接并进行状态同步。
- 如果集群中不存在领导者，则所有参与选举的服务器会根据EPOCH（每个领导者任期的代号）、ZXID（事务ID）和服务器ID等规则进行投票选举。最终，一台服务器会成为新的领导者。
选举Leader规则：
- EPOCH大的直接胜出：EPOCH表示每个领导者任期的代号，EPOCH值较大的服务器具有更高的优先级。
- EPOCH相同，事务ID大的胜出：如果EPOCH相同，则比较事务ID（ZXID），事务ID较大的服务器具有更高的优先级。
- 事务ID相同，服务器ID大的胜出：如果事务ID也相同，则比较服务器ID（SID），服务器ID较大的服务器具有更高的优先级。
SID：服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID：事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑速度有关。
Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加