Dubbo之旅--注册中心

在介绍Dubbo的内部逻辑的时候提到不少次注册中心的概念.实现注册中心的有不少,主要是如下四个注册中心分别是:

 

Multicast注册中心

Zookeeper注册中心

Redis注册中心

Simple注册中心

 

      这里将对注册中心的一个实现Zookeeper跟你们分享,由于Zookeeper是应用比较多,也是咱们项目中实际用到的注册中心.

      

       ZooKeeper 是一个为分布式应用所设计的分布的、开源的协调服务。分布式的应用能够创建在同步、配置管理、分组和命名等服务的更高级别的实现的基础之上。 ZooKeeper 意欲设计一个易于编程的环境，它的文件系统使用咱们所熟悉的目录树结构。 ZooKeeper 使用 Java 所编写，可是支持 Java 和 C 两种编程语言。

    协调服务是很是容易出错的， 同时也很难恢复正常，例如，协调服务很容易处于竞态以致于出现死锁。 ZooKeeper 的目的是为了减轻分布式应用程序所承担的协调任务。

 

     ZooKeeper命名空间

 

     提供的命名空间与标准的文件系统很是类似。一个名称是由经过斜线分隔开的路径名序列所组成的。ZooKeeper中的每个节点是都经过路径来识别。获取下载地址   最主流的Java后台 SSM 框架 springmvc spring mybatis 项目

下图是Zookeeper中节点的数据模型，这种树形结构的命名空间操做方便且易于理解。

 

 

 

                                 图:ZooKeeper层次命名空间

 

 

         接着上图中,咱们须要了解一下ZooKeeper中的节点和临时节点

 

         ZooKeeper的节点是经过像树同样的结构来进行维护的，而且每个节点经过路径来标示以及访问。除此以外，每个节点还拥有自身的一些信息，包括：数据、数据长度、建立时间、修改时间等等。

 

          从这样一类既含有数据，又做为路径表标示的节点的特色中，能够看出，ZooKeeper的节点既能够被看作是一个文件，又能够被看作是一个目录，它同时具备两者的特色。为了简单咱们能够Znode来表示所讨论的ZooKeeper节点。

 

         具体地说，Znode维护着数据、ACL（access controllist，访问控制列表）、时间戳等交换版本号等数据结构，它经过对这些数据的管理来让缓存生效而且令协调更新。每当Znode中的数据更新后它所维护的版本号将增长，这很是相似于数据库中计数器时间戳的操做方式。

 

         另外Znode还具备原子性操做的特色：命名空间中，每个Znode的数据将被原子地读写。读操做将读取与Znode相关的全部数据，写操做将替换掉全部的数据。除此以外，每个节点都有一个访问控制列表，这个访问控制列表规定了用户操做的权限。

 

       ZooKeeper中一样存在临时节点。这些节点与session同时存在，当session生命周期结束，这些临时节点也将被删除。临时节点在某些场合也发挥着很是重要的做用。

 

         了解了Zookeeper的命名空间和节点以后咱们须要跟上一篇文章中提到的内部逻辑联系起来.在上篇介绍到的内部流程中,拿到这里看看Zookeeper是如何处理的,流程以下图:

 

 

 

 

   1  当服务提供者启动时,Zookeeper向/dubbo/com.foo.BarService/providers目录下写入本身的URL地址。

 

   2 当服务消费者启动时,这时候有两个动做:

订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。

并向/dubbo/com.foo.BarService/consumers目录下写入本身的URL地址。

 

  3当监控中心启动时,订阅/dubbo/com.foo.BarService目录下的全部提供者和消费者URL地址。

​