晚上好，我是卢卡，最近半个月时间比较紧张，一个是快过年了，公司的人员评审和评定文档也比较多，二也是更新了一下自己之前的技术的简历，自从五月份入职，也满满有七个月的时间，发现很多技术学的不太扎实，比如经典的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