在SOA架构设计中。系统对于业务逻辑复用的需求十分强烈,上层业务都想借用已有的底层服务,来快速搭建更多,更丰富的业务。从而下降新业务开展的人力和时间成本,已快速知足瞬息万变的市场需求。而公共的业务被拆分出来,造成可共用的服务,最大程度地保障了代码和逻辑的复用,避免重复建设。所以,服务消费者要经过服务名称,根据服务的路由,在众多服务中找到要调用的服务的地址列表:node
大体流程图以下所示:算法
服务消费者 服务列表 地址列表 service1---> server_address1 service2 server_address2 consumer --->service3 server_address3 service4 ....
而对于负载较高的服务来讲,每每对应着多台主机组成的服务集群。在请求到来时,为了将请求均衡地分配到后端服务器,负载均衡程序将从服务对应的地址列表中,经过负载均衡算法和规则,选出一台最佳的服务器进行访问,这个过程称为负载均衡。数据库
调用者 负载均衡算法 地址列表 round_robin server_address1 consumer --->random ---> server_address2 weight_random server_address3 .... ....
服务规模较小,能够采用硬编码的方法将服务地址和配置写在代码中,提升编码解决服务的路由和负载均衡问题,也能够经过软硬件负载均衡设备LVS,Nginx等经过相关配置来解决服务的路由和负载均衡问题。
当服务的机器数量在可控范围内,上述维护成功较低,配置也简单明了,但当服务愈来愈多,规模愈来愈大时,机器数量愈来愈庞大,靠上述维护方案将会愈来愈困难而且单点故障的问题也开始凸显,一旦服务路由或者负载均衡服务器宕机,全部依赖于它的服务所有不可用。apache
service1--->负载均衡算法-->xxxx(集群) consumer --->service2--->负载均衡算法-->xxxx(集群) service3--->负载均衡算法-->xxxx(集群)
此时须要一个可以动态注册和获取服务信息的地方,来统一管理服务名称和其对应的服务器列表信息,称之为服务配置中心。当服务提供者在启动时,将其提供的服务名称,服务地址注册到服务配置中心。服务消费者经过服务配置中心来得到须要调用的服务的机器列表,经过负载均衡算法。选出其中一台服务器进行调用。当服务器宕机或者下线时,相应的机器须要可以动态的从服务配置中心中移除。并通知相应的服务消费者,不然服务消费者就有可能由于调用到已失效的服务而发生错误。在这个过程当中,服务消费者只有第一次调用服务时须要查询服务配置中心而后将查询到的信息缓存到本地,后面的调用直接使用本地缓存的服务地址列表信息,而不须要从新发起请求到服务配置中心去获取相应的服务地址列表。直到服务的地址有变动(机器上线和下线)。这种无中心化的结构解决了以前负载均衡设备所致使的单点故障问题而且大大减轻了服务配置中心的压力。后端
基于ZooKeeper的持久和非持久的特色,咱们可以近乎实时地感受到后端服务的状态(上线,下线,宕机)经过其集群间的zab协议,使得服务配置信息可以保持一致。而zk自己的容错特性和选举机制可以保障咱们方便的进行扩容。经过zk来实现服务的动态注册,机器上线和下线的动态感知,扩容方便容错性好。且无中心化结构可以解决以前使用负载均衡设备所带来的单机故障问题,只有当配置信息更新时才回去zk上获取最新的服务地址列表,其余的时候使用本地缓存。设计模式
了解了zk以后,咱们来看看zk的使用
关于zk的单机模式安装与大部分软件同样,下载,解压,修改环境变量。这里不浪费篇幅了,也不浪费篇幅来写配置文件的含义了。只介绍几个zk的关键特性和典型的应用场景:缓存
Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中常常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。服务器
Zookeeper 会维护一个具备层次关系的数据结构,它很是相似于一个标准的文件系统,如图所示:session
Zookeeper 这种数据结构有以下这些特色:数据结构
- 每一个子目录项如 NameService 都被称做为 znode,这个 znode 是被它所在的路径惟一标识,如 Server1 这个 znode 的标识为 /NameService/Server1
- znode 能够有子节点目录,而且每一个 znode 能够存储数据,注意 EPHEMERAL 类型的目录节点不能有子节点目录
- znode 是有版本的,每一个 znode 中存储的数据能够有多个版本,也就是一个访问路径中能够存储多份数据
- znode 能够是临时节点,一旦建立这个 znode 的客户端与服务器失去联系,这个 znode 也将自动删除,Zookeeper 的客户端和服务器通讯采用长链接方式,每一个客户端和服务器经过心跳来保持链接,这个链接状态称为 session,若是 znode 是临时节点,这个 session 失效,znode 也就删除了
- znode 的目录名能够自动编号,如 App1 已经存在,再建立的话,将会自动命名为 App2
- znode 能够被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化能够通知设置监控的客户端,这个是 Zookeeper 的核心特性,Zookeeper 的不少功能都是基于这个特性实现的,后面在典型的应用场景中会有实例介绍
Zookeeper 做为一个分布式的服务框架,主要用来解决分布式集群中应用系统的一致性问题,它能提供基于相似于文件系统的目录节点树方式的数据存储,可是 Zookeeper 并非用来专门存储数据的,它的做用主要是用来维护和监控你存储的数据的状态变化。经过监控这些数据状态的变化,从而能够达到基于数据的集群管理,后面将会详细介绍 Zookeeper 可以解决的一些典型问题,这里先介绍一下,Zookeeper 的操做接口和简单使用示例。
基本操做
客户端要链接 Zookeeper 服务器能够经过建立 org.apache.zookeeper. ZooKeeper 的一个实例对象,而后调用这个类提供的接口来和服务器交互。
前面说了* ZooKeeper 主要是用来维护和监控一个目录节点树中存储的数据的状态,全部咱们可以操做 ZooKeeper 的也和操做目录节点树大致同样,如建立一个目录节点,给某个目录节点设置数据,获取某个目录节点的全部子目录节点,给某个目录节点设置权限和监控这个目录节点的状态变化。*
public class App { public static void main(String[] args) { try { // 建立一个与服务器的链接 // 参数三 watch 参数4 canBeReadOnly ZooKeeper zk = new ZooKeeper("localhost:2181", 2000, null, false); // 建立一个目录节点 /* * 参数1 :节点路径 参数2 :节点数据 参数3 :访问权限 Ids.OPEN_ACL_UNSAFE表示无权限 参数4 :节点类型 * CreateMode.PERSISTENT持久节点,当该客户端断开连接时不会删除节点 */ zk.create("/testRootPath", "testRootData".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); // 建立一个子目录节点 zk.create("/testRootPath/testChildPathOne", "testChildDataOne".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); System.out.println(new String(zk.getData("/testRootPath", false, null))); // 取出子目录节点列表 System.out.println(zk.getChildren("/testRootPath", true)); // 修改子目录节点数据 zk.setData("/testRootPath/testChildPathOne", "modifyChildDataOne".getBytes(), -1); System.out.println("目录节点状态:[" + zk.exists("/testRootPath", true) + "]"); // 建立另一个子目录节点 zk.create("/testRootPath/testChildPathTwo", "testChildDataTwo".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); System.out.println(new String(zk.getData("/testRootPath/testChildPathTwo", true, null))); /* * // 删除子目录节点 zk.delete("/testRootPath/testChildPathTwo",-1); * zk.delete("/testRootPath/testChildPathOne",-1); // 删除父目录节点 * zk.delete("/testRootPath",-1); // 关闭链接 zk.close(); */ } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } } }
对于生成ZooKeeper的实例,最后一个参数能够指定一个Watch:
ZooKeeper zk = new ZooKeeper("localhost:" + CLIENT_PORT, ClientBase.CONNECTION_TIMEOUT, new Watcher() { // 监控全部被触发的事件 public void process(WatchedEvent event) { System.out.println("已经触发了" + event.getType() + "事件!"); } });
当对目录节点监控状态打开时,一旦目录节点的状态发生变化,Watcher 对象的 process 方法就会被调用。
Zookeeper 从设计模式角度来看,是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理你们都关心的数据,而后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者作出相应的反应,从而实现集群中相似 Master/Slave 管理模式。
下面详细介绍这些典型的应用场景,也就是 Zookeeper 到底能帮咱们解决那些问题?下面将给出答案。
分布式应用中,一般须要有一套完整的命名规则,既可以产生惟一的名称又便于人识别和记住,一般状况下用树形的名称结构是一个理想的选择,树形的名称结构是一个有层次的目录结构,既对人友好又不会重复。说到这里你可能想到了 JNDI,没错 Zookeeper 的 Name Service 与 JNDI 可以完成的功能是差很少的,它们都是将有层次的目录结构关联到必定资源上,可是 Zookeeper 的 Name Service 更加是普遍意义上的关联,也许你并不须要将名称关联到特定资源上,你可能只须要一个不会重复名称,就像数据库中产生一个惟一的数字主键同样。
Name Service 已是 Zookeeper 内置的功能,你只要调用 Zookeeper 的 API 就能实现。如调用 create 接口就能够很容易建立一个目录节点。
配置的管理在分布式应用环境中很常见,例如同一个应用系统须要多台 PC Server 运行,可是它们运行的应用系统的某些配置项是相同的,若是要修改这些相同的配置项,那么就必须同时修改每台运行这个应用系统的 PC Server,这样很是麻烦并且容易出错。
像这样的配置信息彻底能够交给 Zookeeper 来管理,将配置信息保存在 Zookeeper 的某个目录节点中,而后将全部须要修改的应用机器监控配置信息的状态,一旦配置信息发生变化,每台应用机器就会收到 Zookeeper 的通知,而后从 Zookeeper 获取新的配置信息应用到系统中。
集群管理(Group Membership)
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 容易出现单点故障的问题。
Leader Election 关键代码:
void findLeader() throws InterruptedException { byte[] leader = null; try { leader = zk.getData(root + "/leader", true, null); } catch (Exception e) { logger.error(e); } if (leader != null) { following(); } else { String newLeader = null; try { byte[] localhost = InetAddress.getLocalHost().getAddress(); newLeader = zk.create(root + "/leader", localhost, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL); } catch (Exception e) { logger.error(e); } if (newLeader != null) { leading(); } else { mutex.wait(); } } }
共享锁在同一个进程中很容易实现,可是在跨进程或者在不一样 Server 之间就很差实现了。Zookeeper 却很容易实现这个功能,实现方式也是须要得到锁的 Server 建立一个 EPHEMERAL_SEQUENTIAL 目录节点,而后调用 getChildren方法获取当前的目录节点列表中最小的目录节点是否是就是本身建立的目录节点,若是正是本身建立的,那么它就得到了这个锁,若是不是那么它就调用 exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化,一直到本身建立的节点是列表中最小编号的目录节点,从而得到锁,释放锁很简单,只要删除前面它本身所建立的目录节点就好了。
同步锁的关键代码
void getLock() throws KeeperException, InterruptedException{ List<String> list = zk.getChildren(root, false); String[] nodes = list.toArray(new String[list.size()]); Arrays.sort(nodes); if(myZnode.equals(root+"/"+nodes[0])){ doAction(); } else{ waitForLock(nodes[0]); } } void waitForLock(String lower) throws InterruptedException, KeeperException { Stat stat = zk.exists(root + "/" + lower,true); if(stat != null){ mutex.wait(); } else{ getLock(); } }
Zookeeper 能够处理两种类型的队列:
- 当一个队列的成员都聚齐时,这个队列才可用,不然一直等待全部成员到达,这种是同步队列。
- 队列按照 FIFO 方式进行入队和出队操做,例如实现生产者和消费者模型。
同步队列用 Zookeeper 实现的实现思路以下:
建立一个父目录 /synchronizing,每一个成员都监控标志(Set Watch)位目录 /synchronizing/start 是否存在,而后每一个成员都加入这个队列,加入队列的方式就是建立 /synchronizing/member_i 的临时目录节点,而后每一个成员获取 / synchronizing 目录的全部目录节点,也就是 member_i。判断 i 的值是否已是成员的个数,若是小于成员个数等待 /synchronizing/start 的出现,若是已经相等就建立 /synchronizing/start。
同步队列
void addQueue() throws KeeperException, InterruptedException{ zk.exists(root + "/start",true); zk.create(root + "/" + name, new byte[0], Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); synchronized (mutex) { List<String> list = zk.getChildren(root, false); if (list.size() < size) { mutex.wait(); } else { zk.create(root + "/start", new byte[0], Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } } }
当队列没尽是进入 wait(),而后会一直等待 Watch 的通知,Watch 的代码以下:
public void process(WatchedEvent event) { if(event.getPath().equals(root + "/start") && event.getType() == Event.EventType.NodeCreated){ System.out.println("获得通知"); super.process(event); doAction(); } }
FIFO 队列用 Zookeeper 实现思路以下:
实现的思路也很是简单,就是在特定的目录下建立 SEQUENTIAL 类型的子目录 /queue_i,这样就能保证全部成员加入队列时都是有编号的,出队列时经过 getChildren( ) 方法能够返回当前全部的队列中的元素,而后消费其中最小的一个,这样就能保证 FIFO。
下面是生产者和消费者这种队列形式的示例代码:
生产者代码
boolean produce(int i) throws KeeperException, InterruptedException{ ByteBuffer b = ByteBuffer.allocate(4); byte[] value; b.putInt(i); value = b.array(); zk.create(root + "/element", value, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT_SEQUENTIAL); return true; }
消费者代码
int consume() throws KeeperException, InterruptedException{ int retvalue = -1; Stat stat = null; while (true) { synchronized (mutex) { List<String> list = zk.getChildren(root, true); if (list.size() == 0) { mutex.wait(); } else { Integer min = new Integer(list.get(0).substring(7)); for(String s : list){ Integer tempValue = new Integer(s.substring(7)); if(tempValue < min) min = tempValue; } byte[] b = zk.getData(root + "/element" + min,false, stat); zk.delete(root + "/element" + min, 0); ByteBuffer buffer = ByteBuffer.wrap(b); retvalue = buffer.getInt(); return retvalue; } } } }
Zookeeper 做为 Hadoop 项目中的一个子项目,是 Hadoop 集群管理的一个必不可少的模块,它主要用来控制集群中的数据,如它管理 Hadoop 集群中的 NameNode,还有 Hbase 中 Master Election、Server 之间状态同步等。 本文介绍的 Zookeeper 的基本知识,以及介绍了几个典型的应用场景。这些都是 Zookeeper 的基本功能,最重要的是 Zoopkeeper 提供了一套很好的分布式集群管理的机制,就是它这种基于层次型的目录树的数据结构,并对树中的节点进行有效管理,从而能够设计出多种多样的分布式的数据管理模型,而不只仅局限于上面提到的几个经常使用应用场景。