首页  思维导图  详情



 



Zookeeper

2021-04-12 08:51:54   0  举报





仅支持查看

AI智能生成

zk笔记

zookeeper

分布式

zookeeper架构图

ZooKeeper流程图

模板推荐

作者其他创作

大纲/内容

zk入门

基础知识

zk的发展

出现背景

分布式单点故障

传统做法是使用备用节点向master节点定期发送ping包，master回复ack， 如果master回复时出现网络故障，就会启动一个新的master,此时就存在 两个主节点，导致服务混乱。

zk的介绍

Zookeeper 是一个开源的分布式协调服务框架 ，主要用来解决分布式集群中应用系统的 一致性问题和数据管理问题。

特点

本质类似分布式文件系统，适合存小文件

zk中存储的是znode

有路径

可携带数据

znode必须小于1M

核心

文件系统的数据结构

采用树状结构

/app1

/app2

事件监听/通知机制

客户端会对某个节点建立一个watcher事件，当该节点发生变化时，这些客户端会 收到zk的通知，然后客户端可以根据节点变化来做出业务上的改变等

应用场景

数据发布/订阅（注册中心）

一对多，多个订阅者监听一个主题对象，主题对象在自身状态发生变化时会通知所有的订阅者对象

可以使得发布方和订阅方独立封装、独立改变。适合一个对象改变时需要改变其它对象，但不知道有多少个其它对象情况

典型应用：

配置管理

如果集群中机器拥有相同的配置，且需要动态修改，我们可以使用发布/订阅模式把 配置做统一集中管理，让这些机器各自订阅配置信息的改变，当配置发生改变时， 这些机器就可以得到通知并更新为最新的配置

服务发现、注册

对集群中的服务上下线做统一管理。每个工作服务器都可以作为数据的发布方向 集群注册自己的基本信息，而让某些监控服务器作为订阅方，订阅工作服务器的 基本信息，当工作服务器的基本信息发生改变如上下线、服务器角色或服务范围 变更，监控服务器可以得到通知并响应这些变化。

两种设计模式

推模式

服务端主动将数据更新发送给所有订阅的客户端称为推模式。

拉模式

客户端主动请求获取最新数据称为拉模式。

Zookeeper采用了推拉相结合的模式。客户端向服务端注册自己需要关注的节点，一旦该节点 数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知 后，主动到服务端获取最新的数据。

命名服务

命名服务功能主要是根据指定名字来获取资源或服务的地址，提供者等信息，利用其znode的特点和watcher机制，将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息，我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。

作用

负载均衡

轮询服务注册表，尽可能将服务请求均匀分配到所有注册有效的服务器上。

健康检查

动态维护服务地址注册表，利用心跳请求实时监控注册服务状态，删除无效服务节点，维护有效的地址注册表。

调用监控

通过统计注册表各个子节点被访问次数来监控服务调用情况。

动态路由

可以通过配置注册表参数，在不修改服务代码的情况下，动态指定服务访问的机器。

动态配置

注册表的子节点可以作为单服务器的配置中心，可以直接修改节点配置而不是修改代码的方式，动态修改服务运行的部分参数。

分布式协调和通知

Zookeeper中特有的Watcher注册于异步通知机制，能够很好地实现分布式环境下不同机器，甚至不同系统之间的协调与通知，从而实现对数据变更的实时处理。通常做法，所有客户端对zk同一节点注册Watcher事件，监听节点变化

系统机器间通信

心跳检测

不同机器间需要检测到彼此是否在正常运行，可以使用Zookeeper实现机器间的心跳检测。基于其临时节点特性（临时节点的生存周期是客户端会话，客户端若当即后，其临时节点自然不再存在），可以让不同机器都在Zookeeper的一个指定节点下创建临时子节点，不同的机器之间可以根据这个临时子节点来判断对应的客户端机器是否存活。通过Zookeeper可以大大减少系统耦合。

工作进度汇报

通常任务被分发到不同机器后，需要实时地将自己的任务执行进度汇报给分发系统，可以在Zookeeper上选择一个节点，每个任务客户端都在这个节点下面创建临时子节点，这样不仅可以判断机器是否存活，同时各个机器可以将自己的任务执行进度写到该临时节点中去，以便中心系统能够实时获取任务的执行进度。

系统调度

Zookeeper能够实现如下系统调度模式： 分布式系统由控制台和一些客户端系统两部分构成，控制台的职责就是需要将一些指令信息发送给所有的客户端，以控制他们进行相应的业务逻辑，后台管理人员在控制台上做一些操作，实际上就是修改Zookeeper上某些节点的数据，Zookeeper可以把数据变更以时间通知的形式发送给订阅客户端。

分布式锁

分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，可以保证不同系统访问一个或一组资源时的一致性

排它锁(又称为写锁或独占锁)

① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建 临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成 功的客户端需要注册/exclusive_lock节点监听。

② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此 时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获 取。

共享锁(又称为读锁)

分布式队列

用来实现跨进程、跨主机、跨网络的数据共享和数据传递

集群管理

集群

集群角色

角色

集群搭建

zoo.cfg

dataDir=/export/servers/zookeeper-3.4.9/zkdatas # 保留多少个快照 autopurge.snapRetainCount=3 # 日志多少小时清理一次 autopurge.purgeInterval=1 # 集群中服务器地址 server.1=node01:2888:3888 server.2=node02:2888:3888 server.3=node03:2888:3888

创建myid

echo 1 dataDir1/myid echo 2 dataDir2/myid echo 3 dataDir3/myid

查看状态

sh zkServer.sh status

echo stat | nc 127.0.0.1 2181

netstat -nltp | grep 2181

ZAB原子广播协议 （fast paxos算法）

恢复模式（选举）

leader选举

选举机制

LeaderElection

AuthFastLeaderElection

FastLeaderElection （最新默认）

Server状态（选举状态）

LOOKING，竞选状态。

FOLLOWING，随从状态，同步leader状态，参与投票。

OBSERVING，观察状态,同步leader状态，不参与投票。

LEADING，领导者状态。

启动选举

1.每个Server选自己为leader，广播信息（myid：服务器编号,zxid：事务的id,值越大数据越新）

2.接收各服务器投票

3.处理投票

是否是同轮投票

投票是否过时

优先检查ZXID，如果ZXID相同，那么就比较myid。（保留更新大数值）

4.统计投票

是否有过半机器接收到相同的投票信息

5.改变服务器状态

运行时选举

流程和启动选举基本一致（对外暂停服务）

选举图解

参考资料： 上图中过半：表示服务器参与投票的数量

广播模式（同步）

写数据流程

client向zk集群的server1发送一个写请求， 如果server1不是leader，需要把写请求转发给leader, leader将写请求广播给各个server,写成功后会通知leader。 当leader收到过半的server写成功了就会通知client写操作完成

过半机制

保证一半以上的server同意这个proposal(建议)才会成功， 保证了Zookeeperk集群的数据一致性

shell客户端操作

bin/zkCli.sh -server node01:2181

列出Path下的所有Znode ls / 创建永久节点 create /hello world 创建临时节点： create -e /abc 123 创建永久序列化节点： create -s /zhangsan boy 创建临时序列化节点： create -e -s /lisi boy 修改节点数据 set /hello zookeeper 删除节点, 如果要删除的节点有子Znode则无法删除 delete /hello 删除节点, 如果有子Znode则递归删除 rmr /abc 列出历史记录 histroy

znode

构成部分

stat

状态, Znode的权限信息, 版本等

data

数据, 每个Znode都是可以携带数据的, 无论是否有子节点

children

子节点列表

类型

持久性

持久

临时

客户端断开时, 删除所有持有的Znode, 临时Znode不允许有子Znode

顺序性

有序

创建的Znode有先后顺序, 顺序就是在后面追加一个序列号, 序列号是由父节点管理的自增

无序

属性

dataVersion 数据版本, 每次当 Znode 中的数据发生变化的时候, dataVersion都会自增

cversion 节点版本, 每次当 Znode 的节点发生变化的时候, cversion 都会自增

aclVersion ACL(Access Control List) 的版本号, 当 Znode 的权限信息发生变化的时候aclVersion会自增

zxid 事务ID

ctime 创建时间

mtime 最近一次更新的时间

ephemeralOwner 如果 Znode 为临时节点, ephemeralOwner 表示与该节点关联的 SessionId

Watch

命令：get /path watch

特点：Watch是一次性触发

事件封装: Watcher

包括三个内容 keeperState, eventType, path

面试问题

zookeeper是强一致性吗？

zookeeper使用的ZAB协议进行主从数据同步，ZAB协议认为只要是过半数节点写入成为，数据就算写成功了，然后会告诉客户端A数据写入成功，如果这个时候客户端B恰好访问到还没同步最新数据的zookeeper节点，那么读到的数据就是不一致性的，因此zookeeper无法保证写数据的强一致性，只能保证最终一致性，而且可以保证同一客户端的顺序一致性

zk为什么要有主节点？

在分布式环境中，有些业务逻辑只需要集群中的某一台机器执行， 其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能

zk集群为什么是奇数台？

防止由脑裂造成的集群不可用

容灾能力相同的情况下，奇数更节省资源

如何保证事务的顺序一致性？

采用了全局递增的事务ID（zxid）来标识

zk服务宕机对dubbo服务有没有影响？

没有影响，本地有缓存列表

java API

Maven依赖

<dependencies> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>2.12.0</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>2.12.0</version> </dependency> </dependencies>

创建永久节点

创建临时节点

修改节点数据

节点数据查询

节点watch机制