zookeeper注册中心的对比是什么样的

这篇文章将为大家详细讲解有关 zookeeper注册中心的对比是什么样的,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。

成都创新互联是一家集网站建设,铁东企业网站建设,铁东品牌网站建设,网站定制,铁东网站建设报价,网络营销,网络优化,铁东网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。

最近在学zookeeper 注册中⼼   找到一份比较详细的注册中心对比 

简单记一下:

1        ZooKeeper

Java开发的一个服务管理应用. 是Hadoop项目的子项目. 动物园管理员. 是一个其他应用的管理应用, 负责协调,调度,管理,配置等功能.

支持断点恢复, 会话恢复, 配置服务项, 配置消费项, 通配信息配置等.

ZooKeeper是一个Java开发的应用. 运行环境只需要JDK和JVM.

2        Multicast

广播式注册中心. 只要Provider和Consumer在同一个网段中即可实现服务的发布和订阅.

局限性 : 只适合小型架构或开发测试使用. 因为可能造成广播风暴. 网段内超过5台物理机同时发布服务, 可能造成数据通讯问题, 无法实现快速的服务订阅和应用.

3        redis

KV服务器注册中心. KV服务器, 高速缓存服务器. 内存型数据库. NoSql数据库. 后期有课程详细讲解.

类似ZooKeeper注册中心. Provider发布服务到Redis, Consumer从Redis中订阅服务.

优势: 高效.

缺陷: 数据描述相对简单, 使用频率相对较少. 没有经过大量测试, 稳定性不确定.

4        Simple

就是Dubbo自定义的一个注册中心. 减少三方依赖. 让代码依赖性降低, 耦合性降低.

只适合小型应用和开发测试.

以下引用详细解释

Multicast 注册中⼼
Multicast 注册中⼼不需要启动任何中⼼节点,只要⼴播地址⼀样,就可以互相发现。
1. 提供⽅启动时⼴播⾃⼰的地址
2. 消费⽅启动时⼴播订阅请求
3. 提供⽅收到订阅请求时,单播⾃⼰的地址给订阅者,如果设置了  unicast=false  ,则⼴播给订阅者
4. 消费⽅收到提供⽅地址时,连接该地址进⾏ RPC 调⽤。
组播受⽹络结构限制,只适合⼩规模应⽤或开发阶段使⽤。组播地址段: 224.0.0.0 - 239.255.255.255
配置



为了减少⼴播量,Dubbo 缺省使⽤单播发送提供者地址信息给消费者,如果⼀个机器上同时启了多个消费者进程,消费
者需声明  unicast=false  ,否则只会有⼀个消费者能收到消息:






zookeeper 注册中⼼
Zookeeper 是 Apacahe Hadoop 的⼦项⽬,是⼀个树型的⽬录服务,⽀持变更推送,适合作为 Dubbo 服务的注册中
⼼,⼯业强度较⾼,可⽤于⽣产环境,并推荐使⽤ 。
流程说明:
服务提供者启动时: 向  /dubbo/com.foo.BarService/providers  ⽬录下写⼊⾃⼰的 URL 地址
服务消费者启动时: 订阅  /dubbo/com.foo.BarService/providers  ⽬录下的提供者 URL 地址。并向
/dubbo/com.foo.BarService/consumers  ⽬录下写⼊⾃⼰的 URL 地址
监控中⼼启动时: 订阅  /dubbo/com.foo.BarService  ⽬录下的所有提供者和消费者 URL 地址。
⽀持以下功能:
当提供者出现断电等异常停机时,注册中⼼能⾃动删除提供者信息
当注册中⼼重启时,能⾃动恢复注册数据,以及订阅请求
当会话过期时,能⾃动恢复注册数据,以及订阅请求
当设置    时,记录失败注册和订阅请求,后台定时重试
可通过    设置 zookeeper 登录信息
可通过    设置 zookeeper 的根节点,不设置将使⽤⽆根树
⽀持  *  号通配符    ,可订阅服务的所有分组和所有版本的提供者
使⽤
在 provider 和 consumer 中增加 zookeeper 客户端 jar 包依赖:

org.apache.zookeeper
zookeeper
3.3.3

或直接下载。
Dubbo ⽀持 zkclient 和 curator 两种 Zookeeper 客户端实现:
 
使⽤ zkclient 客户端
从  2.2.0  版本开始缺省为 zkclient 实现,以提升 zookeeper 客户端的健状性。zkclient 是 Datameer 开源的⼀个
Zookeeper 客户端实现。
缺省配置:

