zookeeper基础知识

微服务注册中心

分布式锁

配置管理

集群管理

持久节点（PERSISTENT）

持久顺序节点（PERSISTENT_SEQUENTIAL）

临时节点（EPHEMERAL）

临时顺序节点（EPHEMERAL_SEQUENTIAL）

存储数据、访问权限、子节点引用、节点状态信息

「data:」 znode存储的业务数据信息
「acl:」 记录客户端对znode节点的访问权限，如IP等。
「child:」 当前节点的子节点引用
「stat:」 包含Znode节点的状态信息，比如「事务id、版本号、时间戳」等等。

为了保证高吞吐和低延迟，以及数据的一致性，znode只适合存储非常小的数据，不能超过1M，最好都小于1K

Zookeeper 允许客户端向服务端的某个Znode注册一个Watcher监听

客户端首先将Watcher注册到服务端，
同时将Watcher对象保存到客户端的Watch管理器中。
当ZooKeeper服务端监听的数据状态发生变化时，服务端会主动通知客户端，接着客户端的Watch管理器会触发相关Watcher来回调相应处理逻辑，从而完成整体的数据发布/订阅流程

当服务端的一些指定事件触发了这个Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能

客户端根据 Watcher通知状态和事件类型做出业务上的改变

可以把Watcher理解成客户端注册在某个Znode上的触发器，
当这个Znode节点发生变化时（增删改查），就会触发Znode对应的注册事件，注册的客户端就会收到异步通知，然后做出业务的改变

工作原理

Watcher特性总结

public byte[] getData(final String path, Watcher watcher, Stat stat);
public List<String> getChildren(final String path, Watcher watcher);
public Stat exists(final String path, Watcher watcher);

List<String> children = zooKeeper.getChildren(nodePath, new Watcher() {
@Override
public void process(WatchedEvent event) {
// 获取数据, 并继续监控. this 表示将监控器本身作为监控器继续监控
try {
      List<String> childs = zooKeeper.getChildren(nodePath, this);
      System.out.println("自定义节点监控-根节点/下的子节点: " + childs + ", event-type:" + event.getType());
} catch (KeeperException e) {
      e.printStackTrace();
} catch (InterruptedException e) {
      e.printStackTrace();
}

}
});

「顺序一致性」：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去

「原子性」：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，
要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用

「单一视图」：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的

「可靠性：」 一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来

「实时性（最终一致性）」

主从节点一致性问题

分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播 协议 ，是Zookeeper保证数据一致性的核心算法,保证主从节点一致性问题

在Zookeeper中主要依赖Zab协议来实现数据一致性，基于该协议，zk实现了一种主备模型（即Leader和Follower模型）的系统架构来保证集群中各个副本之间数据的一致性

Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点，
如果是读请求，就直接从当前节点中读取数据；
如果是写请求，那么节点就会转发给 Leader 来提交事务，
Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交

Zab 协议的特性

Zab 协议实现的 作用

Zab协议原理

Zab协议核心

协议过程

Leader服务器

Follower

Observer

工作状态

假设现在ZooKeeper集群有五台服务器，它们myid分别是服务器1、2、3、4、5

服务器1（myid=1）启动，当前只有一台服务器，无法完成Leader选举

服务器2（myid=2）启动，此时两台服务器能够相互通讯，开始进入Leader选举阶段

1. 每个服务器发出一个投票

2. 接受来自各个服务器的投票

3. 处理投票

4. 统计投票

使用临时顺序节点特性实现分布式锁

获取锁过程 （创建临时节点，检查序号最小）

释放锁 （删除临时节点，监听通知）

假死：由于心跳超时（网络原因导致的）认为leader死了，但其实leader还存活着。
脑裂：由于假死会发起新的leader选举，选举出一个新的leader，但旧的leader网络又通了，导致出现了两个leader ，有的客户端连接到老的leader，而有的客户端则连接到新的leader。

Zookeeper集群中是不会轻易出现脑裂问题的，原因在于过半机制

过半机制

脑裂产生原因

如何解决"脑裂"问题

避免zookeeper"脑裂"