ZooKeeper设计特点及典型应用场景

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> ZooKeeper设计特点及典型应用场景

ZooKeeper 特点/设计目的

ZooKeeper 作为一个集群提供数据一致的协调服务,自然,最好的方式就是在整个集群中的 各服务节点进行数据的复制和同步。

数据复制的好处

1、容错:一个节点出错,不至于让整个集群无法提供服务

2、扩展性:通过增加服务器节点能提高 ZooKeeper 系统的负载能力,把负载分布到多个节点上

3、高性能:客户端可访问本地 ZooKeeper 节点或者访问就近的节点,依次提高用户的访问速度

设计目的

1、最终一致性:client不论连接到哪个Server,展示给它都是同一个视图,这是zookeeper最重要的性能。 
2、可靠性:具有简单、健壮、良好的性能,如果消息被到一台服务器接受,那么它将被所有的服务器接受。 
3、实时性:Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。但由于网络延时等原因,Zookeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。 
4、等待无关(wait-free):慢的或者失效的client不得干预快速的client的请求,使得每个client都能有效的等待。 
5、原子性:更新只能成功或者失败,没有中间状态。 
6、顺序性:包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。 

 

ZooKeeper 典型应用场景

命名服务

  命名服务是分布式系统中较为常见的一类场景,分布式系统中,被命名的实体通常可以是集 群中的机器、提供的服务地址或远程对象等,通过命名服务,客户端可以根据指定名字来获 取资源的实体、服务地址和提供者的信息。Zookeeper 也可帮助应用系统通过资源引用的方 式来实现对资源的定位和使用,广义上的命名服务的资源定位都不是真正意义上的实体资源, 在分布式环境中,上层应用仅仅需要一个全局唯一的名字。Zookeeper 可以实现一套分布式 全局唯一 ID 的分配机制。

ZooKeeper设计特点及典型应用场景

配置管理

  程序总是需要配置的,如果程序分散部署在多台机器上,要逐个改变配置就变得困难。现在 把这些配置全部放到 ZooKeeper 上去,保存在 ZooKeeper 的某个目录节点中,然后所有相关应用程序对这个目录节点进行监听,一旦配置信息发生变化,每个应用程序就会收到 ZooKeeper 的通知,然后从 ZooKeeper 获取新的配置信息应用到系统中就好

ZooKeeper设计特点及典型应用场景

集群管理

所谓集群管理无在乎两点:是否有机器退出和加入、选举 master

  对于第一点,所有机器约定在父目录 GroupMembers 下创建临时目录节点,然后监听父目录 节点的子节点变化消息。一旦有机器挂掉,该机器与 ZooKeeper 的连接断开,其所创建的 临时目录节点被删除,所有其他机器都收到通知:某个兄弟目录被删除,于是,所有人都知道:有兄弟挂了。新机器加入也是类似,所有机器收到通知:新兄弟目录加入,又多了个新兄弟。

  对于第二点,我们稍微改变一下,所有机器创建临时顺序编号目录节点,每次选取编号最小的机器作为 master 就好。当然,这只是其中的一种策略而已,选举策略完全可以由管理员 自己制定。

ZooKeeper设计特点及典型应用场景

分布式锁

通过zookeeper实现的分布式锁通常还是使用ZooKeeper框架Curator对于分布式锁的实现,但可以自己思考一下如何实现。

有了 ZooKeeper 的一致性文件系统,锁的问题变得容易。 锁服务可以分为两类

一个是读写锁,对写加锁,保持独占,或者叫做排它锁,独占锁;对读加锁,可共享访问,释放锁之后才可进行事务操作,也叫共享锁

一个是控制时序,叫时序锁

  对于独占锁,我们将 ZooKeeper 上的一个 znode 看作是一把锁,通过 createznode 的方式来 实现。对于独占锁,所有客户端都去创建临时目录(临时且节点路径会加上序号)节点/Locks/write,最终成功创建最小序号/Locks/write节点的那个客户端即拥有了这把锁,用完删除掉自己创建的节点就释放出锁,然后下一个序号的节点就可以获取锁。对于共享锁,可以思考如何实现,共享锁要保证不能和独占锁共存,如果有某个进程持有独占锁,那么所有的独占锁或共享锁都不能获取,如果没有独占锁被某个进程持有,那么持有共享锁的进程都可以并发运行,独占锁必须等待所有共享锁全部释放后才能获取。

对于共享锁,我有一个实现思路是,全部创建/locks/readwritelock路径的临时目录节点,然后对于写锁的节点,执行create /locks/readwritelock write,而读锁执行create /locks/readwritelock read,通过序号最小的节点的保存的字符串是read还是write来确定某个线程持有锁实写锁还是读锁;如果第一个节点是写锁,那么其余节点对应的所有线程都不得持有锁,得进入线程等待状态。如果是读锁,那么从第一个节点开始遍历,直到一个请求写锁的节点之前的所有节点对应的线程都可以获取读锁并且权限。路径下保存的数据不一定是字符串,用数字代替也可以。

  对于时序锁, /Locks已经预先存在,所有客户端在它下面创建临时顺序编号目录节点,和选 master 一样,编号最小的获得锁,用完删除,依次有序

设计锁时,一定要保证锁的释放,所以一般都会将节点设置为临时节点,保证即使客户端未释放锁(删除节点)就异常终止,也能让其他程序获取到锁,避免死锁。

ZooKeeper设计特点及典型应用场景

队列管理

  两种类型的队列:

  1、同步队列:当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达。

  2、先进先出队列:队列按照 FIFO 方式进行入队和出队操作。

  第一类,在约定目录下创建临时目录节点,监听节点数目是否是我们要求的数目。

  第二类,和分布式锁服务中的控制时序场景基本原理一致,入列有编号,出列按编号。 同步队列的流程图:

ZooKeeper设计特点及典型应用场景