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 一个 ackleader 会发送一个 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 的节点的组成部分：