- 浏览: 392801 次
- 性别:
- 来自: 杭州
文章分类
- 全部博客 (760)
- 股票日志 (26)
- Selenium (0)
- selenium 2 环境的搭建 (1)
- 并发 (7)
- 框架开发 (1)
- 动态代理 (2)
- Struts2 (2)
- POI (2)
- jdk (3)
- maven (31)
- spring (35)
- mysql (31)
- 工作机会 (3)
- xtream (1)
- oracle dbms_metadata GET_DDL (0)
- SSI (1)
- DB (61)
- powermock (4)
- java 基础 (25)
- 多线程 (11)
- 高手 (2)
- java 底层 (2)
- 专业网站 (1)
- 开发联想 (1)
- 开发联想 (1)
- bat文件 (2)
- 清queue 语句 (1)
- 清queue 语句 (1)
- jquery (7)
- html5 (1)
- Jenkins (10)
- Linux (17)
- 工作issue (2)
- tomcat log (3)
- jvm (23)
- 项目细节 (0)
- oracle (41)
- 泛型 (3)
- 新知识点 (1)
- 数据库ddl 语句 (0)
- AQ (2)
- jms (0)
- 网络资源 (6)
- github (6)
- Easymock (1)
- Dom 解析XML (1)
- windows命令 (2)
- java (7)
- 正则表达式 (5)
- sequence (1)
- oracle 表meta信息 (1)
- 小工具技巧 (1)
- 辅助工具 (1)
- Junit (1)
- 泛型 generic (2)
- Java程序设计 (1)
- cglib (2)
- 架构师之路 (1)
- 数据库连接池 (5)
- c3p0 (1)
- eclipse使用 (1)
- oracle sql plus (1)
- 码农人生 (3)
- SVN (15)
- sqlplus (2)
- jsoup (1)
- 网络爬虫 (2)
- 新技能 (1)
- zookeeper (4)
- hadoop (1)
- SVNKIT (1)
- 从工具到知识点的整理 (1)
- log4j (13)
- 读文件 (0)
- 转义字符 (1)
- command (1)
- web service (3)
- 锁 (1)
- shell 脚本 (1)
- 遇到的错误 (2)
- tomcat (14)
- 房产 (5)
- bootstrap jquery ui (1)
- easyui (2)
- 个人征信 (1)
- 读写分离 (1)
- 备份 (1)
- rmi (6)
- webservice (1)
- JMX (4)
- 内存管理 (3)
- java设计 (1)
- timer (1)
- lock (2)
- concurrent (2)
- collection (1)
- tns (1)
- java基础 (15)
- File (1)
- 本机资源 (1)
- bat (1)
- windows (4)
- 数据结构 (3)
- 代码安全 (1)
- 作用域 (1)
- 图 (2)
- jvm内存结构 (1)
- 计算机思想 (1)
- quartz (6)
- Mongo DB (2)
- Nosql (4)
- sql (5)
- 第三方Java 工具 jar 项目 (2)
- drools (1)
- java swing (2)
- 调用console (1)
- runtime (1)
- process (1)
- swing (2)
- grouplayout (1)
- dubbo (0)
- bootstrap (0)
- nodejs (2)
- SVN hooks (1)
- jdbc (3)
- jdbc error (1)
- precedure (1)
- partition_key (1)
- active mq (1)
- blob (2)
- Eclipse (6)
- web server (1)
- bootstrapt (2)
- struts (1)
- ajax (1)
- js call back (1)
- 思想境界拓展 (1)
- JIRA (1)
- log (1)
- jaxb (3)
- xml java互相转换 (1)
- 装修 (2)
- 互联网 (2)
- threadlocal (3)
- mybatis (22)
- xstream (1)
- 排序 (1)
- 股票资源 (1)
- RPC (2)
- NIO (3)
- http client (6)
- 他人博客 (1)
- 代理服务器 (1)
- 网络 (2)
- web (1)
- 股票 (5)
- deadlock (1)
- JConsole (2)
- activemq (3)
- oralce (1)
- 游标 (1)
- 12月13日道富内部培训 (0)
- grant (1)
- 速查 (2)
- classloader (4)
- netty (4)
- 设计模式 (2)
- 缓存 (2)
- ehcache (2)
- framework (1)
- 内存分析 (2)
- dump (1)
- memory (2)
- 多高线程,并发 (1)
- hbase (2)
- 分布式系统 (1)
- socket (3)
- socket (1)
- 面试问题 (1)
- jetty (2)
- http (2)
- 源码 (1)
- 日志 (2)
- jni (1)
- 编码约定 (1)
- memorycache (1)
- redis (13)
- 杂谈 (1)
- drool (1)
- blockingqueue (1)
- ScheduledExecutorService (1)
- 网页爬虫 (1)
- httpclient (4)
- httpparser (1)
- map (1)
- 单例 (1)
- synchronized (2)
- thread (1)
- job (1)
- hashcode (1)
- copyonwriteArrayList (2)
- 录制声音 (1)
- java 标准 (2)
- SSL/TLS (1)
- itext (1)
- pdf (1)
- 钻石 (2)
- sonar (1)
- unicode (1)
- 编码 (4)
- html (1)
- SecurityManager (1)
- 坑 (1)
- Restful (2)
- svn hook (1)
- concurrentHashMap (1)
- 垃圾回收 (1)
- vbs (8)
- visual svn (2)
- power shell (1)
- wmi (3)
- mof (2)
- c# (1)
- concurrency (1)
- 劳动法 (1)
- 三国志游戏 (2)
- 三国 (1)
- 洪榕 (2)
- 金融投资知识 (1)
- motan (1)
- tkmybatis mapper (1)
- 工商注册信息查询 (1)
- consul (1)
- 支付业务知识 (2)
- 数据库备份 (1)
- 字段设计 (1)
- 字段 (1)
- dba (1)
- 插件 (2)
- PropEdit插件 (1)
- web工程 (1)
- 银行业知识 (2)
- 国内托管银行 (1)
- 数据库 (1)
- 事务 (2)
- git (18)
- component-scan (1)
- 私人 (0)
- db2 (14)
- alias (1)
- 住房 (1)
- 户口 (1)
- fastjson (1)
- test (6)
- RSA (2)
- 密钥 (1)
- putty (1)
- sftp (1)
- 加密 (1)
- 公钥私钥 (3)
- markdown (1)
- sweet (1)
- sourcetree (1)
- 好工具 (1)
- cmd (1)
- scp (1)
- notepad++ (1)
- ssh免密登录 (1)
- https (1)
- ssl (2)
- js (2)
- h2 (1)
- 内存 (2)
- 浏览器 (1)
- js特效 (1)
- io (1)
- 乱码 (1)
- 小工具 (1)
- 每周技术任务 (1)
- mongodb (7)
- 内存泄漏 (1)
- 码云 (2)
- 如何搭建java 视频服务器 tomcat (1)
- 资源 (1)
- 书 (1)
- 四色建模法 (1)
- 建模 (1)
- 配置 (1)
- 职位 (1)
- nginx (1)
- excel (1)
- log4j2 (2)
- 做菜 (1)
- jmap (1)
- jspwiki (1)
- activiti (1)
- 工作流引擎 (1)
- 安卓 (1)
- acitviti 例子 (1)
- 二维码 (1)
- 工作流 (1)
- powerdesign (2)
- 软件设计 (1)
- 乐观锁 (1)
- 王者荣耀 (1)
- session (2)
- token (5)
- cookie (4)
- springboot (24)
- jwt (2)
- 项目路径 (1)
- magicbook (1)
- requestType (1)
- json (2)
- swagger (1)
- eolinker (1)
- springdata (1)
- springmvc (1)
- controlleradvice (1)
- profile (1)
- 银行四要素 (1)
- 支付人员资源 (1)
- 支付渠道 (1)
- yaml (1)
- 中文编码 (1)
- mongo (2)
- serializable (1)
- 序列化 (1)
- zyd (1)
- unittest (1)
- 工具 (1)
- Something (1)
- 通达信 (1)
- protobuf (1)
- 算法 (1)
- springcloud (2)
- hikari (1)
- rocketmq (7)
- cachecloud (1)
- serfj (1)
- axure (1)
- lombok (1)
- 分布式锁 (1)
- 线程 (2)
- 同步代码块 (1)
- cobar (1)
- mq (1)
- rabbitmq (1)
- 定时执行 (1)
- 支付系统 (3)
- 唱歌 (1)
- elasticjob (1)
- 定时任务 (1)
- 界面 (1)
- flink (2)
- 大数据 (1)
- 接私活 (0)
- 内部培训 (2)
最新评论
-
dannyhz:
做股票从短线 试水,然后 慢慢发现 波段和 中期的故事可挖, ...
搭台唱戏 -
dannyhz:
http://developer.51cto.com/art/ ...
如何自己开发框架 它的注意点是什么
http://blog.csdn.net/liuxinghao/article/details/42747625
1 概述
ZooKeeper(动物园管理员),顾名思义,是用来管理Hadoop(大象)、Hive(蜜蜂)、Pig(小猪)的管理员,同时Apache HBase、Apache Solr、LinkedIn Sensei等众多项目中都采用了ZooKeeper。
ZooKeeper曾是Hadoop的正式子项目,后发展成为Apache顶级项目,与Hadoop密切相关但却没有任何依赖。它是一个针对大型应用提供高可用的数据管理、应用程序协调服务的分布式服务框架,基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,提供的功能包括:配置维护、统一命名服务、状态同步服务、集群管理等。
在分布式应用中,由于工程师不能很好地使用锁机制,以及基于消息的协调机制不适合在某些应用中使用,因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。
2 特征
1.ZooKeeper是简单的:ZooKeeper的核心是一个精简文件系统,它提供一些简单的操作和一些额外的抽象操作,例如:排序和通知。
2.ZooKeeper是富有表现力的:ZooKeeper的原语操作是一组构件(building block),可用于实现很多协调数据结构和协议,例如:分布式队列、分布式锁和一组同级节点中的leader选举(leader election)。
3.ZooKeeper具有高可用性:ZooKeeper运行在集群上,被设计成具有较高的可用性,因此应用程序可以完全依赖它。ZooKeeper可以帮助系统避免出现单点故障,从而构建一个可靠的应用。
4.ZooKeeper采用松耦合交互方式:在ZooKeeper支持的交互过程中,参与者之间不需要彼此了解。例如:ZooKeeper可以被用作一个rendezvous机制,让进程在不了解其他进程或网络状况的情况下能够彼此发现并进行交互。参与协调的各方甚至可以不必同时存在,因为一个进程在ZooKeeper中留下一条消息,在该进程结束后,另外一个进程还可以读取这条消息。
5.ZooKeeper是一个资源库:ZooKeeper提供了一个关于通用协调模式实现和方法的开源共享存储库,能使程序员免于编写这类通用的协议。所有人都能够对这个资源库进行添加和改进,随着时间的推移,会使每个人都从中收益。
6.ZooKeeper是高性能的:在它的诞生地Yahoo!公司,对于以写为主的工作负载来说,ZooKeeper的基准吞吐量已超过每秒10000个操作;对于常规的以读为主的工作负载来说,吞吐量更是高出好几倍。
3 ZooKeeper的数据模型
理解ZooKeeper的一种方法是将其看做一个具有高可用性的文件系统。但这个文件系统中没有文件和目录,而是统一使用节点(node)的概念,称为znode。znode既可以保存数据(如同文件),也可以保存其他znode(如同目录)。所有的znode构成一个层次化的数据结构,。
•Persistent Nodes: 永久有效地节点,除非client显式的删除,否则一直存在
•Ephemeral Nodes: 临时节点,仅在创建该节点client保持连接期间有效,一旦连接丢失,zookeeper会自动删除该节点
•Sequence Nodes: 顺序节点,client申请创建该节点时,zk会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式queue等特殊功能的关键
ZooKeeper是Hadoop的正式子项目,与Hadoop密切相关但却没有任何依赖。它是一个针对大型应用提供高可用的数据管理、应用程序协调服务的分布式服务框架,基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,提供的功能包括:配置维护、统一命名服务、状态同步服务、集群管理等。
4 ZooKeeper典型使用场景
4.1 数据发布于订阅
4.1.1 特性、用法
发布与订阅即所谓的配置管理,顾名思义就是将数据发布到zk节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如:全局的配置信息、地址列表等。
4.1.2 具体用法
1.索引信息和集群中机器节点状态放在zk的一些指定节点,供各个客户端订阅使用。
2.系统日志(经处理后)存储,这些日志通常2-3天后清除。
3.应用中用到的一些配置信息集中管理,在应用启动的时候主动来获取一次,并在节点上注册一个Watcher,以后每次配置有更新,实时通知到应用,获取最新的配置信息。
4.业务逻辑中需要用到的一些全局变量,比如一些消息中间件的消息队列通常有个offset,这个offset存放在zk上,这样集群中每个发送者都能知道当前的发送进度。
5.系统中有些信息需要动态获取,并且还会存在人工手动去修改这个信息。以前通常是暴露出接口,例如JMX接口,有了zk后,只要将这些信息存放到zk节点上即可。
4.2 命名服务
4.2.1 特性、用法
这个主要是作为分布式命名服务,通过调用zk的create node api,能够很容易创建一个全局唯一的path,可以将这个path作为一个名称。
4.3 分布通知/协调
4.3.1 特性、用法
ZooKeeper中特有的watcher注册于异步通知机制,能够很好的实现分布式环境下不同系统之间的通知与协调,实现对数据变更的实时处理。使用方法通常是不同系统都对zk上同一个znode进行注册,监听znode的变化(包括znode本身内容及子节点内容),其中一个系统update了znode,那么另一个系统能够收到通知,并做出相应处理。
使用ZooKeeper来进行分布式通知和协调能够大大降低系统之间的耦合。
4.3.2 具体用法
1.心跳检测机制:检测系统和被测系统之间并不直接关联起来,而是通过zk上某个节点关联,大大减少系统耦合。
2.系统调度模式:某系统有控制台和推送系统两部分组成,控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台做的一些操作,实际上是修改了zk上某些节点的状态,而zk就把这些变化通知给它们注册watcher的客户端,即推送系统,于是,做出相应的推送任务。
3.工作汇报模式:一些类似于任务分发系统,子任务启动后,到zk来注册一个临时节点,并定时将自己的进度进行汇报(将进度写回这个临时节点),这样任务管理者就能够实时指导任务进度。
4.4 分布式锁
4.4.1 特性、用法
分布式锁,主要得益于ZooKeeper保证数据的强一致性,即zk集群中任意节点(一个zk server)上系统znoe的数据一定相同。
锁服务可以分为两类:
1.保持独占锁:所有试图来获取这个锁的客户端,最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看做是一把锁,通过create znode的方式来实现。所有客户端都去创建/distribute_lock节点,最终成功创建的那个客户端也即拥有了这把锁。
2.控制时序锁:所有试图来获取这个锁的客户端,最终都是会被安排执行,只是有个全局时序了。与保持独占锁的做法类似,不同点是/distribute_lock已经预先存在,客户端在它下面创建临时有序节点(可以通过节点控制属性控制:CreateMode.EPHEMERAL_SEQUENTIAL来指定)。zk的父节点(/distribute_lock)维持一份sequence,保证子节点创建的时序性,从而形成每个客户端的全局时序。
4.5 集群管理
4.5.1 特性、用法
1.集群机器监控:这通常用于那种对集群中机器状态、机器在线率有较高要求的场景,能够快速对集群中机器变化做出响应。这样的场景中,往往有一个监控系统,实时监测集群机器是否存活。过去的做法通常是:监控系统通过某种手段(比如ping)定时检测每个机器、或每个机器定时向监控系统发送心跳信息。这种做法存在两个弊端:1.集群中机器有变动的时候,牵连修改的东西比较多。2.有一定的延迟。利用ZooKeeper,可以实现另一种集群机器存活性监控系统:a.客户端在节点x上注册watcher,如果x的子节点发生变化,会通知该客户端。b.创建EPHEMERAL类型的节点,一旦客户端和服务器的会话结束或过期,该节点就会消失。例如:监控系统在/clusterServers节点上注册一个watcher,以后每动态加机器,就往/culsterServer下创建一个EPHEMERAL类型的节点:/clusterServer/{hostname}。这样,监控系统就能实时知道机器的增减情况,至于后续处理就是监控系统的业务了。
2.Master选举:在分布式环境中,相同的业务应用分布在不同的机器上,有些业务逻辑(例如一些耗时的计算、网络I/O处理),往往需要让整个集群中的某一台机器进行执行,其余机器可以共享这个结果,这样可以减少重复劳动、提高性能。利用ZooKeeper的强一致性,能够保证在分布式高并发情况下节点创建的全局唯一性,即:同时有多个客户端请求创建/currentMaster节点,最终一定只有一个客户端请求能够创建成功。利用这个特性,就能很轻易的在分布式环境中进行集群选取了。另外,这种场景演化一下,就是动态Master选举。这就要用到 EPHEMERAL_SEQUENTIAL类型节点的特性了。上文中提到,所有客户端创建请求,最终只有一个能够创建成功。在这里稍微变化下,就是允许所有请求都能够创建成功,但是得有个创建顺序,于是所有的请求最终在zk上创建结果的一种可能情况是这样: /currentMaster/{sessionId}-1、/currentMaster/{sessionId}-2、/currentMaster/{sessionId}-3……。每次选取序列号最小的那个机器作为Master,如果这个机器挂了,由于他创建的节点会马上消失,那么之后最小的那个机器就是Master了。
4.5.2 具体用法
1.在搜索系统中,如果集群中每个机器都生成一份全量索引,不仅耗时,而且不能保证彼此之间索引数据一致。因此让集群中的Master来进行全量索引的生成,然后同步到集群中其它机器。
2.Master选举的容灾措施是,可以随时进行手动指定master,就是说应用在zk在无法获取master信息时,可以通过比如http方式,向一个地方获取master。
4.6 分布式队列
4.6.1 特性、用法
队列方面,有两种方式:一种是常规的先进先出队列,另一种是要等到队列成员聚齐之后的才统一按序执行。
对于先进先出队列,和分布式锁服务中的控制时序场景基本原理一致,这里不再赘述。
第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在/queue这个znode下预先建立一个/queue/num节点,并且赋值为n(或者直接给/queue赋值n),表示队列大小,之后每次有队列成员加入后,就判断下是否已经到达队列大小,决定是否可以开始执行了。这种用法的典型场景是,分布式环境中,一个大任务Task A,需要在很多子任务完成(或条件就绪)情况下才能进行。这个时候,凡是其中一个子任务完成(就绪),那么就去/taskList下建立自己的临时时序节点(CreateMode.EPHEMERAL_SEQUENTIAL),当/taskList发现自己下面的子节点满足指定个数,就可以进行下一步按序进行处理了。
1 概述
ZooKeeper(动物园管理员),顾名思义,是用来管理Hadoop(大象)、Hive(蜜蜂)、Pig(小猪)的管理员,同时Apache HBase、Apache Solr、LinkedIn Sensei等众多项目中都采用了ZooKeeper。
ZooKeeper曾是Hadoop的正式子项目,后发展成为Apache顶级项目,与Hadoop密切相关但却没有任何依赖。它是一个针对大型应用提供高可用的数据管理、应用程序协调服务的分布式服务框架,基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,提供的功能包括:配置维护、统一命名服务、状态同步服务、集群管理等。
在分布式应用中,由于工程师不能很好地使用锁机制,以及基于消息的协调机制不适合在某些应用中使用,因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。
2 特征
1.ZooKeeper是简单的:ZooKeeper的核心是一个精简文件系统,它提供一些简单的操作和一些额外的抽象操作,例如:排序和通知。
2.ZooKeeper是富有表现力的:ZooKeeper的原语操作是一组构件(building block),可用于实现很多协调数据结构和协议,例如:分布式队列、分布式锁和一组同级节点中的leader选举(leader election)。
3.ZooKeeper具有高可用性:ZooKeeper运行在集群上,被设计成具有较高的可用性,因此应用程序可以完全依赖它。ZooKeeper可以帮助系统避免出现单点故障,从而构建一个可靠的应用。
4.ZooKeeper采用松耦合交互方式:在ZooKeeper支持的交互过程中,参与者之间不需要彼此了解。例如:ZooKeeper可以被用作一个rendezvous机制,让进程在不了解其他进程或网络状况的情况下能够彼此发现并进行交互。参与协调的各方甚至可以不必同时存在,因为一个进程在ZooKeeper中留下一条消息,在该进程结束后,另外一个进程还可以读取这条消息。
5.ZooKeeper是一个资源库:ZooKeeper提供了一个关于通用协调模式实现和方法的开源共享存储库,能使程序员免于编写这类通用的协议。所有人都能够对这个资源库进行添加和改进,随着时间的推移,会使每个人都从中收益。
6.ZooKeeper是高性能的:在它的诞生地Yahoo!公司,对于以写为主的工作负载来说,ZooKeeper的基准吞吐量已超过每秒10000个操作;对于常规的以读为主的工作负载来说,吞吐量更是高出好几倍。
3 ZooKeeper的数据模型
理解ZooKeeper的一种方法是将其看做一个具有高可用性的文件系统。但这个文件系统中没有文件和目录,而是统一使用节点(node)的概念,称为znode。znode既可以保存数据(如同文件),也可以保存其他znode(如同目录)。所有的znode构成一个层次化的数据结构,。
•Persistent Nodes: 永久有效地节点,除非client显式的删除,否则一直存在
•Ephemeral Nodes: 临时节点,仅在创建该节点client保持连接期间有效,一旦连接丢失,zookeeper会自动删除该节点
•Sequence Nodes: 顺序节点,client申请创建该节点时,zk会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式queue等特殊功能的关键
ZooKeeper是Hadoop的正式子项目,与Hadoop密切相关但却没有任何依赖。它是一个针对大型应用提供高可用的数据管理、应用程序协调服务的分布式服务框架,基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,提供的功能包括:配置维护、统一命名服务、状态同步服务、集群管理等。
4 ZooKeeper典型使用场景
4.1 数据发布于订阅
4.1.1 特性、用法
发布与订阅即所谓的配置管理,顾名思义就是将数据发布到zk节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如:全局的配置信息、地址列表等。
4.1.2 具体用法
1.索引信息和集群中机器节点状态放在zk的一些指定节点,供各个客户端订阅使用。
2.系统日志(经处理后)存储,这些日志通常2-3天后清除。
3.应用中用到的一些配置信息集中管理,在应用启动的时候主动来获取一次,并在节点上注册一个Watcher,以后每次配置有更新,实时通知到应用,获取最新的配置信息。
4.业务逻辑中需要用到的一些全局变量,比如一些消息中间件的消息队列通常有个offset,这个offset存放在zk上,这样集群中每个发送者都能知道当前的发送进度。
5.系统中有些信息需要动态获取,并且还会存在人工手动去修改这个信息。以前通常是暴露出接口,例如JMX接口,有了zk后,只要将这些信息存放到zk节点上即可。
4.2 命名服务
4.2.1 特性、用法
这个主要是作为分布式命名服务,通过调用zk的create node api,能够很容易创建一个全局唯一的path,可以将这个path作为一个名称。
4.3 分布通知/协调
4.3.1 特性、用法
ZooKeeper中特有的watcher注册于异步通知机制,能够很好的实现分布式环境下不同系统之间的通知与协调,实现对数据变更的实时处理。使用方法通常是不同系统都对zk上同一个znode进行注册,监听znode的变化(包括znode本身内容及子节点内容),其中一个系统update了znode,那么另一个系统能够收到通知,并做出相应处理。
使用ZooKeeper来进行分布式通知和协调能够大大降低系统之间的耦合。
4.3.2 具体用法
1.心跳检测机制:检测系统和被测系统之间并不直接关联起来,而是通过zk上某个节点关联,大大减少系统耦合。
2.系统调度模式:某系统有控制台和推送系统两部分组成,控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台做的一些操作,实际上是修改了zk上某些节点的状态,而zk就把这些变化通知给它们注册watcher的客户端,即推送系统,于是,做出相应的推送任务。
3.工作汇报模式:一些类似于任务分发系统,子任务启动后,到zk来注册一个临时节点,并定时将自己的进度进行汇报(将进度写回这个临时节点),这样任务管理者就能够实时指导任务进度。
4.4 分布式锁
4.4.1 特性、用法
分布式锁,主要得益于ZooKeeper保证数据的强一致性,即zk集群中任意节点(一个zk server)上系统znoe的数据一定相同。
锁服务可以分为两类:
1.保持独占锁:所有试图来获取这个锁的客户端,最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看做是一把锁,通过create znode的方式来实现。所有客户端都去创建/distribute_lock节点,最终成功创建的那个客户端也即拥有了这把锁。
2.控制时序锁:所有试图来获取这个锁的客户端,最终都是会被安排执行,只是有个全局时序了。与保持独占锁的做法类似,不同点是/distribute_lock已经预先存在,客户端在它下面创建临时有序节点(可以通过节点控制属性控制:CreateMode.EPHEMERAL_SEQUENTIAL来指定)。zk的父节点(/distribute_lock)维持一份sequence,保证子节点创建的时序性,从而形成每个客户端的全局时序。
4.5 集群管理
4.5.1 特性、用法
1.集群机器监控:这通常用于那种对集群中机器状态、机器在线率有较高要求的场景,能够快速对集群中机器变化做出响应。这样的场景中,往往有一个监控系统,实时监测集群机器是否存活。过去的做法通常是:监控系统通过某种手段(比如ping)定时检测每个机器、或每个机器定时向监控系统发送心跳信息。这种做法存在两个弊端:1.集群中机器有变动的时候,牵连修改的东西比较多。2.有一定的延迟。利用ZooKeeper,可以实现另一种集群机器存活性监控系统:a.客户端在节点x上注册watcher,如果x的子节点发生变化,会通知该客户端。b.创建EPHEMERAL类型的节点,一旦客户端和服务器的会话结束或过期,该节点就会消失。例如:监控系统在/clusterServers节点上注册一个watcher,以后每动态加机器,就往/culsterServer下创建一个EPHEMERAL类型的节点:/clusterServer/{hostname}。这样,监控系统就能实时知道机器的增减情况,至于后续处理就是监控系统的业务了。
2.Master选举:在分布式环境中,相同的业务应用分布在不同的机器上,有些业务逻辑(例如一些耗时的计算、网络I/O处理),往往需要让整个集群中的某一台机器进行执行,其余机器可以共享这个结果,这样可以减少重复劳动、提高性能。利用ZooKeeper的强一致性,能够保证在分布式高并发情况下节点创建的全局唯一性,即:同时有多个客户端请求创建/currentMaster节点,最终一定只有一个客户端请求能够创建成功。利用这个特性,就能很轻易的在分布式环境中进行集群选取了。另外,这种场景演化一下,就是动态Master选举。这就要用到 EPHEMERAL_SEQUENTIAL类型节点的特性了。上文中提到,所有客户端创建请求,最终只有一个能够创建成功。在这里稍微变化下,就是允许所有请求都能够创建成功,但是得有个创建顺序,于是所有的请求最终在zk上创建结果的一种可能情况是这样: /currentMaster/{sessionId}-1、/currentMaster/{sessionId}-2、/currentMaster/{sessionId}-3……。每次选取序列号最小的那个机器作为Master,如果这个机器挂了,由于他创建的节点会马上消失,那么之后最小的那个机器就是Master了。
4.5.2 具体用法
1.在搜索系统中,如果集群中每个机器都生成一份全量索引,不仅耗时,而且不能保证彼此之间索引数据一致。因此让集群中的Master来进行全量索引的生成,然后同步到集群中其它机器。
2.Master选举的容灾措施是,可以随时进行手动指定master,就是说应用在zk在无法获取master信息时,可以通过比如http方式,向一个地方获取master。
4.6 分布式队列
4.6.1 特性、用法
队列方面,有两种方式:一种是常规的先进先出队列,另一种是要等到队列成员聚齐之后的才统一按序执行。
对于先进先出队列,和分布式锁服务中的控制时序场景基本原理一致,这里不再赘述。
第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在/queue这个znode下预先建立一个/queue/num节点,并且赋值为n(或者直接给/queue赋值n),表示队列大小,之后每次有队列成员加入后,就判断下是否已经到达队列大小,决定是否可以开始执行了。这种用法的典型场景是,分布式环境中,一个大任务Task A,需要在很多子任务完成(或条件就绪)情况下才能进行。这个时候,凡是其中一个子任务完成(就绪),那么就去/taskList下建立自己的临时时序节点(CreateMode.EPHEMERAL_SEQUENTIAL),当/taskList发现自己下面的子节点满足指定个数,就可以进行下一步按序进行处理了。
相关推荐
### ZooKeeper典型使用场景详解 #### 一、概述 ZooKeeper是一款开源的分布式协调服务框架,主要用于解决分布式系统中的数据一致性问题。它基于Paxos算法实现,确保了即使在网络分区的情况下,也能保证分布式环境下...
在本课程“第三课:Zookeeper典型使用场景实践1”中,主要讨论了Zookeeper在分布式系统中的四个关键应用场景:分布式集群管理、分布式注册中心、分布式JOB和分布式锁。下面是针对这些场景的详细说明: 1. **分布式...
#### 三、Zookeeper典型应用场景 ##### 1. 数据发布与订阅(配置中心) Zookeeper可以用于发布和订阅配置信息,实现配置信息的集中管理和动态更新。具体应用场景包括: - **全局配置管理**:将全局配置信息存储在...
通过"第三课:zookeeper 典型使用场景实践.docx"、"第三课:zookeeper 典型使用场景实践.md"、"第三课:zookeeper_典型使用场景实践(预习).pdf"这三份文件,你将能够深入理解Zookeeper在实际项目中的应用方式,...
尽管ZooKeeper最初并非为特定应用场景设计,但开发者们逐渐发掘出了一系列典型用途,利用其提供的API接口(原语集)来满足需求。 1. 数据发布与订阅(配置中心) ZooKeeper可以作为一个配置中心,允许发布者将数据...
【Zookeeper 典型使用场景实践】 Zookeeper 是一个分布式协调服务,广泛应用于分布式环境中的配置管理、服务发现、分布式锁、集群管理等场景。在本课程中,我们将重点探讨四个核心应用场景:分布式集群管理、分布式...
通过上述介绍的几个典型应用场景,可以看出ZooKeeper不仅能够简化分布式系统的设计和实现,还能够提高系统的稳定性和扩展性。对于正在构建或优化分布式应用的企业来说,掌握ZooKeeper的核心概念和技术细节是非常有...
ZooKeeper被广泛应用于解决多种分布式问题,以下是一些典型的ZooKeeper应用场景: 1. 数据发布与订阅(配置中心): ZooKeeper作为一个配置中心,允许发布者将数据发布到特定节点,订阅者则可以通过注册Watcher...
【Zookeeper 进阶之——典型应用场景(二)】 Zookeeper 是一个分布式协调服务,它在分布式系统中扮演着至关重要的角色,提供了诸如命名服务、配置管理、组关系管理和分布式锁等高级功能。本文主要讨论如何利用...
本文将探讨 Zookeeper 的几个典型应用场景,并通过代码示例进行解析。 **统一命名服务 (Name Service)** 在分布式环境中,Zookeeper 提供了一种层次化的命名空间,类似于文件系统的目录结构。开发者可以通过调用 ...
同时,本书深入介绍了分布式一致性问题的工业解决方案——ZooKeeper,并着重向读者展示这一分布式协调框架的使用方法、内部实现及运维技巧,旨在帮助读者全面了解ZooKeeper,并更好地使用和运维ZooKeeper。...
#### Zookeeper 典型应用场景 1. **配置管理** 在分布式应用环境中,统一管理配置信息是非常重要的。Zookeeper 可以用来集中存储配置信息,并允许应用程序订阅这些配置的变更通知。当配置发生改变时,所有订阅的...
从Paxos到Zookeeper分布式一致性原理与实践 1.分布式架构 2.一致性协议 3.Paxos的工程实践 4.ZooKeeper与paxos 5.使用ZooKeeper 6.Zookeeper的典型使用场景 7.ZooKeepe技术内幕 8.ZooKeeper运维
在一个典型的Zookeeper集群中,至少需要三个服务器以确保高可用性。客户端发起请求首先发送到任意一个服务器,由领导者负责处理请求并广播到其他服务器,然后所有服务器同步数据,形成一致的状态。 四、Zookeeper的...
同时,本书深入介绍了分布式一致性问题的工业解决方案——ZooKeeper,并着重向读者展示这一分布式协调框架的使用方法、内部实现及运维技巧,旨在帮助读者全面了解ZooKeeper,并更好地使用和运维ZooKeeper。...
目录: zookeeper-3.4.5.tar.gz ZooKeeper典型应用场景.pdf ZooKeeper典型应用场景.pdf zookeeper文档.doc zookeeper文档.pdf zookeeper文档.txt
Zookeeper广泛应用于多种分布式场景中,以下列举了一些典型的应用案例: - **统一命名服务**:在分布式环境中,为了方便识别,通常需要对应用和服务进行统一命名。例如,使用易于记忆的域名代替IP地址。 - **统一...
以下将详细介绍ZooKeeper在实际应用中的几个典型场景。 1. 数据发布与订阅(配置中心) ZooKeeper被广泛用作配置中心,允许发布者将配置信息发布到特定节点,而订阅者可以实时监听并获取这些信息。例如,当全局配置...
Zookeeper典型应用场景包括配置管理、集群管理、命名服务、分布式锁、分布式队列等。例如,Zookeeper可以用来实现一个中心化的配置管理服务,将配置信息存储在Zookeeper中,应用程序可以实时地从Zookeeper中读取配置...