分布式管理员zookeeper，你需要好好了解一下

晚上好，我是卢卡，最近半个月时间比较紧张，一个是快过年了，公司的人员评审和评定文档也比较多，二也是更新了一下自己之前的技术的简历，自从五月份入职，也满满有七个月的时间，发现很多技术学的不太扎实，比如经典的zookeeper，Apache zookeeper开源的分布式协调通知，对于电商系统，高并发，以及微服务的系统服务适用信息都比较高。重新再学习了一下，总结下自己的知识点，对知识点提炼和自己的理解很有帮助，技术人生从重学技术点开始。

zookeeper的定位

Zookeeper 是apache Zookeeper开源的项目,

Zookeeper的主要作用

对于微服务分布式的协调管理,元数据的管理,Master选举, 实际使用场景下,主要是三类项目

1.zookeeper的适用方向

① 后端以Java为主的电商类管理系统

Zookeeper主要作用于 分布式锁,注册中心 ,这里Zookeeper主要保持CAP理论中的CP(一致性和分区容错性),也就是说Zookeeper保证的是强一致性

②对于大数据存储,数据管理,主从数据切换等系统

这里我们熟知的Kafla,canal 等在使用Zookeeper的元数据管理 ,通过master选举出具体的主从,ZAB原子一致性协议,

③大型互联网公司,自研的分布式组件

一般以zookeeper为原型, zookeeper已经被大规模的工业级适用于主要的分布式系统,做元数据管理,以及注册中心,一般使用于 dubbo+Zookeeper 做一个基本的微服务架构来实现基本的数据调用

小总结:

zookeeper 分布式协调系统, 封装了分布式架构中所有的核心和主流的需求和功能;

分布式锁, 元数据管理, master选举, 分布式协调和通知

zookeeper的基本特性：

​

​ 在了解zookeeper的基本架构之前，我们来了解一下，zookeeper为什么可以实现分布式系统的协调通知， 元数据管理等；

​ 熟悉zookeeper技术栈的都比较了解，它本身是处于通知协调机制，数据同步方面有很强的处理能力，这也就是为什么很多自研的框架，底层都用zookeeper的原因，好了，废话不多说，我们开干；

背景：

集群环境下，zookeeper集群搭建了3台物理机器；

1.顺序一致性

 多个请求，不管是读取数据的，还是说写入数据的，都要按照顺序执行；
 zookeeper内部要处理的请求，leader角色会给每一个请求分配一个全局唯一且自增的ZxID，用于请求数据
 
 //这个唯一的全局ID就保证了顺序一致性
这里的zxid，先简单了解，作为一个请求的排列序号，后面会重点讲解的

2.原子性

要么全部机器都成功，要么全部机器都不成功，在同步数据操作时
  //保证每次同步操作结果都是一致的

3.高可用性

集群化部署，避免宕机，

如果宕机，也可自己选举leader，重新提供服务
  //从恢复模式到消息广播模式

4.数据一致性：

 集群情况下，每台机器上的数据都是一致的，但是如果说，在数据同步的时候，宕机了，
 其他机器会自动将数据保存到磁盘日志中，等到leader角色提交之后，才会同步到znode节点中，真正实现数据在每台机器都是一致的
 
 //这里说的数据一致性，是强一致性，也是zookeeper的核心的特性，根据分布式系统保持的CAP理论，只能支持CP,
 //其中C-consistency ，一致性对于，数据的强一致性，p-为系统的分区容错性  A-高可用性，其eureka就是支持AP特性

5.高性能性

高性能，这里提出一个zookeeper的数据模型，znode节点
//znode节点，基于纯内存的，速度很快，树形结构，类似于Linux的文件系统，每个节点都有数据
  
  存储的数据，已经可以处理的能力也就比较强，后面会仔细讲的，接着看下去吧

​

小总结：

基于zookeeper的集群架构的特点图：

zookeeper的集群化：

背景：

和上述的场景一致，都是3台机器，自动化部署的zookeeper集群，现在我们来具体拆分下每个机器的主要功能

