美文网首页
ZooKeeper典型应用场景

ZooKeeper典型应用场景

作者: bobcorbett | 来源:发表于2017-11-22 10:10 被阅读0次
    数据发布/订阅
    • 有两种设计模式,分别是push和pull,push是客户端主动推送给订阅的客户端,pull是由客户端主动发起请求来获取最新数据
    • 如果把配置信息配置到ZooKeeper,同时添加一个watcher监听,这样但凡配置发生变化,服务端都会实时通知到所有客户端
    • 配置信息可以分为配置文件或者内存变量
      • 配置文件可以通过定时轮询读取
      • 内存比那里可以通过JMX实现对系统运行内存变量的更新
    DDNS:动态DNS方案
    命名服务
    • 通过使用命名服务,客户端应用能够根据指定名字来获取资源的实体、服务地址和提供者的信息
    分布式协调/通知
    • ZooKeeper通过Watcher注册与异步通知机制,实现分布式协调/通知
    • ZooKeeper用来搭建MySQL数据复制总线
    • 任务注册时,core进行首先会向/mysql_replicator/tasks节点注册任务,比如/mysql_replicator/tasks/copy_hot_item任务节点
    • 任务热备份:每台任务机器(复制任务部署的主机)都需要在/mysql_replicator/tasks/copy_hot_item/instances/[Hostname]-1
      • 每台任务机器取任务时,都会判断节点的序列号是否是序号最小的子节点,按照“小序号优先”策略进行调度,最小子节点机器会将自己机器状态设置为RUNNING,其余任务机器设置为STANDBY
    • 热备切换:如果RUNNING机器出现故障,所有标记为STANDBY的机器按照“小序号优先”原则选举出来执行
    • 冷备份扫描:序列号小的core进程会把自己标记为RUNNING,其他core进程会把自己创建的子节点删除,然后继续扫描下一个task节点
    • 冷热备份区别:热备份可以实时进行互相协调,缺点是资源消耗较大。冷备份使用扫描机制,降低实时性,但是节省了机器资源
    集群管理
    • 了解机器中有多少台机器,对每台机器运行时状态进行数据采集,对集群中机器进行上下线操作
      • 但是存在大规模升级困难、无法监控到具体中间件中消费者和生产者状态,编程语言多样性问题
    分布式日志采集系统
    • 在每台手机日志的机器启动时,ZooKeeper在收集器节点下创建对应节点
    master选举
    • 利用关系型数据库的主键特性来保证在集群中选举出唯一的master。利用ZooKeeper的强一致性,保证客户端无法重复创建一个已经存在的数据节点
    分布式锁
    • 排它锁:保证当前有且仅有一个事务获得锁。
      • 获取排它锁:在调用create()接口时,在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。同时所有没有获取到锁的客户端需要到/exclusive_lock节点上注册一个子节点变更的Watcher监听,以便实时监听到lock节点的变更情况。
      • 释放排它锁:当前获取锁的客户端机器发生宕机,或者正常完成业务逻辑后,客户端会将自己创建的临时节点删除。
    • 共享锁:加上排它锁之后,数据对象只对一个事务可见,而加上共享锁之后,数据对所有事务可见。其他事务都可以对这个数据对象加共享锁,直到数据对象上所有共享锁被释放。
      • 共享锁数据结构:在ZooKeeper上使用数据节点表示一个锁,类似于“/shared_lock/[Hostname]-请求类型-序号”的临时顺序节点,例如/shared_lock/192.168.0.1-R-0000000001
      • 获取共享锁:如果是读请求,创建/shared_lock/192.168.0.1-R-0000000001节点,如果是写请求,那么创建例如/shared_lock/192.168.0.1-W-0000000001节点
    • 读写顺序:创建完共享锁之后,会获取/shared_lock下所有子节点,并对该节点注册子节点变更的Watcher监听。
      • 如果没有比自己序号小的子节点,或者比自己序号小的节点都是读请求(可以并发读),那么表明自己已经成功获取到了共享锁,开始执行读取逻辑。
      • 对于读请求,如果有比自己序号小的子节点中有写请求,那么就需要进入等待。
      • 对于写请求,如果自己不是序号最小的请求,那么也需要进入等待。
    • 羊群效应:在整个分布式锁竞争过程中,大量的“Watcher通知”和“子节点列表获取”两个操作重复运行,并且大多数的运行结果都是判断出自己并非序号最小的节点,从而开始等待下一次通知。客户端无端地接收到过多和自己并不相关的事件通知,同一时间有多个节点对应的客户端完成事务或是事务中断引起的节点消失,ZooKeeper服务器会在短时间内向其他客户端发送大量的事件通知——这个就是所谓的羊群效应
    • 避免羊群效应,降低监听锁的颗粒度,从监听子节点列表,改变成
      • 读请求:对于比自己序号小的最近一个写请求节点注册Watcher监听
      • 写请求:向比自己序号小的最近一个节点注册Watcher监听
    分布式队列
    • FIFO先入先出队列:共享锁的实现
    • Barrier分布式屏障:对子节点列表变更添加Watcher监听,个数到达N值后,开始业务处理,否则需要进入等待

    相关文章

      网友评论

          本文标题:ZooKeeper典型应用场景

          本文链接:https://www.haomeiwen.com/subject/sbhnvxtx.html