1. ZooKeeper 集群
- 可靠的 ZooKeeper 服务。
- 只要集群的大多数都准备好了，就可以使用这项服务。
- 容错集群设置至少需要三个服务器，强烈建议使用奇数个服务器。
- 建议每个服务运行在单独的机器上。
2. ZooKeeper 集群搭建
tickTime=2000
dataDir=/tmp/zookeeper
clientPort=2181
initLimit=10
syncLimit=5
server.1=zoo1.2888:3888
server.2=zoo2.2888:3888
server.3=zoo3.2888:3888- initLimit：集群中的 follower 服务器（F）与 leader 服务器（L）之间完成初始化同步连接时能容忍的最多心跳数（tickTime 的数量）。如果 zk 集群环境数量确实很大，同步数据的时间会很长，因此这种情况下可以适当调大该参数。
- syncLimit：集群中的 follower 服务器与 leader 服务器之间请求和应答之间能容忍的最多心跳数（tickTime 的数量）。
- 集群节点：
server.id=host:port:port- id：通过在各自的 dataDir 目录下创建一个名为 myid 的文件来为每台机器赋予一个服务器 id。
- 两个端口号：第一个跟随者用来连接到领导者，第二个用来选举领导者。
- myid 文件：一行内容，只包含机器 id 的文本。id 在集群中必须是唯一的，其值应该在 1 到 255 之间。如服务器 1 的 id 为 “1”。
3. 连接到 Zookeeper 集群
- 集群的所有节点都可以提供服务，客户端连接时，连接串中可以指定多个或全部集群节点的连接地址。当一个节点不通时，客户端将自动切换另一个节点。
"10.168.1.23:2181,10.168.1.24:2181,10.168.1.25:2181"4. Zookeeper 集群监控
说明文档：http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_monitoring
- 四字监控命令：https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_zkCommands
- JMX：https://zookeeper.apache.org/doc/current/zookeeperJMX.html
5. Zookeeper 集群 - ZAB 协议
- Zookeeper 每个实例中保存的都是全量数据。作为重要的分布式协调服务，如何保证集群数据的一致性？
- ZAB 协议（Zookeeper Atomic Broadcast，Zookeeper 原子广播协议）是专为 Zookeeper 设置的数据一致性协议。
ZAB 协议过程说明
- 所有事务请求转发给 Leader。
- Leader 分配全局单调递增事务 id（Zxid），广播事务提议。
- Follower 处理提议，做出反馈。
- Leader 收到过半数反馈，广播 Commit。
- Leader 做出响应。
ZAB 协议重要特性：有序性。
崩溃恢复
Leader 服务器出现崩溃，或者说因为网络原因导致 Leader 服务器丢失与过半 Follower 的联系，那么就会进入崩溃恢复模式。
- ZAB 协议规定如果一个 Proposal 在一台机器上被处理成功，那么应该在所有的机器上都处理成功，哪怕机器出现故障崩溃。
- ZAB 协议确保那些已经在 Leader 服务器上提交的事务最终被所有服务器都提交。
- ZAB 协议确保丢弃那些只在 Leader 服务器上被提出的事务。
- ZAB 协议需要设计的选举算法应该满足：
- 确保提交已经被 Leader 提交的事务 Proposal，同时丢弃已经被跳过的事务 Proposal。
- 如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器最高的 ZXID 的事务 Proposal，那么就可以保证这个新选举出来的 Leader 一定具有所有已提交的提案。
- 如果让具有最高编号事务 Proposal 的机器成为 Leader，就可以省去 Leader 服务器检查 Proposal 的提交和丢弃工作的这一步操作。
数据同步
Leader 选举出来后，需完成 Followers 和 Leader 的数据同步，当半数的 Followers 完成同步，则可以开始提供服务。
- Leader 服务器会为每一个 Follower 服务器都准备一个队列，并将那些没有被各 Follower 服务器同步的事务以 Proposal 消息的形式逐个发送给 Follower 服务器，并在每一个 Proposal 消息后面紧接着再发送一个 Commit 消息，以表示该事务已经被提交。
- Follower 将所有其尚未同步的事务 Proposal 都从 Leader 服务器上同步过来并成功应用到本地数据库中后，Leader 服务器就会将该 Follower 服务器加入到真正的可用的 Follower 列表中，并开始之后的其他流程。
丢弃事务 Proposal 处理
- 在 ZAB 协议的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字。
- 低 32 位是一个简单的单调递增的计数器，针对客户端的每一个事务请求，Leader 服务器在产生一个新的事务 Proposal 的时候，都会对该计数器进行 1 操作。
- 高 32 位代表 Leader 周期纪元的编号，每当选举产生一个新的 Leader 服务器的时候，就会从这个 Leader 服务器上取出其本地日志中最大事务 Proposal 的 ZXID，并从该 ZXID 中解析出对应的纪元值，然后对其进行 1 操作，之后就会以此编号作为新的纪元，并将低 32 位置 0 来开始生成新的 ZXID。
- 基于这样的策略，当一个包含了上一个 Leader 周期中尚未提交过的事务 Proposal 的服务器启动加入到集群中，发现此时集群中已经存在 Leader，将自身以 Follower 角色连接上 Leader 服务器之后，Leader 服务器会根据自己服务器上最后被提交的 Proposal 和 Follower 服务器的 Proposal 进行对比，发现 Follower 中有上一个 Leader 周期的事务 Proposal 时，Leader 会要求 Follower 进行一个回退操作（回退到一个确实已经被集群中过半机器提交的最新的事务 Proposal）。
6. Zookeeper 集群 Leader 选举
- 对选举算法的要求：
- 选出的 Leader 节点上要持有最高的 zxid。
- 过半数节点同意。
- 内置实现的选举算法：
- LeaderElection
- FastLeaderElection（默认）
- AuthFastLeaderElection
Leader 选举机制概念
- 服务器id myid（一个数字）
- 事务id，服务器中存放的最大 zxid
- 逻辑时钟，发起的投票轮数技术（比如第一轮发起，长时间没收到响应，会发起第二轮投票，此时如果收到第一轮投票结果，需要将结果丢弃）
- 选举状态：
- Looking：竞选状态。
- Following：跟随状态，同步 leader 状态，参与投票。
- Observing：观察状态，同步 leader 状态，不参与投票。
- Leading：领导者状态。
Leader 选举算法
- 选举算法：
- 每个服务实例均发起选举自己为领导者的投票（自己的投给自己）；
- 其他服务实例收到投票邀请时，比较发起者的数据事务 ID 是否比自己最新的事务 ID 大，大则给它投一票，小则不投票给它，相等则比较发起者的服务器 ID，大则投票给它；
- 发起者收到大家的投票反馈后，看投票数（含自己的）是否大于集群的半数，大于则胜出，担任领导者；未超过半数且领导者未选出，则再次发起投票。
- 胜出条件：投票赞成数大于半数则胜出的逻辑。
Leader 选举示例说明
- 有5台服务器,每台服务器均没有数据,它们的编号分别是1,2,3,4,5,按编号依次启动,它们的选举过程如下:
- 服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器1的状态一直属于Looking。
- 服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是Looking
- 服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以服务器3胜出,此时投票数正好大于半数,所以服务器3成为领导者,服务器1,2成为小弟。
- 服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为小弟。
- 服务器5启动,后面的逻辑同服务器4成为小弟。
7. Zookeeper 参数配置
- https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_configuration
