目录

服务运行模式

集群中的机器数量

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的情况。