zk了解
分布式程序服务之间需要相互调用,调用其它服务则需要知道其它服务的相关信息,如果在每个服务上都存储其它服务的相关信息,效率很低,且工作量大,不好维护,这时就需要一个专门的服务来维护这么服务的数据信息,需要获取其它服务的时候就直接到这里来拿,zk就是来管理这些服务的数据信息的,即也叫分布式应用程序的协调服务。
zk既然要对数据进行管理,则需要提供对数据的基本操作,增删改查等相关命令操作是肯定要有的,所以zk提供了一套指令和api来对数据进行管理,以及对操作的监控。
除了对数据对基本操作和监控之外,自身也要保证可靠性和稳定性,不然随时容易挂,找你拿个数据半天才给我,黄花菜都凉了,还不如不用这东西,还给其它服务添麻烦。
总结:zk是一个分布式应用程序的协调服务,而且高可靠,高性能。数据存储的目的是为了帮助协调。
zk核心概念
1.session会话:连接分配会话id,心跳保持会话,会话中的请求按照FIFO顺序执行。
2.数据模型znode
层次名称空间:和文件系统类似。
znode节点:
要求:命名规范,名称唯一。
类型:持久,顺序、临时(会话断开则会删除)、临时顺序。
数据构成:上限1M、元数据stat结构。
3.watch监听机制:
datawatch:数据节点的变化
childwatch:子节点的变化
重要特性:一次性,持续监听需要持续性设置。
有序性:先通知,后得到结果。
注意事项:由于一次性,所以想监听以后的变化,得继续设置watch,还会有延迟。
zookeeper中的时间:zk很重要的特性,因为所有的操作都是有序的,则涉及到时间。
zk特性和设计目标
设计目标:简单、可靠(先写日志,后添加数据)、快速(在内存中)。
zk特性:
说明:zk的这种数据结构和watch机制很适合分布式的服务协调。
zk典型应用场景
- 数据发布和订阅(配置中心)
实现原理:znode存储数据(一个配置项一个znode或一个配置文件一个znode),Watch监听数据变化实时获取最新的配置信息。 - 命名服务
概念:即服务的调用地址,动态的获取服务的调用地址。
example:将某个服务地址放到znode中,其它服务watch节点变化,可以得到最新的调用地址。
貌似也是使用的存储监听机制。 - Master选举
实现原理:利用临时节点特性,挂了之后会被删除,监听临时节点的watch,利用原子性创建节点得到leader,没有创建成功的则获取节点数据就知道谁是leader了。 - 集群管理
- 分布式队列
实现原理:利用节点的顺序性特性,实现先进先出,即创建顺序节点。出队就是移除最小号的节点。 - 分布式锁
原理1:利创建临时节点(意外情况,断开连接则删除节点),创建成功则获取锁,删除节点释放锁。节点不重名+watch。
缺点:惊群效应。适用于小并发,过大并发量会对服务器造成较大冲击。
原理2:利用临时顺序节点特性。
zk集群
-
zk集群特点
保证可靠的zk服务、大多数准备好了就可以使用了、最好使用奇数个服务器、单独机器部署。 -
zk集群监控和管理
方式:四字监控命令、jmx,详情可在官网查看。 -
zk集群原理
核心原理-ZAB协议:
1.概念:原子广播协议,是专为zk设计的数据性一致的协议。主要为了保证zk集群数据交互的一致性。
2.消息的交互过程图解:
3.ZAB协议部分内容
说明:协议部分内容主要应对服务崩溃的问题。leader挂了,和从节点失去了联系,就会进入崩溃恢复模式,这种模式下整个集群无法对外提供服务,丧失可用性。
4.ZAB协议处理崩溃恢复
1.leader选举
leader选举的实现:
- 成为leader的要求:最高的zxid和过半数节点同意,自己也算半数节点中的一个。
- 内置实现的选举算法:LeaderElection、FastLeaderElection(默认)、AutoFastLeaderElection
- 选举算法描述
- 选举发送的消息内容。服务太多不需要每个都去参与选举,比较耗时,挑几个就行了,其它的服务设置成观察状态,同步数据就可以了。
2.数据同步 说明:Leader把比Follower大的提案数据以队列的形式给Follower,然后Follower操作完成后就可以对外提供服务了。