1. Zookeeper
1.1. 概述
为分布式应用提供协调服务。
从设计模式的角度，它是一个基于==观察者模式==设计的分布式服务管理框架，它负责存储和管理大家关心的数据，接受观察者的注册，一旦数据发生变化，Zookeeper将变化的信息通知给注册的观察者。
1.2. 特点
- Zookeeper: 一个leader和多个Follower，组成的集群
- 集群中只要有半数以上的节点存活，Zookeeper集群就能正常服务
- 全局数据一致： 每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
- 更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行
- 数据更新原子性，一次数据更新要么成功，要么失败
- 实时性：在一定时间范围内，client能读到最新数据
1.3. 数据结构
数据模型结构与Unix文件系统很类似，整体上可看做一棵树，每个节点称作一个ZNode。每个ZNode默认可存储1MB的数据，每个ZNode可以通过路径唯一标识。
1.4. 应用场景
- 统一命名服务
- 统一配置管理
- 统一集群管理
- 服务器节点动态上下线
- 软负载均衡
2. 内部原理
2.1. 选举机制
目前有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成为小弟。
2.2. 节点类型
持久（Persistent）：客户端和服务器断开连接后，创建的节点不删除
持久化目录节点：
客户端与Zookeeper断开连接后，该节点依旧存在
持久化顺序编号目录节点：
客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该接待名称进行顺序编号，例如“znode2_001”
说明：创建Znode时设置顺序标识，znode名称后会附加一个值，顺序号是单调递增的计数器，由父节点维护
注意：在分布式系统中，顺序号可以被用于为所有的全局事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序
短暂（Ephemeral）：客户端和服务器断开连接后，创建的节点自己删除
临时目录节点：
客户端与Zookeeper断开连接后，该节点被删除
临时顺序编号目录节点：
客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该接待名称进行顺序编号
2.3. 监听器原理
2.4. 写数据流程
