1. ZooKeeper 入门
1.1 是什么
ZooKeeper 是一个开源的分布式的，为分布式应用提供协调服务的应用。
工作机制：
ZooKeeper 从设计模式角度来理解：是一个基于观察者模式的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，ZooKeeper 就将负责通知已经在 ZooKeeper 上注册的那些观察者做出相应的反应。
ZooKeeper = 文件系统+通知机制
1.2 特点：
1）ZooKeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群；
2）集群只要有半数以上的节点存活，ZooKeeper 集群就能正常服务。
3）全局数据一致：每个 Server 保存一份相同的数据副本，Client 无论连接到哪个 Server，数据都是一致的。
4）更新请求顺序进行，一次数据更新要么成功，要么失败。
5）数据更新原子性，一次数据更新要么成功，要么失败。
6）实时性，在一定时间范围内，Client 能读到最新数据。
1.3 ZooKeeper 数据结构
ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看做是一棵树，每个节点称作一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识。
1.4 应用场景
提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
- 统一命名服务
在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。
例如：IP 不容易记住，而域名容易记住。
-
统一配置管理
应用场景-统一配置管理.png
- 分布式环境下，配置文件同步非常常见。
（1）一般要求一个集群中，所有节点的配置信息是一致的，比如 Kafka 集群。
（2）对配置文件修改后，希望能够快速同步到各个节点上。
2）配置管理可交由 ZooKeeper 实现。
（1）可将配置信息写入 ZooKeeper 上的一个 Znode。
（2）各个客户端服务监听这个 Znode。
（3）一旦 Znode 中的数据被修改，ZooKeeper 将通知各个客户端服务器。
- 统一集群管理
1）分布式环境中，实时掌握每个节点的状态是必要的。
（1）可根据节点实时状态做出一些调整。
2）ZooKeeper 可以实现实时监控节点状态变化
（1）可将节点信息写入 ZooKeeper 上的一个 ZNode。
（2）监听这个 ZNode 可获取它的实时状态变化。
- 服务器动态上下线
客户端能实时洞察到服务器上下线的变化。
- 软负载均衡
在 ZooKeeper 中记录没太服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。
2. ZooKeeper 安装配置
2.1 安装 部署
1）安装
学习环境Mac通过 brew 安装，过程略....
TODO:Linux 集群安装待补充......
- 配置修改
brew 安装 ZooKeeper 安装配置文件位于/usr/local/etc/zookeeper下；
实际生产中 Linux 位于 ZooKeeper 安装目录 conf 下。
修改如下内容：dataDir=/opt/module/zookeeper-3.4.10/zkData
（3）在/opt/module/zookeeper-3.4.10/这个目录上创建zkData文件夹
3）操作 ZooKeeper
以下操作场景为mac 环境下 brew 本地安装ZooKeeper演示环境，Linux 环境略有不同。
(3)启动客户端
➜ ~ zkCli
Connecting to localhost:2181
Welcome to ZooKeeper!
JLine support is enabled
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
[zk: localhost:2181(CONNECTED) 0]
(4)退出客户端
[zk: localhost:2181(CONNECTED) 0] quit
Quitting...
(5)停止 ZooKeeper
➜ ~ zkserver stop
ZooKeeper JMX enabled by default
Using config: /usr/local/etc/zookeeper/zoo.cfg
Stopping zookeeper ... STOPPED
2.2 配置参数解读
Zookeeper中的配置文件zoo.cfg中参数含义解读如下：
1．tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒
Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。
它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)
2．initLimit =10：LF初始通信时限
集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。
3．syncLimit =5：LF同步通信时限
集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。
4．dataDir：数据文件目录+数据持久化路径
主要用于保存Zookeeper中的数据。
5．clientPort =2181：客户端连接端口
监听客户端连接的端口。
3. ZooKeeper 内部原理
3.1 选举机制
1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
3）以一个简单的例子来说明整个选举的过程。
假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如图所示。
（1）服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。
（2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。
（5）服务器5启动，同4一样当小弟。
关于ZooKeeper选举机制的更多介绍，请参考：https://www.jianshu.com/p/3476587a6fa1
3.2 节点类型
