事件通知——ZooKeeper实现服务注册与发现的重要机制

ZooKeeper作为一款分布式协调框架，被广泛应用在分布式，大数据开发领域，雅虎研究员设计Zookeeper的初衷，是想利用Zookeeper的临时顺序节点，轻松实现分布式锁，但随后Zookeeper被应用与服务注册发现中，最著名的应用莫过于阿里的分布式RPC框架Dubbo，那么ZooKeeper为什么能被阿里选中，成为服务的注册中心呐，今天我们就一起聊一聊这个话题。

ZooKeeper的数据模型

要想了解今天的问题，我们要从ZooKeeper的数据模型说起，它很像数据结构当中的树，树是由节点所组成，Zookeeper 的数据存储也同样是基于节点，这种节点叫做 Znode，但是，不同于树的节点，Znode 的引用方式是路径引用，类似于文件路径，要拿到节点中存放的数据，就要通过路径才能获取，也就是是说，它和文件系统和REST风格类似，是基于路径访问资源的。

由于ZooKeeper的数据模型非常像文件系统，所以这就允许我们通过访问对应路径下的Znode来获取其中的数据，当一个请求通过网关进入ZooKeeper时，ZooKeeper便可通过url中的路径匹配相应的服务，并进行调用。

ZooKeeper的事件通知

那么大量的服务注册到ZooKeeper集群上，当服务发生宕机，或故障时，ZooKeeper将如何处理呐？这里便用到了我们将要聊到的事件通知（Watch）。

我们可以把 Watch 理解成是注册在特定 Znode 上的触发器。当这个 Znode 发生改变，也就是发生写操作的时候，将会触发 Znode 上注册的对应事件，请求 Watch 的客户端会接收到异步通知。

具体的流程如下：

服务端接到请求后，会返回数据并且在对应的哈希表里插入被 Watch 的 Znode 路径以及Watcher列表（WatchTalbe）。

当被 Watch 的 Znode 已删除，服务端会查找哈希表，找到该 Znode 对应的所有 Watcher，异步通知客户端，并且删除哈希表中对应的 Key-Value。

服务注册与发现流程简单分析

当服务上线后，各个服务会注册到ZooKeeper，这时ZooKeeper通过写操作，将各个服务的ip等信息存储到Znode中

假设用户通过API网关调用A服务，API网关通过REST风格的接口路径即可得到访问从ZooKeeper客户端获取数据的Key

当ZooKeeper客户端调用读操作，并开启事件通知模式时，即可轻松的获取对应的数据，并将被Watch的服务写入哈希表，当注册到ZooKeeper的服务出现故障宕机时，即可通过异步通知ZooKeeper客户端，将相应的服务从哈希表中移除，这便实现了服务注册的基本功能。

当然，在实际的部署中，ZooKeeper及各个服务均会部署多个，以实现服务的高可用，但是将服务全部注册到ZooKeeper集群中，当ZooKeeper集群发生故障时，能否保障提供正常的服务注册发现服务呐，我们在下个文章一起聊聊吧。