zookeeper原理

zookeeper概述

1. 工作机制

存储和管理关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，zookeeper将通知在zookeeper上注册的观察者做出反应

2. zookeeper特点

1. 一个领导者，多个跟随者组成的集群
2. 集群中只要半数以上节点存活，集群就能正常工作
3. 全局数据一致，每个服务器保存相同的一份数据副本
4. 更新请求顺序进行
5. 数据更新原子性
6. 实时性，在一定的时间范围内，client能读到最新数据

3. zookeeper数据结构

4. 应用场景

统一命名服务：类似于域名和ip映射一样，可以通过名称来获取资源或服务的地址，提供者等信息

统一配置管理：分布式环境下需要配置文件同步。zookeeper中将配置文件写入一个Znode中；每个客户端监听znode；数据被修改时，zookeeper将通知各个客户端服务器

统一集群管理：监控节点将信息写到一个znode上；监听这个znode就能够获取他的实时状态变化

服务器动态上下线：客户端能实时洞察到服务器上下线的变化
1. 服务端启动时，去注册信息（创建的都是临时节点）
2. 客户端获取到当前在线服务器列表，并且注册监听
3. 服务器节点下线
4. 服务器节点上下线事件通知到客户端
5. process（） 重新再去获取服务器列表，并且注册监听

软负载均衡：zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理客户端最新的请求

zookeeper内部原理

1. 选举机制

1）半数机制：集群中半数以上机器存活，集群可用。所以 Zookeeper 适合安装奇数台服务器。

2）选举机制：leader通过选举产生，半数以上投票即可

Leader 选举原理

重要的参数：

