内容简介:zookeeper实现了主动通知节点变化,原子创建节点,临时节点,按序创建节点等功能。通过以上功能的组合,zookeeper能够在分布式系统中组合出很多上层功能。下面就看几个常用到的场景,及使用方式和注意事项。顾名思义,就是给分布式系统中的资源,使用人易于理解的名字,能够找到需要的资源。例如:一个统一接口系统,接收服务然后转给后端服务的具体server。当新增接口时,请求方只要传递新接口的名字,系统就能够根据名字找到对应的server,发现服务并转发请求。
zookeeper实现了主动通知节点变化,原子创建节点,临时节点,按序创建节点等功能。通过以上功能的组合,
zookeeper能够在分布式系统中组合出很多上层功能。下面就看几个常用到的场景,及使用方式和注意事项。
名字服务(NameService)
顾名思义,就是给分布式系统中的资源,使用人易于理解的名字,能够找到需要的资源。例如:一个统一接口系统,接收服务然后转给后端服务的具体server。当新增接口时,请求方只要传递新接口的名字,系统就能够根据名字找到对应的server,发现服务并转发请求。
在zookeeper中,按照命名的规则,建立对应的目录层级,例如 /company/team/service 就能找到一个公司,一个team下的提供的某个服务的路径。当上线新业务时,服务在zk中找到自己名字的节点,建立一个临时节点,写入配置信息。当调用方使用时,统一接口查询对应目录下的节点,选择合适的读取配置。当业务下掉时,直接删除服务,临时节点自动删除,服务自动下线掉。
配置管理(Configuration Management)
分布式系统位于不同主机的服务,有时要使用统一的配置。可以在zookeeper中的znode节点存储配置数据,每个客户端都监控(watch)znode的变化,当配置变更时,会通知推送,然后各个客户端再拉取新的配置。
注意:zk的watch是一次性的,客户端读取后要重新watch,并且检查是否是最新版本。
组员管理(Group Membership)
在Master、Slave模式下,Master要知道都有哪些Slave,进行同步等操作。也要及时知道哪些Slave死掉,然后去做相应处理。具体做法是Master先建立一个/Slave节点,每个Slave上线时都在/Slave建立一个临时节点,写入配置,server监控/Slave节点,对增加或消失的节点进行相应处理。
以上三种用法都属于配置类服务,按照一定的规则进行配置,需要读取配置的地方监控配置的变化。
简单互斥锁(Simple Lock)
每个进程都在/lock下创建锁znode,并watch /lock,只有一个创建成功,当成功的进程释放锁或者停止超时会通知其他进程,重新进入竞争锁的机制。
互斥锁(Simple Lock without Herd Effect)
为了不引发惊群效应,只要能给竞争进程 排序 就可以了,每个进程都在/lock的节点下创建带序号的znode,并且每个znode只监听比他次小的节点,当次小的节点释放锁后,比他次大的节点会收到通知,拿到锁权限。
注意:防止还没有执行到的进程死掉,要更新监听顺序。例如:2监听1,3监听2,如果2进程提前死掉,3要监控到这种状态,判断是否是2关闭,还是2释放锁,如果不是正常关闭,要去监听1更新监听。
读写锁(Read/Write Lock)
读写锁:多个读可以并发执行,但是写和读,写和写不能同时执行。
改动互斥锁方案, 如果是写锁,监听他次小的节点,次小节点释放锁后,写锁检测是否还有更小的节点,如果有继续监听,如果没有获得写锁执行 ;如果是读锁,监听左侧最大的写锁,当写锁释放后就获得读锁。
也要注意中间节点死掉提前释放的问题,要重新监听节点。
屏障(Barrier)
在分布式系统中,屏障是这样一种语义: 客户端需要等待多个进程完成各自的任务,然后才能继续往前进行下一步。
例如凌晨备份,等待每个进程把数据都dump结束后,再打包压缩传走。
client先设置/mybarrier的znode,然后启动每个进程,每个进程执行结束成功后,在/mybarrier下创建结束的znode节点,client发现/mybarrier下的node数都达到了,再继续下面的任务。
双屏障(Double Barrier)
双屏障是这样一种语义: 它可以用来同步一个任务的开始和结束,当有足够多的进程进入屏障后,才开始执行任务;当所有的进程都执行完各自的任务后,屏障才撤销。
进入屏障:创建/ready和/process节点,每个进程都先到ready中注册,注册数量达到要求时,通知所有进程启动开始执行。
离开屏障:在/process下把注册ready的进程都建立节点,每个进程执行结束后删掉/process下的对应节点。当/process下为空时,任务全结束。
锁、屏障,本质都是排序,给要使用的节点排序,根据顺序来执行策略,保证执行不冲突。
总结
以上的应用场景,并不是只有zk能实现的,而且实现的方式也是通用的,换做其他组件,只要满足了通知和原子创建、自增id,都可以实现这些场景的使用。而且实现的方法也是通用的,不仅在zk中才这样用。
本质上就是统一配置通知机制,和原子简历自增id节点排序机制,实现了配置类和锁类协调的功能。
参考
《ZooKeeper原理及使用》 http://www.wuzesheng.com/?p=2609
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 性能测试场景设计深度解析
- 深入解析Redis中常见的应用场景
- Laravel 全局异常错误处理源码解析及使用场景
- 社团链应用场景深度解析之----零知识身份认证
- 看这里!鹅厂大佬深度解析 Apache Pulsar 五大应用场景
- EmotiW2018国际大赛夺冠 解析思图场景情感识别算法
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
HTML 压缩/解压工具
在线压缩/解压 HTML 代码
RGB转16进制工具
RGB HEX 互转工具