Zookeeper的同步数据，是经过主leader提交commit然后同步到各个follow角色 ：2PC提交事务--留个念想，后面细聊

1.Zookeeper集群化角色划分：

• Leader（领导）

  集群启动后，根据半数选举成功的机器，成为Leader角色，支持读写，主要用于写操作，

• Follower（候选人）

  剩余的选举不成功，为follower角色，支持读取数据和同步数据，（leader宕机，提供不了写数据操作时，其他Follower中选举出新的L earner来实现写数据的操作）

• Observer

只是支持读取数据，不参与leader的竞争

这里面角色都是自身理解，也可以说成模式等等；

当每个角色确定功能之后，我们可以将数据直接开始同步，提供服务；

1.1注意事项：

​ 当一个写操作的请求直接访问follower角色的zookeeper的进程时，follower角色处理不了写操作，因为自身没有权限，只有Leader角色处理写操作的请求，这样的话，follower角色就会转发请求到Leader角色处理此请求，处理之后，开始数据同步，然后返回到其他follower角色，完成数据同步，阿虎；

2.Zookeeper集群与客户端访问的过程：

背景：

​ Zookeeper集群化，处理请求，可能来源于消息队列，或者是单独的发生请求读取数据，等等；那么每个请求到底是怎么连接到Zookeeper集群建立连接的呢，这节我们来具体聊聊？

当Zookeeper的集群环境下启动成功，然后我们开始分配角色，然后我们集群于客户端开始建立TCP的长连接，

当建立连接后，就会产生一个服务端的session ，形成一个会话的机制，相应的也会有sessionTimeout的存在

如果当前环境下，突然连接中断了，在sessionTimeout时间内连接成功不会影响此次长连接的使用；

3.Zookeeper集群化的数据一致性是怎么保证的？

背景：

​ 上述说到Zookeeper支持CAP理论中的CP ,主要是consistency，一致性； 他保证数据强一致性，就很有自己的架构特点，我们来一步步揭开Zookeeper怎么保证强一致性的面纱？

Zookeeper的强一致性是通过: ZAB(Zookeeper Atomic Broadcast) 协议： 原子广播协议

这个协议是Zookeeper的数据操作的核心，也用于元数据管理的关键；

协议来进行Zookeeper集群之间的数据同步，保证数据的强一致性；

ZAB： zookeeper Atomic broadcast 协议的思想：

划分角色： leader和follower

发送一个Proposal（提议），leader给所有的follower都同步一个proposal（提议）
如果半数以上的follower，都收到事务的proposal提议，每个follower都会返回一个ack

每个提议Pproposal ->先不会写入follower中znode数据中，而是会往一个自己本地磁盘日志文件中写入，然后返回给leader一个
ack
leader会发送一个commit提交事务

半数提交：2PC
也就是两个阶段提交；
leader如果异常宕机，会从follower中重新选举；

4.Zookeeper集群化数据同步的过程：

划分的比较细，坚持看完一定会有收获的⛽️

1⃣️当集群启动的时候，选举算法开始进行在机器中分配leader和follower角色，通过半数选举机制成功选到leader角色的机器

2⃣️剩下的当然就是follower角色的机器了，然后可以向外提供服务了

3⃣️当一个（写操作）请求经过Zookeeper集群后，leader角色机器会优先分配一个zxid用于创建节点或者变更节点的全局唯一自增ID，然后将发起一个提议Proposal（只是一个提议，相当于告诉其他人来活了，准备一下），将提议都放入，之前给每个follow角色准备好的队列中，（这里到可以保证顺序一致性）。

4⃣️每个follower角色的机器，拿到提议proposal,然后将数据放入自身的磁盘日志文件中，（不会放入znode节点），然后给leader节点回复一个ACK(确定连接成功，返回的确定字符)

