章节内容
上一节我们完成了：
新建Java的Maven工程
使用Java调用ZK 进行操作
创建节点、删除节点、监听节点等操作
背景介绍
这里是三台公网云服务器，每台 2C4G，搭建一个Hadoop的学习环境，供我学习。
之前已经在 VM 虚拟机上搭建过一次，但是没留下笔记，这次趁着前几天薅羊毛的3台机器，赶紧尝试在公网上搭建体验一下。
2C4G 编号 h121
2C4G 编号 h122
2C2G 编号 h123
Leader选举
选举机制
半数机制：集群中半数以上机器存活，集群可用。所以 ZooKeeper 适合奇数台。
ZooKeeper 虽然在配置文件中没有指定Master和Slave，但是ZK在工作的时候，会有一个Leader，其他的都是Follower。
首次启动
假设有五台集群的机器：
服务1启动，此时只有它一台启动了，它发出去的报文没有任何响应，所以一直是LOOKING状态。
服务2启动，它与最开始启动的服务1进行通信，互相交换自己的选举结果。由于两者都没有历史数据，所以ID值较大的服务2胜出。但是目前还没有超过半数的服务同意，所以服务1和服务2都是LOOKING状态。
服务3启动，服务3成了1、2、3的老大，集群中>=2台选了3，所以服务3成了Leader。
服务4启动，服务4应该是1、2、3的老大，但是集群已经选了3为老大，所以4只可以做Follower。
服务5启动，同4。
非首次启动
每次选举的时候都会根据自身的事务ID，优先选择事务ID大的为 Leader。
ZAB 一致性
ZAB 介绍
ZAB 是 Apache ZooKeeper 的一种使用场景和实现模式。
ZK就是分布式一致性问题的工业解决方案，Paxos算法是底层算法。
ZAB，即 ZooKeeper Atomic Broadcast，是 ZooKeeper 背后的一致性算法，确保了分布式系统中的数据一致性和可靠性。
数据一致性
为什么会出现数据一致性问题？
将数据复制到分布式部署的多台机器中，可以消除单点故障，防止由于部分服务器宕机导致服务不可用。
通过负载均衡，能够让分布在不同地区的数据副本全都对外提供服务，提高系统性能。
但是分布式后，会导致数据不一致的情况出现
比如常见于 主从复制的时候：
主备模式
ZK中，所有客户端写入数据都是写入Leader，由Leader复制到Follower中。
广播消息
ZAB协议的消息广播过程类似于二阶段提交。
对于客户端的写请求，全部由 Leader 接收，Leader将请求封装成一个事务 Proposal（提议），将其发送给所有Follower。
如果收到超过半数反馈ACK，则执行Commit操作（先提交自己，再发送Commit给其他Follower）。
发送Proposal到Follower
Leader接收Follower的ACK
超过半数ACK则进行Commit
Leader宕机
Leader如果宕机了，ZK集群将无法正常工作，ZAB协议提供了一个高效可靠的Leader选举算法。
- ZAB协议保证那些已经在Leader提交的事务最终会被所有服务器提交
- ZAB协议保证丢弃那些只在Leader 提交/复制，但没有提交的事务。