或:
dubbo.registry.client=zkclient
或:
zookeeper://10.20.153.10:2181?client=zkclient
需依赖或直接下载:

com.github.sgroschupf
zkclient
0.1

使⽤ curator 客户端
从  2.3.0  版本开始⽀持可选 curator 实现。Curator 是 Netflix 开源的⼀个 Zookeeper 客户端实现。
如果需要改为 curator 实现,请配置:

或:
dubbo.registry.client=curator
或:
zookeeper://10.20.153.10:2181?client=curator
需依赖或直接下载:

com.netflix.curator
curator-framework
1.1.10

Zookeeper 单机配置:


或:

Zookeeper 集群配置:

或:

同⼀ Zookeeper,分成多组注册中⼼:


zookeeper 安装
安装⽅式参⻅: Zookeeper安装⼿册,只需搭⼀个原⽣的 Zookeeper 服务器,并将 Quick Start 中 Provider 和
Consumer ⾥的  conf/dubbo.properties  中的  dubbo.registry.addrss  的值改为  zookeeper://127.0.0.1:2181  即可使
⽤。
可靠性声明
阿⾥内部并没有采⽤ Zookeeper 做为注册中⼼,⽽是使⽤⾃⼰实现的基于数据库的注册中⼼,即:Zookeeper 注册中
⼼并没有在阿⾥内部⻓时间运⾏的可靠性保障,此 Zookeeper 桥接实现只为开源版本提供,其可靠性依赖于
Zookeeper 本身的可靠性。
兼容性声明
因  2.0.8  最初设计的 zookeeper 存储结构不能扩充不同类型的数据, 2.0.9  版本做了调整,所以不兼容,需全部改
⽤  2.0.9  版本才⾏,以后的版本会保持兼容  2.0.9  。 2.2.0  版本改为基于 zkclient 实现,需增加 zkclient 的依赖
包, 2.3.0  版本增加了基于 curator 的实现,作为可选实现策略。
. 建议使⽤  2.3.3  以上版本的 zookeeper 注册中⼼客户端 ↩

