Question

zookeeper

Answer 1

客户端的Watcher

String就是节点的path，有三大类。
dataWatches：数据watcher
existWatches：节点是否存在的watcher
childWatches：节点的子节点个数变化，包括：0->1，1->2等等，只要数量变化就触发。

对于zk的watcher机制，有几个疑问？

三、ZK的通信协议
分两类：请求和响应协议。是基于TCP/IP的应用层协议，其实就是规定了应用层报文的格式，以及每个字段的含义。客户端和服务端双方都遵守这种约定，脱离了ZK，其他框架是无法识别这种通信协议的。

请求和响应报文格式，网上搜一下一大堆。这里不再赘述

那么回到什么是分布式协调呢？我们就以RPC这种场景来说：
比如我们可以理解上面的图，一半client是service角色，一半client是consumer角色，然后zk提供了这些client之间的协调 -- 充当consumer角色的client必须依赖于充当service角色提供的服务，这可不就是分布式协调的一种嘛（协调其中一半的client依赖另一半）。当然我们可以继续扩展：分布式配置中心Disconf，有个client它的角色可以是管理员(配置员)，它是一个进程。它向zk某一个节点配置了XX数据，然后其他所有client同时收到最新配置。这可不就是另外一种协调了嘛（其他client依赖这个配置的值执行业务）。

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能

乍一看这个定义挺抽象的，一时半会没理解。其实举个例子就容易理解的多，比如你有个资源，我们先简单把该资源当做一个本地文件或本地电影。你为了保证该资源的可靠性，你需要把该资源copy到3台机器上。那么这三个资源，在互联网上就会有三个url地址：机器1/xxx/xxx/xxx.pdf，机器2/xxx/xxx/xxx.pdf，机器3/xxx/xxx/xxx.pdf。请求方为了访问该资源，肯定不会把这三个地址硬编码到自己本地，这样不易拓展。所以这个时候，就需要一个统一命名服务来封装该资源的三个真实地址，对外只提供一个地址并且永远可以不变。那么这个统一命名服务，我们当然可以用http协议来实现，也可以用zk协议(ZAB协议)来实现。
现在理解了上面的内容，那么我们就容易拓展这个资源的定义了。上面所说的资源，我们可以拓展为一个服务 xxx.xxx.xxx.UserService，该服务的提供方可以有很多个，但是为了封装真实提供方，我们只能对外暴露一个地址那就是xxx.xxx.xxx.UserService。是不是很熟悉？Dubbo的ZK注册中心，就是这么干的。

理解定义我们就不说了，这个很好理解。实际案例咱们可以参考Dubbo的ZK，提供者发布或修改服务真实地址后，消费者可以实时收到变化的通知，然后再去ZK拉取最新数据。这可不就是ZK的发布与订阅嘛，通过Listener观察者模式来实现。应用场景很多：RPC服务发现，配置中心的配置分发等等。

所谓集群管理无在乎两点：是否有机器退出和加入、选举 Master。
不就是ZK的发布订阅嘛，没啥好说的。

这里的maser选举，可不是ZK内部的master选举（两者相差十万八千里）。这里的master选举，是指业务调用方，属于client角色的进程，进行选举。
业务master选举其实很简单，完全没必要像ZK内部选举那样，还要实现一套可靠的选举算法(paxos算法包含了一个提案选举，paxos算法可不止一个选举算法)。ZK本身提供了一个可靠创建唯一节点的API接口，这个接口保证了并发调用只会有一个成功。那么业务master选举，是不是可以转化为多个业务进程并发调用该API接口，谁创建唯一节点成功了，谁就是master了，其他进程就是slave。怎么感觉这么像分布式锁的实现呢？除了少了释放锁的通知操作。。。

软负载均衡也没啥好说的，就是注册与发现的变种，或者说发布与订阅的变种。获取统一命名服务的所有提供者列表，然后通过负载均衡算法在这一堆列表中选择一个，策略可以是随机选择，轮训选择，Hash一致性选择等等。。。Dubbo的负债均衡是实现在消费者调用逻辑里面的，并不在获取列表接口里面，ZK不做负载均衡，基于ZK的应用可以做。

和上面的数据发布与订阅 一模一样 ，不在赘述。

和上面说的Master选举很像，都是一堆client角色的业务调用方，调用创建某唯一节点的API。谁创建成功，谁就拿锁。只不过ZK的底层实现是严格按照顺序来的，所以必然是ZK接收请求的时候，谁第一个谁拿锁。注意可不是client谁先请求谁拿锁。client请求还要经过网络，同时请求是没法确定哪个client先到达的。
但是光创建唯一节点成功还不叫锁，锁天然包含了两个功能：可重入和释放锁唤醒其他等待的client节点。可重入ZK是实现不了，需要业务方自己实现。释放锁的唤醒ZK是通过Listener的通知唤醒的。

我们看下上面的所有应用场景，其实本质上都是调用zk的两个最核心的接口：创建节点和监听节点变化。

ZooKeeper 将数据保存在内存中，这也就保证了高吞吐量和低延迟 （但是内存限制了能够存储的容量不太大，此限制也是保持 znode 中存储的数据量较小的进一步原因）。ZK集群加机器可不能增加内存，为啥呢？因为ZK集群里面的所有数据，都是每台机器保存一份副本。整个集群内存最小的机器，决定整个集群的内存大小。

ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其的高性能 ，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）

ZooKeeper 底层其实只提供了两个功能：