这是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读取数据的性能测试
-