早晨好，我是卢卡，最近半个月工夫比拟缓和，一个是快过年了，公司的人员评审和评定文档也比拟多，二也是更新了一下本人之前的技术的简历，自从五月份入职，也满满有七个月的工夫，发现很多技术学的不太扎实，比方经典的 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