ZooKeeper 简单理解

ZooKeeper 概览
ZooKeeper 是一个开源的分布式协调服务，ZooKeeper 框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。
ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、
集群管理、Leader选举、分布式锁和分布式队列等功能。
ZooKeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。
服务生产者将自己提供的服务注册到 ZooKeeper 中心，服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。

Zookeeper 组件结构
除了request processor, 组成zookeeper服务的每个server都会在本地备份其它组件的拷贝(应该是Leader的复本）。
复制数据库是一个内存数据库，保存了所有的数据树；更新操作被记录到磁盘中，便于数据恢复；写操作在应用于内存数据库之前先被序列化到磁盘上了。
也就是说磁盘上的日志才是数据正真的现状。

有条件地更新和监控
Zookeeper支持监控，即客户端可以设置在某个znode（数据节点）上的监控；当一个节点发生变化时，就会触发和删除一个监控。当一个监控触发时，客户端会收到一个说明节点变化的包。当客户端和Zookeeper Server断开时，客户端将收到一个本地通知。
本质就是：监听器（观察者模式）

各种保证
Zookeeper之所以能构造复杂的服务，如同步、配置管理、组管理等功能，是因为它提供了一系列的保证：
1）顺序一致性：客户端的更新操作必须与它们被发送的顺序严格一致
2）原子性：更新操作要么成功、要么失败
3）单个系统影像：一个客户端将会看到相同的服务视图，不管它与那个Server连接（跟一致性是呼应的）
4）可靠性：一旦一个更新操作被应用，从更新时间点向前的时间都将报错一致，直到下一次更新。
5）时间轴：在一个特定的时间点上，客户端看到的系统视图被保证是最新的。

读写分离流程
每一个Zookeeper服务器都能为客户端服务，客户端连接到具体某个服务器后并提交请求。
读请求直接由本地每个服务器数据库的备份来满足（直接由提供Zookeeper服务器的内存数据）；
而那些可能改变服务状态的请求，即写请求，通过一致性协议Zab（Zookeeper Atomic Broadcast）来处理。
一致性协议的处理流程：来自客户端的写请求被统一发送到一leader节点，其他的追随者节点，接受Leader节点的消息建议，并统一消息发送。
消息层负责Leader失败时替换Leader，和同步追随者和Leader。
Zookeeper使用一个客户原子消息协议。因为消息层是原子的，Zookeeper可以保证本地复制从来不会有分歧。当Leader节点收到写请求时，它会计算当前系统的写操作被应用时的状态，并且将其转换成一个捕获了最新状态的事务。
Zookeeper Transactions是有序的、Zookeeper是快速的（在10：1的读写比例下，在读优先的工作量下，表现是较好的）。

Zookeeper应用场景
1）配置管理：分布式应用中的统一配置管理，提供集中服务配置管理功能，应用场景HBase,控制集群配置信息；Kafka消息队列，使用Zookeeper，管理Broker(经纪人）
Alibaba的服务器治理框架Dubbo，利用zookeeper来管理一些服务配置。
2）命名管理：跟域名类似的功能，类似域名管理的；如果应用中需要服务和IP的映射关系的配置，也可以统一集中管理。
3）分布式锁服务：HBase的HMaster的使用。
4）集群管理：用于管理在线集群信息

分布式组件都有一些相通的设计思想，如数据分区、一致性保证等，前一段时间玩过Redis的Sentinel集群实践，再回头看Zookeeper的时候，发现它俩自动选举Leader进行故障修复的流程是一样的。网上查了查才知道，原来是Redis的故障处理流程是基于Zookeeper的。
Zookeeper提供的主要服务就是统一配置、选举、监听等，所以使用它的产品主要用它来实现消息的发布订阅（消息队列）、主节点的选举、配置更新等功能。