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 配置说明:

1. 基于log4j的日志配置:

   运行命令行增加: ZOO_LOG_DIR

2. 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
   

3. 四字命令:

   通过 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 更详细, 包括请求的延迟情况, 服务区内存大小, 集群同步等...
   

4. 性能优化:

    JVM优化
    IO优化
    加大 linux系统的文件句柄数和用户线程数, linux 通过 ulimit 查看配置
    业务并发高: 客户创建多个客户端连接, 用于不同的业务
    减少资源消耗, 比如watcher的数量
    提高带宽
   

5. 扩容:

    停机:直接增加节点
    不停机:
    	新增节点: id需要比集群更大
    	新节点启动, 加入集群且同步数据
    	mntr查看新的节点数据成功同步后再执行
    	依次id从小到大,关闭zk实例,修改配置,启动实例
   

6. 监控:

    zookeeper的事务日志
    	磁盘IO
    	日志清理:建议定期清理事务日志和快照文件
    连接数,避免过多
    watchers 数量
    ZK通知延时是否过大
   

ZK运维系统

Taokeeper:

功能:
	CPU
	ZK日志目录磁盘空间监控
	单机连接数
	单机Watcher数量
	节点健康状态
	少量统计报表
不足:
	目录查看
	网络流量
	磁盘IO监控
安装:
	源码安装:
	包安装:
		初始化脚本:4张表sql

安装步骤:
	1. 修改机器,增加host
		zk1node
		zk2node
		zk3node

个人意见: 无法达到生产使用的标准, 建议自行开发相应的监控系统, 或者运维人员通过四字命令手工监控

---

====自己总结=

1. 一些资料

   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/ (原理)
   

2. 心得

   Zookeeper 的使用场景

    Zookeeper完全可以解决我们的问题，分布式计算中的协调员，观察者，分布式锁  都可以作为zookeeper的关键词
    在系统中利用Zookeeper来处理事件通知,队列,优先队列,锁,共享锁等功能，利用这些特色在分布式计算中发挥重要的作用。
   
    Zookeeper 可以做配置的动态更新（通知机制）
   
    配置管理 & 集群服务管理
    	所有节点登录后, 自行获取配置(公共的,特有的(通过serviceId标示))
    	一般节点启动后负责在 某 path 中写入自身的service等标志, 如果已有则不再启动
    	管理节点启动后负责获取所有其他节点写入的一些数据, 来确定有多少其他节点正在工作
   

   一些疑问:

    是否可以用于进行业务监控和系统监控 ?
    数据是否可以序列处理? 是否有乱序 ? 写入 ZK 的效率如何 ?  一个 ZK集群, 单个client 最快写入效率?20个节点,最快写入效率如何?
    如果一个节点的数据更新了, client端获取到watcher 事件, 但是还未处理完, 节点数据又更新了, 是否可能发生? 应该如何处理呢?
    server 端直接关闭, 会有何情况 ?
    	会导致连接上的客户端, 不断重试连接; 如果client 进行连接时, server 还未ready, 则会一直重试, 一旦 server ok ,则连接会成功
    集群如果对应的 myid 不在, 会报错, zoo.cfg 读取失败
   

3. Todo :

   • ZK 源码查看

       服务端的启动
       服务端的整体结构
       客户端的连接
       服务端接收到各类事件的处理
       事务日志的写入
       快照的写入
     

   • ZK 的应用开发

       1) 设想 ET, 将配置文件存在ZK中,启动时读取,且响应更新 ; 以API jar 的方式提供, 可以用于各个项目中获取
       2) ZK 节点数据界面可视化开发
       3) 监控工具打造:应用通过ZK将数据传入,监控工具从ZK中获取各个更新数据
     

   • Zookeeper 的性能压力测试

       1) 单个client, 针对单个节点的连续写入能力,测试写入性能, 另外配合一个client注册watcher, 看是否可以连续获取到更新的数据
       2) 单个client, 针对打个节点不断写入子节点,测试写入性能, 另外注册 watcher , 看是否可以获取到更新的事件
       3) 使用场景有些类似于 MQ 的使用, 对于ZK读取数据的性能测试