zookeeper注册中心及集群

在dubbo微服务项目中，使用zookeeper作为注册中心，服务提供者注册服务到zookeeper中暴露服务，消费者去zookeeper中寻找使用服务。相当于微服务的中间站。

zookeeper是树形结构：

流程说明：

• 服务提供者启动时: 向 /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 的根节点，不配置将使用默认的根节点。
• 支持 * 号通配符 ，可订阅服务的所有分组和所有版本的提供者

zookeeper集群：

 ZooKeeper集群中的节点分为三种角色：Leader、Follower和Observer。通常来说，需要在集群中配置奇数个（2N+1）ZooKeeper服务，至少（N+1）个投票才能成功的执行写操作。（2n+1台机器，允许挂掉n台(zookeeper)）。

Zookeeper集群采用选举方式，一半以上选举出一个做为leader为客户端提供服务。所以需要2n+1个zookeeper服务器，在挂掉n个时仍能保证服务正常运行。故至少需要三台zookeeper服务器才能提供集群服务

角色介绍

Leader

在ZooKeeper集群中只有一个节点作为集群的领导者，由各Follower通过ZooKeeper Atomic Broadcast(ZAB)协议选举产生，主要负责接收和协调所有写请求，并把写入的信息同步到Follower和Observer。

Follower

Follower的功能有两个：

每个Follower都作为Leader的储备，当Leader故障时重新选举Leader，避免单点故障。处理读请求，并配合Leader一起进行写请求处理。Observer

Observer不参与选举和写请求的投票，只负责处理读请求、并向Leader转发写请求，避免系统处理能力浪费。

Client

ZooKeeper集群的客户端，对ZooKeeper集群进行读写操作。例如HBase可以作为ZooKeeper集群的客户端，利用ZooKeeper集群的仲裁功能，控制其HMaster的“Active”和“Standby”状态。

 

zookeeper配置:每个zookeeper相同配置如下：

配置zookeeper/conf/zoo.cfg文件，红色部分为配置内容

下方server.x=ip地址----部分为每个参与集群的zookeeper地址的配置，x为数字。

此编号在每个zookeeper配置的dataDir目录下myid文件中指定。文件名为myid，无扩展名，文件内容为自定义的此zookeeper编号，不能重复。

如：

x是一个数字，表示这个是第几号服务器；“=”号后面是对应几号服务器的IP地址，第一个端口2888是集群中从服务器（follower）连接到主服务器（leader）的端口，也就是作为leader时使用的，其他从服务器都连接到主服务器的这个端口；第二个端口3888表示的是进行leader选举时使用的端口。

1. 客户端访问zookeeper集群配置：

 

参考文档：

http://dubbo.apache.org/zh-cn/docs/user/references/registry/zookeeper.html

https://baijiahao.baidu.com/s?id=1649612643805961509&wfr=spider&for=pc