ZAB协议（Zookeeper Atomic Broadcast）是Zookeeper中用于实现分布式一致性的协议。该协议旨在确保分布式系统中的数据一致性和可靠性，并具有以下特点： 支持崩溃恢复和消息广播：ZAB协议能够在Leader节点崩溃或因其他原因导致Leader缺失时，自动进入崩溃恢复模式，
zookeeper集群中服务器被划分为以下四种状态： LOOKING：寻找Leader状态。处于该状态的服务
Zookeeper集群的数目一般为奇数个，主要是出于以下两方面的考虑： 防止脑裂。如果Zookeeper集群的节点数为偶数个，那么在集群发生脑裂并分成两个均等子集群的情况下，可能导致整个Zookeeper集群都无法正常工作。而如果集群节点数为奇数个，则即使发生脑裂并分成两个子集群，每个子集群都至少会
ZooKeeper可以用于实现分布式锁，主要的思路是利用ZooKeeper的临时顺序节点唯一性和顺序性的特点来实现。具体实现步骤： 1. 创建一个ZooKeeper节点作为锁的根节点，例如 /locks。 2. 当一个线程需要获取锁时，它在锁的根节点下创建一个临时顺序节点，例如 /locks/loc
在 ZooKeeper 中，节点监视（watch）通知不是永久的，而是一次性触发。当客户端注册一个监视事件，例如监视一个节点的数据变化或子节点的变化时，如果相应的节点状态发生了变化，ZooKeeper 会通知客户端，并触发监视事件。一旦监视事件被触发，它会从客户端的监视列表中删除，客户端需要再次显式
Zookeeper脑裂是指一个集群环境中出现了多个Master节点，导致数据不一致和数据问题。这种情况通常发生在网络故障导致集群中部分节点失去与Master节点的连接，而在这些节点看来，Master节点已经失效，因此它们会选举新的Master节点。在这个过程中，可能会出现多个Master节点，导致脑
Zookeeper的持久化机制主要涉及两种数据存储方式：内存存储和磁盘存储。 内存存储：这是Zookeeper默认的数据存储方式。在内存存储中，Zookeeper将所有数据保存在内存中，而不是磁盘上。当Zookeeper关闭或发生故障时，内存中的数据会丢失。为了提高性能，Zookeeper采用了延迟
Zookeeper 的典型应用场景包括： 数据发布与订阅：这是 Zookeeper 的一种典型应用场景。发布者将数据发布到 ZooKeeper 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。 分布式锁：Zookeeper 可以用来实现分布式锁。利用 ZooKeeper 的节点唯一
Zookeeper的解决方案是通过过半机制来避免脑裂问题的发生。 具体来说，在Zookeeper的领导者选举过程中，如果某台ZookeeperServer获得了超过半数的选票，则此ZookeeperServer就可以成为Leader。举个简单的例子，如果现在集群中有5台ZookeeperServer
Zookeeper 在 CAP 问题上选择了 CP，也就是说，在一致性和可用性之间，Zookeeper 选择了强一致性。 Zookeeper 是一个分布式协调服务，它的主要职责是维护整个系统的状态，并提供一致性的服务。因此，为了保证数据的一致性，Zookeeper 必须确保在分布式节点之间进行同步的
