Day16_Zookeeper

本文主要是介绍Day16_Zookeeper，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

Zookeeper
- - zookeeper和dubbo的关系
  - Raft协议选举算法
  - Zookeeper的选举算法是什么？
  - 什么是ZAB协议？
  - 四种类型的数据节点 Znode
  - Zookeeper的持久节点和临时节点有什么区别？
  - zookeeper如何实现分布式锁
  - Zookeeper 下 Server有哪些工作状态？
  - Zookeeper集群中有哪些角色？
  - 你熟悉Zookeeper节点ZNode和相关属性吗？
  - Zookeeper的Observer模式是什么？
  - Zookeeper的Watcher机制是什么？
  - Zookeeper的Watcher机制有什么缺点？
  - Zookeeper的Observer模式和Watcher机制有什么区别
  - 请描述一下 Zookeeper 的通知机制是什么？
  - Zookeeper的ACL（访问控制列表）是什么？
  - Zookeeper的ACL是如何实现的？
  - Zookeeper的事务日志是什么？
  - Zookeeper的会话超时是什么？如何处理会话超时？
  - Zookeeper有哪几种几种部署模式？
  - 集群最少要几台机器，集群规则是怎样的?
  - Zookeeper的java客户端都有哪些？
  - 集群支持动态添加机器吗？
  - Zookeeper负载均衡和Nginx负载均衡区别
  - Zookeeper脑裂是什么原因导致的？
  - Zookeeper 是如何数据同步的？
  - ZooKeeper 集群中个服务器之间是怎样通信的？
  - Zookeeper的使用场景有哪些？
  - 说说Zookeeper的工作原理？
  - 了解Zookeeper的系统架构吗？
  - Zookeeper为什么要这么设计？
  - 在Zookeeper中Zxid 是什么，有什么作用？
  - Zookeeper是如何保证事务的顺序一致性的？
  - ZooKeeper为啥是奇数个节点
  - ZooKeeper 宕机如何处理？
  - 说说ZooKeeper 的序列化
  - 讲解一下 ZooKeeper 的持久化机制
  - 说说 Zookeeper 的 CAP 问题上做的取舍？
  - Eureka和zookeeper都可以提供服务注册与发现的功能，两者的区别

Zookeeper

zookeeper和dubbo的关系

ZooKeeper注册中心：在Dubbo架构中，ZooKeeper作为注册中心，为Dubbo提供了服务注册和发现的功能，而Dubbo则利用这些功能实现了服务间的远程调用和通信。

Dubbo则担任高性能RPC（远程过程调用）框架的一个角色，Dubbo提供了远程过程调用、负载均衡和服务治理等核心能力。

Raft协议选举算法

启动了之后，一般来说，3台机器，每个人都会投票给自己，选举自己当选为leader，他对自己的投票会发给其他的机器。这样投票下来发现选不出来leader的Raft协议，如果一轮投票，发现大家没有选举出来一个leader，此时如何呢？大家都走一个随机时间的等待，timeout时间过后，再次发起第二轮选举。机器01选择休眠等待3秒钟，机器02选择休眠等待1.5秒钟，机器03选择休眠等待4秒钟第二轮选举的时候，机器02先苏醒过来，发现进入了第二轮投票，他发现此时没有人发送选票给他，他就还是选举自己当做leader，发送给了机器01和机器03机器01醒来收到选票结果发现已经有人投票给02了，它也投票给02；机器03醒来发现机器02都两个选票了，它也投票给机器02大家发现选票都投完了，发现超过半数的人（全票）都投给了机器02，此时机器02当选为leader，Raft协议本质就是通过随机休眠时间保证说一定会在某一轮中投票出来一个人当选为leader

Zookeeper的选举算法是什么？

答： Zookeeper使用的选举算法是基于Paxos协议的ZAB协议。在一个Zookeeper集群中，有一个Leader节点和多个Follower节点。Leader节点负责处理客户端的读写请求，Follower节点负责与Leader节点保持数据一致性。如果Leader节点故障，则集群会自动选举一个新的Leader节点。

我们不想要raft的睡眠机制（这种太随机了，我们希望存放数据最新的master作为controller），所以zk采用的是ZAB协议选举leader

ZAB协议选举模式：刚启动就给其他的节点去发送投票，每个人刚开始都是投票给他自己的，也会收到别人的投票，第一轮选票选不出controller；第二轮投票时，比较节点的id大小，master集群总共部署了20台机器，其中就3台机器作为controller候选节点，3台机器启动就会发起选举的投票，优先会把id更大的节点选举为contorller（id越大，说明这个节点是后来才启动的，它启动时同步过来的数据是很新的，优先选举这个节点作为controller）。新的Leader节点会与其他Follower节点进行数据同步，在数据同步完成后，集群就可以开始对外提供服务了。

什么是ZAB协议？

ZAB协议，全称Zookeeper Atomic Broadcast（Zookeeper原子广播协议），是Zookeeper设计的一种支持崩溃恢复和原子广播的协议。集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性；

Zab协议包含两个阶段：Zab协议包含两个阶段：leader election阶段和Atomic Brodcast阶段（选举模式和广播模式）。
a) 集群中将选举出一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过brodcast将所有的更新告诉给follower。
b) 当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。
c) 当leader被选举出来，且大多数服务器完成了和leader的状态同步后，leadder election 的过程就结束了，就将会进入到Atomic brodcast的过程。
d) Atomic Brodcast同步leader和follower之间的信息，保证leader和follower具有形同的系统状态。

四种类型的数据节点 Znode

PERSISTENT-持久节点
解释：除非手动删除，否则节点一直存在于Zookeeper上。
案例：假设你在ZooKeeper中存储了应用的配置文件作为持久节点。即使应用重启或与之关联的客户端会话断开，配置文件仍然保留在ZooKeeper中，供其他客户端或应用实例访问
EPHEMERAL-临时节点
解释：临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。
案例：在服务注册与发现场景中，服务提供者可以将自己的服务信息注册为临时节点。如果服务提供者宕机或断开连接，其对应的临时节点会自动从注册中心删除，从而实现了服务的自动下线。
PERSISTENT_SEQUENTIAL-持久顺序节点
解释：基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
案例：在分布式锁或分布式队列的场景中，可以使用持久顺序节点来确保任务或锁请求的顺序处理。每个请求都会创建一个新的持久顺序节点，并通过节点名的后缀来确定其顺序。
EPHEMERAL_SEQUENTIAL-临时顺序节点
解释：基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
案例：在需要自动排序和自动清理的任务队列中，可以使用临时顺序节点。客户端可以将任务作为临时顺序节点添加到队列中，一旦任务完成或客户端会话结束，相应的节点就会自动删除，从而保持队列的整洁和有序。

import org.apache.zookeeper.CreateMode;  
import org.apache.zookeeper.KeeperException;  
import org.apache.zookeeper.ZooDefs;  
import org.apache.zookeeper.ZooKeeper;  
import org.apache.zookeeper.data.Stat;  public class ZNodeExample {  private static final String CONNECT_STRING = "localhost:2181"; // ZooKeeper 服务器地址  private static final int SESSION_TIMEOUT = 30000; // 会话超时时间，单位毫秒  public static void main