Zookeeper作为一个分布式协调系统提供了一项基本服务：分布式锁服务，分布式锁是分布式协调技术实现的核心内容。像配置管理、任务分发、组服务、分布式消息队列、分布式通知/协调等，这些应用实际上都是基于这项基础服务由用户自己摸索出来的。
1.Zookeeper在大数据系统中的常见应用
zookeeper作为分布式协调系统在大数据领域非常常用，它是一个很好的中心化管理工具。下面举几个常见的应用场景。
1.1.HDFS/YARN
- HA(分布式锁的应用)：Master挂掉之后迅速切换到slave节点。
1.2.hbase
- HA ：同上。
- 配置管理 ：client需要读写hbase的数据首先都是连到ZK读取root表，获得meta表所在的region，最后找到数据所在位置。
- 任务发布：regionserver挂了一台，master需要重新分配region，会把任务放在zookeeper等regionserver来获取
1.3.kafka
- 配置管理：broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新
- 任务分配：给topic分配partitions和replication
2.Zookeeper有哪些操作特性
2.1.数据结构
ZooKeeper命名空间中的Znode，兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。 每个Znode由3部分组成:
- stat状态信息：描述该Znode的版本, 权限等信息
- data：与该Znode关联的数据(配置文件信息、状态信息、汇集位置)，数据大小至多1M
- children：该Znode下的子节点
ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
2.2.watch机制
ZooKeeper可以为所有的读操作设置watch，包括：exists()、getChildren()及getData()。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次，这样可以减少网络流量。
- 数据watch(data watches)：getData和exists负责设置数据watch
- 孩子watch(child watches)：getChildren负责设置孩子watch
2.3.节点类型
ZooKeeper中的节点有两种，分别为临时节点和永久节点(还可再分为有序无序)。节点的类型在创建时即被确定，并且不能改变。
- 临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。另外，ZooKeeper的临时节点不允许拥有子节点。（分布式队列）
- 永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
3.这些应用是如何通过这些特性实现的
3.1.HA:
两种方式：
- 创建两个或多个有序临时节点，永远把最小值当做master
- 创建临时节点的为master，多个slave会watch这个节点
3.2.配置管理：
存储集群元数据提供给client使用，体现在比如需要对HBase和Kafka操作时，都会直接连到zookeeper，zookeeper记录了数据存储的位置，存活的节点等元数据信息。
3.3.任务发布：
Master要监视/works和/tasks两个永久节点，以便能感知到由哪些slave当前可用，当前有新任务需要分配。
分配过程：在/assign下创建当前可用的workA，找到需要分配的taskA，创建/assign/workA/taskA
4.zookeeper架构设计
zookeeper作为一个分布式协调系统，很多组件都会依赖它，那么此时它的可用性就非常重要了，那么保证可用性的同时作为分布式系统的它是怎么保证扩展性的？问题很多，读完接下来的内容你会有答案。
上图来自zookeeper的官方文档，我解释下这张图的各个角色（observer在上图中可以理解为特殊的follower）
| 角色 | 分工 | 数量 |
|---|---|---|
| client客户端 | 请求发起方 | 不限 |
| observer观察者 | 接受用户读写请求，写转发给leader，读直接返回（选主过程不参加投票） | 不限 |
| follower跟随者 | 接受用户读写请求，写转发给leader，读直接返回（选主过程参加投票） | 奇数个（不可过多） |
| leader领导者 | 负责提议，更新系统状态 | 1个 |
另外：follower和observer同时均为learner（学习者）角色，learner的分工是同步leader的状态。
5.zookeeper的读写
zookeeper的各个复制集节点（follower，leader，observer）都包含了集群所有的数据且存在内存中，像个内存数据库。更新操作会以日志的形式记录到磁盘以保证可恢复性，并且写入操作会在写入内存数据库之前序列化到磁盘。
每个ZooKeeper服务器都为客户端服务。客户端只连接到一台服务器以提交请求。读取请求由每个服务器数据库的本地副本提供服务。更改服务状态，写请求的请求由zab协议处理。
作为协议协议的一部分，来自客户端的所有写入请求都被转发到称为leader的单个服务器。其余的ZooKeeper服务器（称为followers）接收来自领导者leader的消息提议并同意消息传递。消息传递层负责替换失败的leader并将followers与leader同步。
ZooKeeper使用自定义原子消息传递协议zab。由于消息传递层是原子的，当领导者收到写入请求时，它会计算应用写入时系统的状态，并将其转换为捕获此新状态的事务。
6.zookeeper的CAP原则
cap原则是指作为一个分布式系统，一致性，可用性，分区容错性这三个方面，最多只能任意选择两种。就是必定会要有取舍。
- 一致性C
Zookeeper是强一致性系统，同步数据很快。但是在不用sync()操作的前提下无法保证各节点的数据完全一致。zookeeper为了保证一致性使用了基于paxos协议且为zookeeper量身定做的zab协议。这两个协议是什么东西之后的文章会讲。
- 可用性A（高可用性和响应能力）
Zookeeper数据存储在内存中，且各个节点都可以相应读请求，具有好的响应性能。Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的。
- 分区容忍性P
有2点需要分析的
- 节点多了会导致写数据延时非常大（需要半数以上follower写完提交）,因为需要多个节点同步.
- 节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.
zk在CAP问题上做的取舍
严格地意义来讲zk把取舍这个问题抛给了开发者即用户。
为了协调CA（一致性和可用性），用户可以自己选择是否使用Sync()操作。使用则保证所有节点强一致，但是这个操作同步数据会有一定的延迟时间。反过来若不是必须保证强一致性的场景，可不使用sync，虽然zookeeper同步的数据很快，但是此时是没有办法保证各个节点的数据一定是一致的，这一点用户要注意。实际的开发中就要开发者根据实际场景来做取舍了，看更关注一致性还是可用性。
为了协调AP（一致性和扩展性），用户可以自己选择是否添加obsever以及添加个数，observer是3.3.0 以后版本新增角色，它不会参加选举和投票过程，目的就是提高集群扩展性。因为follower的数量不能过多，follower需要参加选举和投票，过多的话选举的收敛速度会非常慢，写数据时的投票过程也会很久。observer的增加可以提高可用性和扩展性，集群可接受client请求的点多了，可用性自然会提高，但是一致性的问题依然存在，这时又回到了上面CA的取舍问题上。
7.zookeeper的选主机制
FastLeaderElection原理
- myid
每个Zookeeper服务器，都需要在数据文件夹下创建一个名为myid的文件，该文件包含整个Zookeeper集群唯一的ID（整数）。例如某Zookeeper集群包含三台服务器，hostname分别为zoo1、zoo2和zoo3，其myid分别为1、2和3，则在配置文件中其ID与hostname必须一一对应，如下所示。在该配置文件中，server.后面的数据即为myid
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888- zxid
类似于RDBMS中的事务ID，用于标识一次更新操作的Proposal ID。为了保证顺序性，该zkid必须单调递增。因此Zookeeper使用一个64位的数来表示，高32位是Leader的epoch，从1开始，每次选出新的Leader，epoch加一。低32位为该epoch内的序号，每次epoch变化，都将低32位的序号重置。这样保证了zkid的全局递增性。
7.1.支持的领导选举算法
可通过electionAlg配置项设置Zookeeper用于领导选举的算法。
到3.4.10版本为止，可选项有
0 基于UDP的LeaderElection
1 基于UDP的FastLeaderElection
2 基于UDP和认证的FastLeaderElection
3 基于TCP的FastLeaderElection在3.4.10版本中，默认值为3，也即基于TCP的FastLeaderElection。另外三种算法已经被弃用，并且有计划在之后的版本中将它们彻底删除而不再支持。
7.2.FastLeaderElection
FastLeaderElection选举算法是标准的Fast Paxos算法实现，可解决LeaderElection选举算法收敛速度慢的问题。
服务器状态
- LOOKING 不确定Leader状态。该状态下的服务器认为当前集群中没有Leader，会发起Leader选举
- FOLLOWING 跟随者状态。表明当前服务器角色是Follower，并且它知道Leader是谁
- LEADING 领导者状态。表明当前服务器角色是Leader，它会维护与Follower间的心跳
- OBSERVING 观察者状态。表明当前服务器角色是Observer，与Folower唯一的不同在于不参与选举，也不参与集群写操作时的投票
7.2.选票数据结构
每个服务器在进行领导选举时，会发送如下关键信息
- logicClock 每个服务器会维护一个自增的整数，名为logicClock，它表示这是该服务器发起的第多少轮投票
- state 当前服务器的状态
- self_id 当前服务器的myid
- self_zxid 当前服务器上所保存的数据的最大zxid
- vote_id 被推举的服务器的myid
- vote_zxid 被推举的服务器上所保存的数据的最大zxid
7.2.投票流程
- 自增选举轮次
Zookeeper规定所有有效的投票都必须在同一轮次中。每个服务器在开始新一轮投票时，会先对自己维护的logicClock进行自增操作。
- 初始化选票
每个服务器在广播自己的选票前，会将自己的投票箱清空。该投票箱记录了所收到的选票。例：服务器2投票给服务器3，服务器3投票给服务器1，则服务器1的投票箱为(2, 3), (3, 1), (1, 1)。票箱中只会记录每一投票者的最后一票，如投票者更新自己的选票，则其它服务器收到该新选票后会在自己票箱中更新该服务器的选票。
- 发送初始化选票
每个服务器最开始都是通过广播把票投给自己。
- 接收外部投票
服务器会尝试从其它服务器获取投票，并记入自己的投票箱内。如果无法获取任何外部投票，则会确认自己是否与集群中其它服务器保持着有效连接。如果是，则再次发送自己的投票；如果否，则马上与之建立连接。
- 判断选举轮次
收到外部投票后，首先会根据投票信息中所包含的logicClock来进行不同处理
外部投票的logicClock大于自己的logicClock。说明该服务器的选举轮次落后于其它服务器的选举轮次，立即清空自己的投票箱并将自己的logicClock更新为收到的logicClock，然后再对比自己之前的投票与收到的投票以确定是否需要变更自己的投票，最终再次将自己的投票广播出去。
外部投票的logicClock小于自己的logicClock。当前服务器直接忽略该投票，继续处理下一个投票。
外部投票的logickClock与自己的相等。当时进行选票PK。
- 选票PK
选票PK是基于(self_id, self_zxid)与(vote_id, vote_zxid)的对比
外部投票的logicClock大于自己的logicClock，则将自己的logicClock及自己的选票的logicClock变更为收到的logicClock
若logicClock一致，则对比二者的vote_zxid，若外部投票的vote_zxid比较大，则将自己的票中的vote_zxid与vote_myid更新为收到的票中的vote_zxid与vote_myid并广播出去，另外将收到的票及自己更新后的票放入自己的票箱。如果票箱内已存在(self_myid, self_zxid)相同的选票，则直接覆盖
若二者vote_zxid一致，则比较二者的vote_myid，若外部投票的vote_myid比较大，则将自己的票中的vote_myid更新为收到的票中的vote_myid并广播出去，另外将收到的票及自己更新后的票放入自己的票箱
- 统计选票
如果已经确定有过半服务器认可了自己的投票（可能是更新后的投票），则终止投票。否则继续接收其它服务器的投票。
- 更新服务器状态
投票终止后，服务器开始更新自身状态。若过半的票投给了自己，则将自己的服务器状态更新为LEADING，否则将自己的状态更新为FOLLOWING
原文地址：http://blog.51cto.com/9587671/2178493