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