Redis 注册中⼼
基于 Redis 实现的注册中⼼ 。
使⽤ Redis 的 Key/Map 结构存储数据结构:
主 Key 为服务名和类型
Map 中的 Key 为 URL 地址
Map 中的 Value 为过期时间,⽤于判断脏数据,脏数据由监控中⼼删除
使⽤ Redis 的 Publish/Subscribe 事件通知数据变更:
通过事件的值区分事件类型: register  ,  unregister  ,  subscribe  ,  unsubscribe
普通消费者直接订阅指定服务提供者的 Key,只会收到指定服务的  register  ,  unregister  事件
监控中⼼通过  psubscribe  功能订阅  /dubbo/*  ,会收到所有服务的所有变更事件
调⽤过程:
1. 服务提供⽅启动时,向  Key:/dubbo/com.foo.BarService/providers  下,添加当前提供者的地址
2. 并向  Channel:/dubbo/com.foo.BarService/providers  发送  register  事件
3. 服务消费⽅启动时,从  Channel:/dubbo/com.foo.BarService/providers  订阅  register  和  unregister  事件
4. 并向  Key:/dubbo/com.foo.BarService/providers  下,添加当前消费者的地址
5. 服务消费⽅收到  register  和  unregister  事件后,从  Key:/dubbo/com.foo.BarService/providers  下获取提供者地
址列表
6. 服务监控中⼼启动时,从  Channel:/dubbo/*  订阅  register  和  unregister  ,以及  subscribe  和 unsubsribe  事件
7. 服务监控中⼼收到  register  和  unregister  事件后,从  Key:/dubbo/com.foo.BarService/providers  下获取提供者
地址列表
8. 服务监控中⼼收到  subscribe  和  unsubsribe  事件后,从  Key:/dubbo/com.foo.BarService/consumers  下获取消费
者地址列表
配置







选项
可通过    设置 redis 中 key 的前缀,缺省为  dubbo  。
可通过    设置 redis 集群策略,缺省为  failover  :
failover  : 只写⼊和读取任意⼀台,失败时重试另⼀台,需要服务器端⾃⾏配置数据同步
replicate  : 在客户端同时写⼊所有服务器,只读取单台,服务器端不需要同步,注册中⼼集群增⼤,性能压
⼒也会更⼤
可靠性声明
阿⾥内部并没有采⽤ Redis 做为注册中⼼,⽽是使⽤⾃⼰实现的基于数据库的注册中⼼,即:Redis 注册中⼼并没有在
阿⾥内部⻓时间运⾏的可靠性保障,此 Redis 桥接实现只为开源版本提供,其可靠性依赖于 Redis 本身的可靠性。
安装
安装⽅式参⻅: Redis安装⼿册,只需搭⼀个原⽣的 Redis 服务器,并将 Quick Start 中 Provider 和 Consumer ⾥的
conf/dubbo.properties  中的  dubbo.registry.addrss  的值改为  redis://127.0.0.1:6379  即可使⽤。
. Redis 是⼀个⾼效的 KV 存储服务器 ↩
. 从  2.1.0  版本开始⽀持 ↩
. Redis 过期数据通过⼼跳的⽅式检测脏数据,服务器时间必须同步,并且对服务器有⼀定压⼒,否则过期检测
会不准确 ↩


Simple 注册中⼼
Simple 注册中⼼本身就是⼀个普通的 Dubbo 服务,可以减少第三⽅依赖,使整体通讯⽅式⼀致。
配置
将 Simple 注册中⼼暴露成 Dubbo 服务:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans
/spring-beans-2.5.xsdhttp://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xs
d">





ondisconnect="disconnect" callbacks="1000">






引⽤ Simple Registry 服务:

或者:

或者:

适⽤性说明
此  SimpleRegistryService  只是简单实现,不⽀持集群,可作为⾃定义注册中⼼的参考,但不适合直接⽤于⽣产环境。
 

Telnet 命令参考⼿册
从  2.0.5  版本开始,dubbo 开始⽀持通过 telnet 命令来镜像服务治理。
使⽤
telnet localhost 20880
或者:
echo status | nc -i 1 localhost 20880
status命令所检查的资源也可以扩展,参⻅:扩展参考⼿册。
命令
以下展示了 dubbo 内建的 telnet 命令的说明和⽤法,此外,telnet 命令还⽀持⽤户⾃⾏扩展,参⻅:Telnet 命令扩展。
ls
1.  ls  : 显示服务列表
2.  ls -l  : 显示服务详细信息列表
3.  ls XxxService  : 显示服务的⽅法列表
4.  ls -l XxxService  : 显示服务的⽅法详细信息列表
ps
1.  ps  : 显示服务端⼝列表
2.  ps -l  : 显示服务地址列表
3.  ps 20880  : 显示端⼝上的连接信息
4.  ps -l 20880  : 显示端⼝上的连接详细信息
cd
1.  cd XxxService  : 改变缺省服务,当设置了缺省服务,凡是需要输⼊服务名作为参数的命令,都可以省略服务参数
2.  cd /  : 取消缺省服务
pwd
pwd  : 显示当前缺省服务
trace
1.  trace XxxService  : 跟踪 1 次服务任意⽅法的调⽤情况
2.  trace XxxService 10  : 跟踪 10 次服务任意⽅法的调⽤情况
3.  trace XxxService xxxMethod  : 跟踪 1 次服务⽅法的调⽤情况
4.  trace XxxService xxxMethod 10  : 跟踪 10 次服务⽅法的调⽤情况
11 telnet 命令参考⼿册
145
count
1.  count XxxService  : 统计 1 次服务任意⽅法的调⽤情况
2.  count XxxService 10  : 统计 10 次服务任意⽅法的调⽤情况
3.  count XxxService xxxMethod  : 统计 1 次服务⽅法的调⽤情况
4.  count XxxService xxxMethod 10  : 统计 10 次服务⽅法的调⽤情况
invoke
1.  invoke XxxService.xxxMethod({"prop": "value"})  : 调⽤服务的⽅法
2.  invoke xxxMethod({"prop": "value"})  : 调⽤服务的⽅法(⾃动查找包含此⽅法的服务)
status
1.  status  : 显示汇总状态,该状态将汇总所有资源的状态,当全部 OK 时则显示 OK,只要有⼀个 ERROR 则显示
ERROR,只要有⼀个 WARN 则显示 WARN
2.  status -l  : 显示状态列表
log
1.  log debug  : 修改 dubbo logger 的⽇志级别
2.  log 100  : 查看 file logger 的最后 100 字符的⽇志
help
1.  help  : 显示 telnet 命帮助信息
2.  help xxx  : 显示xxx命令的详细帮助信息
clear
1.  clear  : 清除屏幕上的内容
2.  clear 100  : 清除屏幕上的指定⾏数的内容
exit
exit  : 退出当前 telnet 命令⾏
.  2.0.6  以上版本⽀持 ↩

关于 zookeeper注册中心的对比是什么样的就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。


本文标题:zookeeper注册中心的对比是什么样的
文章位置:http://cdiso.cn/article/iecoij.html

其他资讯