Day16_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具有形同的系统状态。

ZAB协议选举模式：刚启动就给其他的节点去发送投票，每个人刚开始都是投票给他自己的，也会收到别人的投票，第一轮选票选不出controller；第二轮投票时，比较节点的id大小，master集群总共部署了20台机器，其中就3台机器作为controller候选节点，3台机器启动就会发起选举的投票，优先会把id更大的节点选举为contorller（id越大，说明这个节点是后来才启动的，它启动时同步过来的数据是很新的，优先选举这个节点作为controller）。新的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