1 为什么需要zk
当前应用服务发生了很大的变化，在大数据和云计算盛行的今天，应用服务由很多独立的程序组成，如何让一个应用中多个独立的程序协同工作是一件非常头疼的事。
zookeeper从文件系统API得到启发，提供一组简单的API，使得开发人员可以实现通用的协作任务，包括选举主节点、管理组内成员关系、管理元数据等。zookeeper包括一个应用开发库(主要提供Java和C两种语言的API)和一个用Java实现的服务组件，ZK的服务组件运行在一组专用服务器上，保证了高容错性和可扩展性。
2 主从应用
典型的主从应用工作模式中，从节点处于空闲状态时会通知主节点可以接收工作，于是主节点会分配任务给从节点。获取主节点身份的过程就是获取锁的过程，获得主节点控制权锁的进程就是主节点进程。
在一个典型的不共享环境下不同的计算机之间不共享除了网络之外的其他任何消息，虽然许多消息传递算法可以实现同步原语，但是ZK使用一个提供某种有序共享存储的组件。
ZK的应用实例：
HBase是一个与Hadoop一起使用的数据存储仓库，在HBase中ZK用于选举一个集群中的主节点，以便跟踪可用的服务器，并保存集群的元数据；
Kafka是一个基于发布-订阅模式的消息系统，其中ZK用于检测崩溃、实现主题的发现，并保持主题的生产和消费状态；
Solr是一个企业级的搜素平台，分布式本名SolrCloud，它使用ZK来存储集群中的元数据，并协作更新这些数据。
开发中应用ZK往往看成是连接到ZK服务端的客户端，ZK客户端API包括：
A：保障强一致性、有序性和持久性；
B：实现通用的同步原语的能力；
C：简单的并发处理机制；
3 ZK特点
3.1 ZK区别其他分布式系统
ZK之前的一些系统采用分布式锁管理器或者分布式数据库实现协作。但是ZK设计更关注任务协作，并不提供任何锁或数据存储接口，同时ZK也没有给开发人员加入任何特殊的同步原语，使用起来非常灵活。
3.2 ZK构建分布式系统
分布式系统定义：分布式系统是同时跨越多个物理主机，独立运行多个软件组件所组成的系统；
分布式系统中的进程通信有两种方式：直接通过网络信息交换或读写某些共享存储。ZK使用共享存储模式来实现应用的协作和同步原语；共享存储本身需要在进程和存储间进行网络通信；ZK不适用海量数据存储；
在实际系统中的问题：
A：消息延迟
B: 处理器性能
C： 时钟偏移
CAP的定义
Consistency (一致性)：
“all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
Availability (可用性):
可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
Partition Tolerance (分区容错性):
即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。
CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：
CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。
AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。
4 以HBase了解主从应用
HBase主节点服务器（HMaster）负责跟踪区域服务器（HRegionServer）是否可用，并分派区域到服务器。在这种架构中主节点进程负责跟踪从节点状态和任务东有效性，并分配任务到从节点。ZK完成了如选举主节点、跟踪有效东从节点，维护应用元数据。
面临三个关键问题：主节点崩溃、从节点崩溃、通信故障
问题解决：
主节点失效：当主节点崩溃时，备份主节点接管主节点角色，进行故障转移；新主节点需要恢复到旧的主节点崩溃时的状态，不能直接从崩溃的主节点获取信息，ZK负责获取崩溃主节点信息；
从节点失效：正常情况下客户端向主节点提交任务，之后主节点将任务派发到有效的从节点中，从节点接收到派发的任务，执行完成这些任务后向主节点报告执行状态，主节点会将执行结果通知给客户端。
如果从节点崩溃，所有派发任务可能执行完毕或没有执行完成，主节点具有检测从节点崩溃的能力，并清除之前的状态。
通信故障：主从节点网络故障导致一个任务执行多次，“仅一次”和“最多一次”的语义，对任务加锁并不能保证一个任务执行多次；
网友评论