这是ZK学习笔记的下篇, 主要希望可以分享一些 ZK 的应用以及其应用原理
我本人的学习告一段落, 不过还遗留了一些ZK相关的任务开发和性能测试的任务, 留待以后完成之后再通过其他文章来进行分享了
ZK应用场景:
1. 一个服务多台机器, 快速修改配置
2. 服务的消费者如何动态知道服务有多少个提供者
3. 生产系统部署多少个业务系统以及每个业务系统提供多少接口
ZK案例-配置管理:
服务端:
每次启动, 会将提供的request都注册到 ZK 中
客户端:
启动时读取 ZK 中所有的 service 提供者,并且组装出可用的 service
优化:
服务器启动注册本地IP,使用临时节点的方式, 一旦连接失效, 客户端可以收到节点消失的通知
ZK案例-分布式锁
排他锁:只能一个线程获取.其他线程需要等待
ZK实现:
获得锁:构建目录, 叶子节点创建成功则认为获取锁
排他锁实现的核心思想:
通过只有一个线程可以创建一个同样的叶子节点进行实现
线程可以成功创建叶子节点即认为获取锁成功,可以执行业务代码
若线程无法成功创建叶子节点,则认为获取锁失败, 需要进入等待, 多个其他线程创建失败则多个线程进入等待
线程执行完业务代码会删除叶子节点,其他线程获取到删除通知,会释放线程,再次尝试获取锁
共享锁:可以多个读操作同时获取锁进行处理,一旦出现写锁,其他所有操作需要等待写入完成之后重新获取锁
ZK实现:
读时可以允许其他线程进行读, 写是其他线程不可进行其他操作
共享锁实现的核心思想:
每个节点都向ZK写入节点信息(Seq节点)
通过排名比较是否自己在第一个来进行判断是否获取到锁
非第一个,则在本身和前面都是读锁的情况下才可以继续,否则获取失败,进入等待
性能如何(待测试...)?
在连续不断有请求到达时,最大TPS有多少, 区分同时有 10个线程竞争和同时有 100个线程竞争的时候
ZK的使用和运维
ZK 配置说明:
-
基于log4j的日志配置:
运行命令行增加: ZOO_LOG_DIR
-
zoo.conf
dataLogDir : 事务日志文件存储目录, 高并发下, 和 dataDir 配置在不同磁盘上, 提高 IO snapCount : 两次事务日志的记录数量 preAllocSize : 默认64MB, 与 snapCount相关, minSessionTimeout , maxSessionTimeout : 2倍和20倍 ticktime maxClientCnxns: socket层限制客户端和单台服务器的并发连接数, 只控制单台机器,不能控制总连接 Jute.maxbuffer:配置单个节点最大数据大小, 默认10MB, 需要客户端和服务端同时配置生效 Autopurge.snapRetainCount: 自动清理快照和事务日志需要保留文件数 Autopurge.purgeInterval:清理的周期 fsync.warningthresholdms:事务日志刷新到磁盘的阈值, 默认1000ms , fsync超过此时间会报警 forceSync : 日志提交时是否强制刷磁盘, 默认true, 可以false -
四字命令:
通过 telnet ip port 进入 , 打印命令
通过 nc 进入: echo 命令 |nc localhost port
conf : 查看配置 cons : 输出当前客户端所有连接的详细信息 queued : 待处理的请求 recved : 接受到的 sent : 已处理的 sid lop : 最近操作 crst : 重置客户端连接统计信息 dump : 当前集群所有会话信息, 包括id, 临时节点, 会话超时时间(leader节点) envi : 运行时当前环境信息 ruok : 输出zk服务器运行是否正常 stat : 服务端运行状况, zk服务版本, 延迟, 节点信息等 srvr : 类似 stat , 无会话信息 srst : 重置服务端统计信息 wchs : 输出服务器管理的 watcher 的概要信息, zk构造器创建的 watcher 不会被计入统计中 wchc : 管理的 watcher 的详细信息, 以 session 为视角 wchp : 以node为视角 mntr : 比 stat 更详细, 包括请求的延迟情况, 服务区内存大小, 集群同步等... -
性能优化:
JVM优化 IO优化 加大 linux系统的文件句柄数和用户线程数, linux 通过 ulimit 查看配置 业务并发高: 客户创建多个客户端连接, 用于不同的业务 减少资源消耗, 比如watcher的数量 提高带宽 -
扩容:
停机:直接增加节点 不停机: 新增节点: id需要比集群更大 新节点启动, 加入集群且同步数据 mntr查看新的节点数据成功同步后再执行 依次id从小到大,关闭zk实例,修改配置,启动实例 -
监控:
zookeeper的事务日志 磁盘IO 日志清理:建议定期清理事务日志和快照文件 连接数,避免过多 watchers 数量 ZK通知延时是否过大
ZK运维系统
Taokeeper:
功能:
CPU
ZK日志目录磁盘空间监控
单机连接数
单机Watcher数量
节点健康状态
少量统计报表
不足:
目录查看
网络流量
磁盘IO监控
安装:
源码安装:
包安装:
初始化脚本:4张表sql
安装步骤:
1. 修改机器,增加host
zk1node
zk2node
zk3node
个人意见: 无法达到生产使用的标准, 建议自行开发相应的监控系统, 或者运维人员通过四字命令手工监控
====自己总结=
-
一些资料
Zookeeper 学习
http://www.open-open.com/lib/view/open1415453633887.htmlzookeeper简介
http://www.open-open.com/lib/view/open1415453633887.htmlZK的应用,可以再细化:
http://blog.csdn.net/xinguan1267/article/details/38422149 http://cailin.iteye.com/blog/2014486/ (原理) -
心得
Zookeeper 的使用场景
Zookeeper完全可以解决我们的问题，分布式计算中的协调员，观察者，分布式锁 都可以作为zookeeper的关键词 在系统中利用Zookeeper来处理事件通知,队列,优先队列,锁,共享锁等功能，利用这些特色在分布式计算中发挥重要的作用。 Zookeeper 可以做配置的动态更新（通知机制） 配置管理 & 集群服务管理 所有节点登录后, 自行获取配置(公共的,特有的(通过serviceId标示)) 一般节点启动后负责在 某 path 中写入自身的service等标志, 如果已有则不再启动 管理节点启动后负责获取所有其他节点写入的一些数据, 来确定有多少其他节点正在工作一些疑问:
是否可以用于进行业务监控和系统监控 ? 数据是否可以序列处理? 是否有乱序 ? 写入 ZK 的效率如何 ? 一个 ZK集群, 单个client 最快写入效率?20个节点,最快写入效率如何? 如果一个节点的数据更新了, client端获取到watcher 事件, 但是还未处理完, 节点数据又更新了, 是否可能发生? 应该如何处理呢? server 端直接关闭, 会有何情况 ? 会导致连接上的客户端, 不断重试连接; 如果client 进行连接时, server 还未ready, 则会一直重试, 一旦 server ok ,则连接会成功 集群如果对应的 myid 不在, 会报错, zoo.cfg 读取失败 -
Todo :
-
ZK 源码查看
服务端的启动 服务端的整体结构 客户端的连接 服务端接收到各类事件的处理 事务日志的写入 快照的写入 -
ZK 的应用开发
1) 设想 ET, 将配置文件存在ZK中,启动时读取,且响应更新 ; 以API jar 的方式提供, 可以用于各个项目中获取 2) ZK 节点数据界面可视化开发 3) 监控工具打造:应用通过ZK将数据传入,监控工具从ZK中获取各个更新数据 -
Zookeeper 的性能压力测试
1) 单个client, 针对单个节点的连续写入能力,测试写入性能, 另外配合一个client注册watcher, 看是否可以连续获取到更新的数据 2) 单个client, 针对打个节点不断写入子节点,测试写入性能, 另外注册 watcher , 看是否可以获取到更新的事件 3) 使用场景有些类似于 MQ 的使用, 对于ZK读取数据的性能测试
-