赞
踩
统一命名服务(naming)
分布式应用中,通常需要有一套完整的命名规则,既能狗产生唯一的命名又便于认识别和记住,通常情况下用树形的结构是一个理想的选择,属性的名称结构是一个有层次的目录结构,既对人友好又不会重复,说到这里你可能xiangdao`想到JNDO没错Zookeeper的Name Service与JNDI能够完成的功能是差不多的,他们都是酱油层次的目录结构关联到一定资源上,dansh但是Zookeeper的NameService更加是广泛意义上的关联,也许你并不需要将名称关联到特定资源上,你可能只需要一个不会重复的名称,就想数据库中产生唯一的数字主键一样.
NameService已经是Zookeeper内置的功能,nizh你只要调用Zookeeper的API就能实现,如调用create接口就可以很容易的创建一个目录节点.
配置管理
配置管理的在分布式应用环境下很常见,例如同一个应用系统需要多台PC Server运行,但是他们运行的应用系统的某些配置是相同的,如果要修改这个相同的配置项,那么就必须同时修改每台运行这个系统的PC Server这样非常麻烦而且容易出错.
像这样的配置信息完全可以交给Zookeeper来管理,将配置信息保存在Zookeeper的某个目录节点中,然后将所有需要修改的应用及其监控配置信息的状态,一旦配置信息发生变化,每台应用及其就会收到ZooKeeper的通知,然后从Zookeeper的通知,然后从Zookeeper获取新的配置信息应用到系统中
集群管理
Zookeeper能够很容易的实现集群管理的功能,如有多台Server组成一个服务集群,那么必须要一个总管知道当前及权重每台机器的服务状态,一旦有机器不能提供服务,集群中其他集群必须知道,从而做出调整重新分配服务政策.同样增加集群的服务能力时,就会增加一台或者多台server,同样也必须让总管知道.
Zookeeper不仅能够帮你维护当前的集群中机器的服务状态,而且能够帮你选出一个'总管',让这个总管来管理集群,这就是Zookeeper的另一个功能 Leader Election
它们的实现方式都是在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点,然后每个 Server 在它们创建目录节点的父目录节点上调用 getChildren(String path, boolean watch) 方法并设置 watch 为 true,由于是 EPHEMERAL 目录节点,当创建它的 Server 死去,这个目录节点也随之被删除,所以 Children 将会变化,这时 getChildren上的 Watch 将会被调用,所以其它 Server 就知道已经有某台 Server 死去了。新增 Server 也是同样的原理。
Zookeeper 如何实现 Leader Election,也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点,不同的是它还是一个 SEQUENTIAL 目录节点,所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_SEQUENTIAL 目录节点,是因为我们可以给每台 Server 编号,我们可以选择当前是最小编号的 Server 为 Master,假如这个最小编号的 Server 死去,由于是 EPHEMERAL 节点,死去的 Server 对应的节点也被删除,所以当前的节点列表中又出现一个最小编号的节点,我们就选择这个节点为当前 Master。这样就实现了动态选择 Master,避免了传统意义上单 Master 容易出现单点故障的问题。
对列管理
Zookeeper 可以处理两种类型的队列:
1.当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列。
2.队列按照 FIFO 方式进行入队和出队操作,例如实现生产者和消费者模型。
同步队列用 Zookeeper 实现的实现思路如下:
创建一个父目录 /synchronizing,每个成员都监控标志(Set Watch)位目录 /synchronizing/start 是否存在,然后每个成员都加入这个队列,加入队列的方式就是创建 /synchronizing/member_i 的临时目录节点,然后每个成员获取 / synchronizing 目录的所有目录节点,也就是 member_i。判断 i 的值是否已经是成员的个数,如果小于成员个数等待 /synchronizing/start 的出现,如果已经相等就创建 /synchronizing/start。
单机部署、集群部署、伪集群部署
Zookeeper 的核心是原子广播机制,这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式,它们分别是恢复模式和广播模式。
集群本身有很多种类,如tomcat集群,集群里面每一台机器是对等的,所以其自身不存在leader之说。
另外一类,如fastDfs,其依赖于独特的HASH算法,建立文件名和路径之间的映射关系,写操作都是通过namenode分发到各台datanode之上,算法保证了文件名的独一无二,也不存在leader的说法。
还有memcache集群,集群里面的机器之间彼此无心跳,通过一致性hash尽可能将key值的存储分散化,降低单一memcahe服务器down机的影响。
还有一类是主从复制,主节点负责写,从节点负责读,提高读的性能。从节点定期通过心跳与主节点沟通,一旦主节点挂掉了,从节点马上接手主节点的任务。应该来讲,zookeeper集群是最接近这一种的。
对于分布式应用,难以避免出现网络的抖动。比如,
主节点暂时失去响应,如瞬时负载过高,网络拥塞或者其他原因导致主节点暂时失去响应,超过响应超时时间,这个时候从节点启动,承担起leader的职责,但是原先的主节点又恢复了服务。这个时候,如果没有选举机制(不能仅仅自己宣告自己是leader,还要广而告之,让其他服务器或者客户端知道自己是leader),有可能会存在两个leader节点,导致集群发生混乱
可以;2n+1台server,只要有n+1台就可以使用。
客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时,zookeeper会通知客户端。
注:以上内容仅提供参考和交流,请勿用于商业用途,如有侵权联系本人删除!
注:此博客只是为了记忆相关知识点,大部分为网络上的文章,在此向各个文章的作者表示感谢!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。