Zookeeper 的 ZAB 协议以及 zookeeper 与 nacos 注册中心比对

本文为博主原创，未经允许不得转载：

　　1. ZAB 协议

　　2. zookeer 节点状态

　　3. zookeeper 注册中心与 nacos 注册中心比较

　　4. zookeeper 配置注册中心

1. ZAB 协议

　　　　ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议，实现分布式数据一致性

　　　　所有客户端的请求都是写入到 Leader 进程中，然后，由 Leader 同步到其他节点，称为 Follower。在集群数据同步的过程中，如果出现 Follower 节点崩溃

　　或者 Leader 进程崩溃时，都会通过 Zab 协议来保证数据一致性。

　　ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。

　　　　消息广播：

　　　　　　集群中所有的事务请求都由 Leader 节点来处理，其他服务器为 Follower，Leader 将客户端的事务请求转换为事务 Proposal，并且将 Proposal 分发

　　　　给集群中其他所有的 Follower 。完成广播之后，Leader 等待 Follwer 反馈，当有过半数的 Follower 反馈信息后，Leader 将再次向集群内 Follower 广播 Commit 信息，　　　　　　 Commit 信息就是确认将之前的Proposal 提交。

　　　　　　Leader 节点的写入是一个两步操作，第一步是广播事务操作，第二步是广播提交操作，其中过半数指的是反馈的节点数 >=N/2+1，N 是全部的 Follower 节点数量。

　　　　崩溃恢复：

　　　　　　初始化集群，刚刚启动的时候Leader 崩溃，因为故障宕机Leader 失去了半数的机器支持，与集群中超过一半的节点断连，此时开启新一轮 Leader 选举，

　　　　选举产生的 Leader 会与过半的 Follower 进行同步，使数据一致，当与过半的机器同步完成后，就退出恢复模式，然后进入消息广播模式，整个 ZooKeeper

　　　　集群的一致性保证就是在上面两个状态之前切换，当 Leader 服务正常时，就是正常的消息广播模式；当 Leader 不可用时，则进入崩溃恢复模式，崩溃恢复

　　　　阶段会进行数据同步，完成以后，重新进入消息广播阶段。

2.zab节点的三种状态

　　　　following：服从leader的命令

　　　　leading：负责协调事务

　　　　election/looking：选举状态

3.zk 和 nacos 的区别

　　　　zk：CP设计(强一致性)，目标是一个分布式的协调系统，用于进行资源的统一管理。

　　　　　　当节点crash后，需要进行leader的选举，在这个期间内，zk服务是不可用的。

　　　　nacos：AP设计（高可用），目标是一个服务注册发现系统，专门用于微服务的服务发现注册。

　　　　　　nacos 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 nacos 的客户端在向某个

　　　　nacos 注册时如果发现连接失败，会自动切换至其他节点，只要有一台 nacos 还在，就能保证注册服务可用（保证可用性），只不过查到的信息可

　　　　能不是最新的（不保证强一致性）

4. zk 配置注册中心

　　　　1。引入 zookeeper 服务注册发现的启动类：

　　　　 <dependency>

            <groupId>org.springframework.cloud</groupId>

            <artifactId>spring-cloud-starter-zookeeper-discovery</artifactId>

        </dependency>

　　　　2。 spring boot 项目在配置文件中指定注册地址：

#zookeeper 连接地址

spring.cloud.zookeeper.connect-string=localhost:2181

#将本服务注册到zookeeper

spring.cloud.zookeeper.discovery.register=true

spring.cloud.zookeeper.session-timeout=30000