上一篇 <<<Zookeeper如何保证节点一致性问题
下一篇 >>>Zookeeper实现哨兵选举机制
Zk集群是由多个Server节点组成了一个集群，只有一个Leader节点；其他节点类型都是为Follower类型，每个follower节点保存了leader节点的副本数据，leader负责写，其他负责读。
- 1、利用zab的恢复模式，选举leader，优先比较zxid、其次比较myid，达到过半机制将不再选举
- 2、无论follower、Observer还是leader节点接收到请求，统一交由leader实现写操作，leader会创建一个全局zxid（事务ID），zk已经使用锁的机制对我们zxid保证了足够线程安全问题；
- 3、使用2阶段协议，leader带上zxid询问所有的follower和Observer是否可以同步数据
4、达到半数的服务器节点确认同步ack，则leader会向所有的跟随者和观察者commit事务数据，使用的是zab的广播模式
---同步过程中观察者宕机，则下次同步，如果leader宕机，则选取数据最新的zxid作为leader进行新的同步。
为什么我们写的请求必须统一交给leader而不是follower节点实现？
因为可以采用借鉴在分布式事务中2pc（两阶段提交协议）解决分布式数据同步问题。
推荐阅读：
<<<Zookeeper基础知识及应用场景
<<<Zookeeper如何实现分布式锁
<<<CAP理论和Base理论
<<<Zookeeper选举的策略
<<<为什么Zookeeper集群节点一定要是奇数
<<<Zookeeper在后期新增zk节点时如何提高选举效率问题
<<<Zookeeper如何保证节点一致性问题
<<<Zookeeper实现哨兵选举机制
<<<Zookeeper示例之访问权限控制
<<<Zookeeper示例之服务发现与治理
<<<Zookeeper示例之分布式锁
<<<Zookeeper示例之节点事件监听
<<<Zookeeper示例之集群请求
<<<Linux环境安装Zookeeper
<<<Zookeeper配置文件介绍
<<<Zookeeper常见问题
<<<Eureka与Zookeeper有啥区别？
<<<Zookeeper常用命令
