“这是我参与8月更文挑战的第21天，活动详情查看：8月更文挑战”
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的节点的组成部分：
