Zookeeper服务端

目录

服务运行模式

集群中的机器数量

Session连接

Zookeeper的安装

Zookeeper的session状态流转

集群化部署

---

服务运行模式

可以是单体服务，也可以是集群服务。

单体服务只有一台服务器，没有备份，没有状态同步。

集群服务有多台服务器，避免单点故障导致的不可用问题，存在备份，存在状态同步。通常更倾向于集群模式。

集群中的机器数量

我们在搭建Zookeeper集群（其他集群也可以参考）时，该如何考虑服务节点的数量呢？这里的节点我们在机器的维度考虑。

一般采用半数可用的原则，即，如果有五个机器提供服务，那么至少要有三台可用，即容忍有2台机器同时down掉。在客户端的单次操作请求时，至少要完成三台机器上的数据持久化才能告知客户端操作成功。半数可用原则为高可用提供了基础。

同时，我们往往将服务节点数设置为奇数个，便于提高可用性。

Session连接

在客户端调用服务端时，先建立session，这个session的含义非同小可。

首先，临时节点会因为session的断开而消失（被删除）

其次，session代表的是一次TCP链接，通过链接传递数据。

再次，单个session执行的api操作是有序的。

Zookeeper的安装

前提：

已经安装java 1.6以上版本

1. 下载安装文件

下载链接https://zookeeper.apache.org/

2. 解压

tar -xvzf zookeeper-3.4.5.tar.gz

 

3. 重命名默认配置

mv conf/zoo_sample.cfg conf/zoo.cfg

 

4. 可以修改一下zoo.cfg中的数据存储位置配置

dataDir=/users/me/zookeeper

5. 启动服务端

bin/zkServer.sh start 

 上述语句默认后台启动，也可以使用下面的命令前台启动

bin/zkServer.sh start-foreground

6. 启动客户端

bin/zkCli.sh 

7. 查看节点

ls / 

8. 创建节点

create  node  data

 

 9. 删除节点

delete  node

 

10. 停止服务

bin.zkServer.sh  stop

 

Zookeeper的session状态流转

1：客户端初始化时，未连接->连接中

2：连接建立成功，连接中->已连接

3：当客户端丢失服务端的链接，或者持续一段时间没有接受到服务端的响应，已连接->连接中

2：当持续一段时间无法接受服务端的响应时，客户端开始尝试换个服务器重连，此时链接成功的话，连接中->已连接

4：连接超时，无法重连，连接中->关闭 

4/5：客户端可以主动关闭连接

在创建链接的时候，需要指定超时时间t，这个t代表从上一次接收到消息开始到断开连接的时间。

当到达1/3的t的时间还没有接收到服务端的响应时，客户端开始发送心跳包。

当到达2/3的t的时间还没有回应时，客户端开始选择换一个服务器重连。

同时，zookeeper通过zxid来保证更新的顺序，保证已经同步状态的服务器才能接受客户端的重连，而状态滞后的服务器是不能建立连接的。

 

集群化部署

我们可以在单个服务器上配置多个zookeeper实例，模拟集群化

1. 创建三个目录，z1，z2, z3，在三个目录下创建data目录，在data目录下创建myid文件

通过公共化配置服务，server.1   server.2   server.3表示三个节点，2222和2223分别用于通信和master选举，2181是客户端链接端口。

2. 给三个myid存储初识数据，表示自己的唯一编号：

 

3. 启动第一个节点：

这里的报错表示连接其他服务器失败，因为只启动了一个节点，所有失败是正常的

4.  启动第二个节点

 发现节点2被选举为master

 此时节点1的日志也体现了节点1变成了从节点

 

5. 客户端建立连接

 指定server来指定集群的服务器。

 我们发现连接到了节点2，实际上节点3并未启动，因此会发现偶现失败连接到3，重新自动连接到节点1或者节点2的情况。