Dubbo用zookeeper做为注册中心的注册机制

前言

上次小编为大家介绍了 Dubbo 服务化最佳实践以及用redis作为注册中心的原理讲解。不过没有说完，今天接着为大家带来Dubbo以Zookeeper为注册中心的注册机制和原理。小编后续会写一篇Dubbo注册中心相关的源码阅读文章，希望给大家带来帮助。好了进入今天的主题。

Zookeeper注册中心

Zookeper是⼀个树型的⽬录服务，本身⽀持服务的变更推送。

存储结构

zookeeper 存储结构是采⽤树级⽬录形式，其层级分别是 dubbo\接⼝名\提供者、消费者\URL. 都是以节点名称的形式存储。其中的URL作为临时节点 存在，当应⽤与Zookepper会话断开后， 其会被⾃动删除。

上面图其实是没画全的，因为其还有config，这个暂且不表。
接下来我们通过zookeeper可视化界面验证器存储结构，这边小编启动了两个服务端和一个消费端。

上面的像文件夹一样的就是永久节点，而像文件的就是临时节点，前面的描述不是很准确（因为当服务关闭的时候，永久节点也会变成文件一样的图标）。其实可以点击Node Metadata查看他的信息，里面有Ephemeral Id可判断这个是否连接当前会话判断，如下图


注意：如果是程序突然宕机，zookeeper其会话不会马上关闭，默认会保留40秒超时等待。期间临时节点不会删除 。

节点监听

当服务向注册中心发布更新自己的服务时，客户端是怎么及时获取到他的信息的。这就是接下来要讲到节点监听。这边可以监听父节点下面子节点的数量，子节点的状态，数据等等。

#打开一个客户端
./bin/zkCli.sh
#创建一个非临时节点
create /names 1
#监听子节点的变化
ls /names watch
#打开一个新客户端
#在新客户端中创建节点，监听事件将会被触发
create -e /names/bob 1

上面每次watch后又得重新watch才可以哦。所以dubbo每次都得重新订阅才可以，接下来咱们看一下dubbo订阅和发布流程。

订阅与发布流程

上面讲到dubbo 利用zookeeper的监听机制，去监听 /dubbo/{接口名}/providers 的子节点信息，从而达到订阅发布的目的。
其流程如下：

1. 消费端
   a. 启动：注册消费者信息(创建临时节点)
   b. 启动：订阅提供者信息（添加providers⼦节点监听事件）
   c. 触发订阅：更新提供者列表，重新订阅
   d. 停止：注销消费者信息(删除临时节点),取消订阅
2. 提供端
   a. 启动：注册提供者信息(创建临时节点)
   b. 停止：注销提供者信息(删除临时节点)

相关源码
org.apache.dubbo.registry.zookeeper.ZookeeperRegistry#doRegister// 注册 org.apache.dubbo.registry.zookeeper.ZookeeperRegistry#doUnregister// 注销 org.apache.dubbo.registry.zookeeper.ZookeeperRegistry#doSubscribe// 订阅 org.apache.dubbo.registry.zookeeper.ZookeeperRegistry#doUnregister // 取消订阅
注：doRegister注册包括消费者和提供者的信息。

有兴趣的小伙伴可以看一下源码这个源码比以redis作为注册中心的源码简单太多了。小编后续为大家奉上关键源码详解。

与redis对比优点

大家可能只知道dubbo的注册中心用zookeeper比较好，但不知道好在哪些地方，这边小编总结了以下几点，希望给大家做个参考。

• redis作为注册中心时需要自己做发布和定义，而zookeeper自带了发布订阅功能，只需监听即可，且更稳定。
• redis每隔30秒需要心跳保活机制，而zookeeper却不需要。
• 当机子宕机时，redis会产生脏数据，虽然最终会通过redis的过期淘汰机制，但有脏数据可能会存在较长时间，而zookeeper则会自动清除。
• redis需要启动一个线程来监听服务并且更新接口列表，并且是个阻塞线程，当生产环境有大量服务和客户端时，监听线程非常多，且更新耗时耗力，不适合做注册中心。而zookeeper是非阻塞的且监听迅速。

所以zookeeper更适合做dubbo的注册中心。

总结

好了今天就聊到这儿了，小编下期为大家带来dubbo集群机制详解（负载均衡与容错机制）。最后希望大家喜欢小编，记得三连。小编会继续进步努力的！