Zookeeper学习笔记(下)

这是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.html

zookeeper简介

 http://www.open-open.com/lib/view/open1415453633887.html

ZK的应用,可以再细化:

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

巴特西