Zookeeper基础知识

是一种分布式协调服务

服务注册与发现 kess

配置中心 kconf

分布式锁

分布式协同

集群管理

使用场景：

什么是Zookeeper？有什么作用

zk以集群的方式进行运行，其中有一个节点是Leader，其余的节点是fllower，还有一些是observer。其中leader节点主要是单节点的写操作，fllower节点只要是同步数据以及投票，observer节点是为了应对写少读多的场景做的只读节点

1、集群管理                        

data 储存的数据信息

ACL 记录Znode的访问权限

stat 包含Znode的各种元数据 比如事务ID 版本号 时间戳 大小等等

child 当前节点的子节点的引用

ZNode 是一个树形结构 节点分为临时节点和永久节点，其中还有一种顺序节点 所以一共是4种 是否临时*是否有序 Znode底层的数据结构是concurrentHashMap 

数据模型

类似于文件系统    /a/b/c

数据格式

Leader负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower节点（Leader会维持一个Follower列表）。之后Leader需要等待Follower的反馈，一旦超过半数的Follower进行了正确的反馈，Leader则会对所有Follower发起Commit消息，要求所有Follower将该Proposal进行提交（即写入Transaction Log）

数据提交

基于永久节点的特性，可以用户做配置中心 -- kconf

图示

2、数据储存

zk使用基于心跳的会话来维持客户端与服务端之间的联系。每个服务端都有一个sessionId，如果服务端没有在固定的时间内收到客户端的PING，就断开连接。基于这个方式 我们可以用zk来做服务的注册与发现

session的过期时间是协商决定的。服务端保存了一个过期区间，如果客户端设置的过期时间在区间内，就使用客户端的过期时间，如果不在区间，还是以服务端的为准

3、会话管理

Watcher主要是通过Client、Server以及WatcherManager一起配合完成，主要是包括注册&触发两个阶段

注册：客户端通过SendThread线程向服务端发送请求，比如exist或者getData之类的

触发：当节点发生了变更，服务端则会在WatcherManager中挨个遍历watcher，然后把数据发送过去。当客户端的EventThread收到数据之后，则会执行相应的逻辑

销毁：watch是一次性的，如果服务端发送了一次watch，那么客户端则需要重新注册

服务的发现与注册

配置中心

用途

4、事件通知

是指ZK更新数据的操作，要么全部成功 要么全部失败

5、原子性操作

工作原理

ZAB协议是为Zookeeper专门设计的一种支持崩溃恢复的原子广播协议

ZAB协议主要包括两部分：崩溃恢复模型和原子广播协议

常识

当Leader节点出现宕机、网络中断或者其他超过半数的fllower节点无法通信时，这时候fllower接口开始进行leader选举。当超过半数的节点同意，那么就选举出来了新的leader

在选举的时候，是可能出现数据丢失的。在前leader已经提交的数据，新的leader也会同步，在前leader已经提出，但是还没有提交的数据，则会丢弃

数据提交 & leader选举都是过半，所以单数能节约资源

当为双数的时候，可能会出现4比4的情况，称为脑裂，此时无法提供服务，所以也是为了防止脑裂

为什么zk的集群都是单数？

崩溃恢复模型

ZXID 的设计也很有特点，是一个全局有序的 64 位的数字，可以分为两个部分：高 32 位是： epoch（纪元），代表着周期，每当选举产生一个新的 Leader 服务器时就会取出其本地日志中最大事务的 ZXID ，解析出 epoch（纪元）值操作加 1作为新的 epoch ，并将低 32 位置零。低 32 位是： counter（计数器），它是一个简单的单调递增的计数器，针对客户端的每个事务请求都会进行加 1 操作；

请求的每一次提交都是Leader在写，写之前会为Proposal生成一个事务id(ZXID)，并且是单调递增的。

每一个Fllower都有一个专属的队列，所以leader需要把ZXID放到每一个队列去，当fllower消费之后也写事务日志到磁盘上，再向leader返回ask

当leader收到的ask大于一半的时候，就广播一个commit，同时完成对自身事务的提交

原子广播协议

ZAB协议

Zookeeper使用的是客户端负载均衡。当客户端连接到Zookeeper时，Zookeeper会返回一个可用的服务端节点列表。客户端会从列表中选择一个节点进行连接，如果节点无法响应，则会自动切换到下一个可用节点。这样可以将请求分散到不同的节点上，实现负载均衡。另外，Zookeeper还提供了一些监控工具来帮助管理员检测和管理节点的负载情况。

随机策略

轮循策略

最少连接策略 选择当前连接数最少的可用Zookeeper服务器作为客户端请求的目标。

哈希策略  根据客户端请求的内容计算一个哈希值，然后选择拥有该哈希值的Zookeeper服务器作为客户端请求的目标，从而实现请求的负载均衡。

权重策略  针对不同的Zookeeper服务器设置不同的权重值，根据权重值来选择目标服务器，从而实现请求的负载均衡。

负载均衡

实现原理：通过创建临时节点来表示是否获取到了锁

创建临时有序节点(通过watch实现)可以避免羊群效应，也就是多个请求同时抢占

当客户端与zk断连的时候，临时节点自动删除

优势点：

架构图

1、实现了推拉结合 

2、降低了ZK与服务的连接数

设计好处

服务注册与发现架构设计

Zookeeper