(一)zookeeper实战——初识zookeeper
前言
本节内容是zookeeper的开篇内容,主要介绍一下zookeeper的基本概念、基本特点、数据结构、工作原理等,便于我们对zookeeper有一个初步的了解。
正文
- zookeeper的特点
- zookeeper由一个领导者(Leader)和多个跟随者(Follower)组成
- zookeeper集群中只要有半数以上的节点存活,zookeeper集群就能正常提供服务
- zookeeper集群能够保证全局数据一致性,即每个server保存一份相同的数据副本,客户端无论连接到哪台服务器,数据都是一致的
- 更新请求顺序进行,来自同一个客户端的更新请求按照其发送顺序执行
- 数据更新的原子性,一次数据更新,要么成功,要么失败
- zookeeper的数据结构
- 整体上是一棵树,每个节点称作一个znode
- 每个znode存储1MB的数据
- 每个znode可以通过其节点路径唯一标识
- 应用场景
- 统一命名服务
- 统一配置管理
- 统一集群管理
- 服务动态上下线
- 软负载均衡
- zookeeper配置参数说明
- tickTime =2000:通信间隔的心跳数,Zookeeper服务器与客户端心跳时间,单位毫秒,每间隔tickTime时间就会发送一个心跳
- initLimit =10:LF初始通信时限,集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数(tickTime的数量),用它来限定集群中的Zookeeper服务器连接到Leader的时限。
- syncLimit =5:LF同步通信时限,集群中Leader与Follower之间的最大响应时间单位,假如响应超过syncLimit * tickTime,Leader认为Follwer死掉,从服务器列表中删除Follwer
- dataDir:数据文件目录+数据持久化路径
- clientPort =2181:客户端连接端口
- zookeeper的内部选举机制
- 半数机制,半数以上集群存活则集群可用。所以集群安装是奇数台服务器。
- 集群中只有一台leader服务器,其它都是跟随者Follow服务器,通过内部机制选举出leader服务器
- 优先选举自己,自己不符合再等待其它节点上线,选举其它节点为leader节点,直到其它节点达到半数以上,选举结束,该节点成为leader节点
- 节点类型
- 持久节点:服务器与客户端断开连接后,节点不删除
- 临时节点:服务器与客户端断开连接后,节点删除
- 持久化顺序节点:节点编号是有序的,单调递增,服务器与客户端断开连接后,节点不删除
- 临时顺序节点:节点编号是有序的,单调递增,服务器与客户端断开连接后,节点删除
- 监听器原理
- 创建一个main,再main线程中创建zookeeper客户端,创建俩个线程,一个线程负责网络连接通信,一个负责监听
- 通过通信线程将注册的监听事件发送给zookeeper
- zookeeper将监听事件加入到监听事件列表中
- zookeeper监听到数据或者路径发生变化,将这个消息发送给监听线程
- 监听线程内部调用process方法处理监听事件
- 写数据流程
- 客户端向服务端发送一个写请求
- 如果该服务端不是leader服务器,则会将写请求转发给leader,leader会将该次写请求广播给其他服务器,其它服务器写成功后会通知给leader服务器
- leader只要收到大多数节点数据写成功了,就认为数据写成功,并告知接收请求的服务器结果
- 服务器在通知客户端,写流程的结果
结语
本节内容到这里就结束了,我们下期见。。。。。。