ACK (Acknowledge character）即是确认字符:
     
//在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。
    
在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。

5⃣️当leader角色的机器，拿到半数以上的follower角色机器返回的ACK之后,代表已经准备成功，leader角色会推送一个commit消息，

其他follower就会将数据从磁盘文件写入，自身进行znode节点中存储起来，提交之后，数据同步完成，也就可以读取数据了

因为这个过程，分了两阶段提交，又称为2PC事务，用于解决分布式事务的方法

5.Znode的数据模型：

1.zookeeper的数据模型是，

基于纯内存的树形结构: Znode

 znode分类：

​        持久节点：客户端与zk断开连接，节点依旧存在
​        临时节点：客户端与zk断开连接，节点消失
​        顺序节点： 对于创建节点的时候，自增加全局递增的序号；

zk中有一个基于分布式锁的要求环境，curator框架，我们开展临时节点来实现的，加锁的时候创建一个顺序节点

2.zk节点的用途

zookeeperk做元数据管理的时候： 肯定是持久节点
但是一般做分布式锁，分布式协调和通知，都是临时节点，如果断开，临时节点消失，

3 .znode的节点的组成部分：

6.zookeeper启动集群到数据同步过程

leader选举

集群启动，开始进行leader选举，半数机器认可当前机器作为leader，各个follower开始进行数据同步，完成就可以退出恢复模式，然后可以的对外提供服务了

宕机重新选举leader

3台机器，允许不超过一半的机器宕机

2台机器， 两个机器都同意某台机器作为leader ，这个就可以选举出leader;

1台机器是没法自己选举自己的；
因为1台机器，小于半数，所有不能启动集群环境了；

数据同步

leader选举出来后，其他机器都是follower--开始数据同步

强制剩下的follower 数据与自己leader一致；

数据同步完成之后，就会进去， 消息广播模式；

消息写入： leader写入，采用2PC模式过半写机制，给follower进行同步

将自己数据更新到，znode数据节点中

宕机修复

leader宕机，或者follower宕机，只要存活的机器超过一半，那就可以重新选举leader
选举leader，要求有一半以上的支持 ，其他跟follower数据同步，消息广播模式

zk从恢复模式到消息广播模式开始同步数据

7.谈谈在zookeeper集群下数据一致性的理解？

​ 在数据同步的过程中，leader 将提议proposal放入队列（先进先出），然后开始同步到follower，当过半的follower返回ACK(确认字符)之后，leader直接推送一个commit用于提交，follower同步数据；（这里我们注意，不是全部的follower返回结果）

zk的数据同步不是强一致性，

当follower将磁盘日志文件中的数据，提交到znode之后，数据才可以被读取到，最终数据会一致的，但是

zk官方给的一个回复是，顺序一致性，会根据zxid，以及提议proposal的顺序保证

因为leader一定会保证所有的proposal同步到follower上，是按照顺序，最终实现顺序一致性

zk也可以支持强一致行，但是需要手动调节zk的sync()操作

8.ZAB协议下，数据不一致的情况有哪些？

情况1：

当leader推送一个commit提交数据，刚自己提交了，但是他还没有吧commit提交给follower的时候，就已经挂掉了？

简介： 当客户端发送一个写操作的请求，leader已经收到半数以上follower发来的ack，他自己本地已经将数据写入znode中，leader自己commit成功，但是在没有给别的follower发出commit之前就已经挂了， 客户端在收到，leader已经commit数据之后，就默认已经将数据更新完成，但是我们新请求，查询数据follower机器的时候，发现没有，与之间leader返回的不一样；（导致了数据不一致）

这时，follower中的数据和刚刚宕机的leader机器上的数据肯定是不一致的，接下来zk会怎么做呢？

在具体的时间中，zk集群中的follower角色发现，老大leader无法回复，处于失联，宕机状态，他们就说我们再选一个leader，然后就再重新选一个leader01（新的），那之前已经挂掉的leader，就顺势变成了follower，

情况2：

如果客户端在，请求写数据操作的leader机器上，然后leader，发送一个proposal提议，但是还没发出去，就挂了；

导致本地磁盘日志文件中存在一个proposal；但是其他的follower中没有这个数据；

当集群奔溃之后，开展恢复模式，ZAB协议的关键核心就显示出来了，根据

情况1的解决思路：

众多的follower,开始半数选举机制，选出新的leader之后，发现本地磁盘上有没有提交的proposal，然后查看别的follower也存在这样 的情况，这里的新leader(是之前未接收到commit消息的follower),然后我们开始发送commit 给其他follower，将数据写入znode节点中 解决客户端读取数据不一致的情况；

情况2的解决过程：

根据上述的情况，已经宕机的leader存在一个proposal的提议，但是其他的follow没有收到，所以在恢复模式之后，新的leader被选择出来，开展写操作，但是发优先去查询一下本地磁盘中是否有之前遗留的proposal提议，查询到一个follower(之前宕机的发送的一个proposal的leader)磁盘数据与其他的不一致，然后现在的新leader将会同步数据给其他的follower，之前宕机的leader存在一个的提议（proposal提议）会被舍弃掉；

9.奔溃恢复时选举出来的新leader如何跟其他follower进行同步数据的过程

我们还是来模拟一个场景，5台机器的zookeeper集群化部署

其中四台是follower角色用于读取数据和同步数据的，剩下的一台就是leader专门进行写操作的机器

背景：

​ 当一个leader发出一个proposal提议后，其他三台的follower机器都收到了，唯独剩下的一个没收到proposal，但是现在已经有三台j follower机器已经返回了ack的确认字符， 所以leader判断已经都通知成功，（半数选举），然后自身开始commit，没等到给剩下的follower 角色进行提交就宕机了；

​

分析一下：

​ 目前leader已经commit数据到自己的znode节点上了，但是已经挂了，但是其他四台follow机器，三台已经将proposal放到自己本地的磁盘日志文件中，剩余一台啥都没有（之前半数返回ack已经够了没有收到proposal提议），万一其他三台机器恢复机制时，都选举最后一台机器，作为新的leader,那这条数据就永久丢失了，

先告诉大家一个答案，就是这中事情不会发生，zookeeper集群不会选择一个没有数据的角色选举成leader

主要是要了解一个zxid的概念：

Zxid： 可以理解为一个事物的自增ID，要是对提议改变了，他就自增，

要是这个follow没有收到提议，也就zxid相应的比收到返回ack的follower 节点的机器肯定是大的；

选举leader的要求是，在follower中，收到事务zxid最大的，也就是相当于创建时间最早的，作为新的leader

10.zxid

• znode节点的状态信息中包含czxid, 那么什么是zxid呢?
• ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.
• 创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.

​ ZooKeeper中ZXID是一个长度64位的数字，其中低32位是按照数字递增，即每次客户端发起一个proposal，低32位的数字简单加1。高32位是leader周期的epoch编号。也就是leader的一个版本号

比如说后面epoch编号为8， 也就说当前的leader版本是8 ，挂掉之后重新选举就自增1，epoch的编号就是9

所以睡要是想之前的情况2，发生就知道是为什么会出来丢掉的数据，因为会找leader的epocn最大的一个版本作为可以提交的领导者

重新发号命令；

11.Observer节点（角色）的作用：

需要配置文件，只会单纯的接受和同步数据，observer不会参与过半写机制，不参与选举

只是被动的接受数据，

如果读的请求需求很大，我们可以添加几个Observer,

优点：

• ​ 可一扛下很大的并发量，
• ​ 不会影响过半写的机制，
• ​ 不会特别影响性能

原因：

要是都是follower节点的话，当leader要发proposal提议，要等待过半的机器返回ack，然后同步数据，也是过半的，

选举的时候也是过半的，这样会很耗费时间以及网络资源，但是只要读取的数据，不参与选举的observer就很大程度上解决了这个痛点

12.zookeeper适用于实际部署场景：

​ 适用于小集群的部署，读多写少的场景；

奇数台机器，半数选举，

过半写+磁盘日志文件====》commit+znode 节点

主要是写入压力过大leader