目录
服务运行模式
集群中的机器数量
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的情况。