• 服务器 ID(myid)：编号越大在选举算法中权重越大
• 事务 ID(zxid)：值越大说明数据越新，权重越大
• 逻辑时钟(epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是相同的，每投完一次值会增加

选举状态：

• LOOKING: 竞选状态
• FOLLOWING: 随从状态，同步 leader 状态，参与投票
• OBSERVING: 观察状态，同步 leader 状态，不参与投票
• LEADING: 领导者状态

1. 服务器启动时选举过程：

• （1）每台 server 发出一个投票，由于是初始情况，server1 和 server2 都将自己作为 leader 服务器进行投票，每次投票包含所推举的服务器myid、zxid、epoch，使用（myid，zxid）表示，此时 server1 投票为（1,0），server2 投票为（2,0），然后将各自投票发送给集群中其他机器。
• （2）接收来自各个服务器的投票。集群中的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自 LOOKING 状态的服务器。
• （3）分别处理投票。针对每一次投票，服务器都需要将其他服务器的投票和自己的投票进行对比，对比规则如下：
  • a. 优先比较 epoch
  • b. 检查 zxid，zxid 比较大的服务器优先作为 leader
  • c. 如果 zxid 相同，那么就比较 myid，myid 较大的服务器作为 leader 服务器
• （4）统计投票。每次投票后，服务器统计投票信息，判断是都有过半机器接收到相同的投票信息。server1、server2 都统计出集群中有两台机器接受了（2,0）的投票信息，此时已经选出了 server2 为 leader 节点。
• （5）改变服务器状态。一旦确定了 leader，每个服务器响应更新自己的状态，如果是 follower，那么就变更为 FOLLOWING，如果是 Leader，变更为 LEADING。此时 server3继续启动，直接加入变更自己为 FOLLOWING。

2. 运行过程中的 leader 选举

​ （1）变更状态。leader 挂后，其他非 Oberver服务器将自身服务器状态变更为 LOOKING。

​ （2）每个 server 发出一个投票。在运行期间，每个服务器上 zxid 可能不同。

​ （3）后续与启动过程相同

2. 监听器原理

1. main线程；创建zookeeper客户端，会创建两个线程，一个负责监听（listener，一个负责网络连接通信(connect)
2. 通过通信线程，将注册的监听事件发送给zookeeper监听器
3. 监听器将注册事件添加到列表中
4. 当zookeeper监听到有数据或路径变化，就会把消息发送给listener线程
5. listener内部调用process方法
6. 

3. 写数据原理

1. 客户端向zookeeper的服务器1发送一个写请求
2. 如果服务器1 不是leader，那么会转发给leader。
3. leader再将写请求广播给要写入的服务器。
4. 写完之后，让服务器1通知客户端写入成功

4. 数据同步流程

在zookeeper中，依赖ZAB协议实现分布式数据一致性。

ZAB分为两部分： 消息广播，崩溃恢复

消息广播

Zookeeper 使用单一的主进程 Leader 来接收和处理客户端所有事务请求，并采用 ZAB 协议的原子广播协议，将事务请求以 Proposal 提议广播到所有 Follower 节点，当集群中有过半的Follower 服务器进行正确的 ACK 反馈，那么Leader就会再次向所有的 Follower 服务器发送commit 消息，将此次提案进行提交。这个过程可以简称为 2pc 事务提交，整个流程可以参考下图，注意 Observer 节点只负责同步 Leader 数据，不参与 2PC 数据同步过程。

崩溃恢复

在正常情况消息广播情况下能运行良好，但是一旦 Leader 服务器出现崩溃，或者由于网络原理导致 Leader 服务器失去了与过半 Follower 的通信，那么就会进入崩溃恢复模式，需要选举出一个新的 Leader 服务器。在这个过程中可能会出现两种数据不一致性的隐患，需要 ZAB 协议的特性进行避免。

• 1、Leader 服务器将消息 commit 发出后，立即崩溃
• 2、Leader 服务器刚提出 proposal 后，立即崩溃

ZAB 协议的恢复模式使用了以下策略：

• 1、选举 zxid 最大的节点作为新的 leader
• 2、新 leader 将事务日志中尚未提交的消息进行处理

5. 分布式锁原理

详见：

https://www.runoob.com/w3cnote/zookeeper-locks.html

排他锁

抢占创建唯一子节点，没抢上的注册子节点变更的监听事件

共享锁（读锁）

根据序号大小来实现

常见问题

为什么集群中机器的数目是奇数个？

因为leader选举才用的是paxos协议。

paxos协议核心思想是：多数server写成功则认为写成功。多数即 n/2 +1

如此看来 三台和四台的容灾能力是一样的，为了节省资源，一般采用奇数个

ZooKeeper实战

1. 下载安装

wget https://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz
tar -zxvf zookeeper-3.4.14.tar.gz
cd zookeeper-3.4.14
cd conf/
cp zoo_sample.cfg zoo.cfg
cd ..
cd bin/
sh zkServer.sh start #启动服务端
sh zkServer.sh status #查看服务端状态
sh zkCli.sh 		#启动客户端

2. 客户端基础命令

ls path # ls 命令用于查看某个路径下目录列表。 path：代表路径
ls2 path#ls2 命令用于查看某个路径下目录列表，它比 ls 命令列出更多的详细信息。
get path [watch] #get 命令用于获取节点数据和状态信息。
stat path [watch] #stat 命令用于查看节点状态信息。
#path：代表路径。 #[watch]：对节点进行事件监听

create [-s] [-e] path data acl#create 命令用于创建节点并赋值。
#[-s] [-e]：-s 和 -e 都是可选的，-s 代表顺序节点， -e 代表临时节点，注意其中 -s 和 -e 可以同时使用的，并且临时节点不能再创建子节点。
#path：指定要创建节点的路径，比如 /runoob。
#data：要在此节点存储的数据。
#path：访问权限相关，默认是 world，相当于全世界都能访问。

set path data [version] #set 命令用于修改节点存储的数据。
delete path [version] #delete 命令用于删除某节点
#path：节点路径。 data：需要存储的数据。 [version]：可选项，版本号(可用作乐观锁)。