百度精准搜索,排名优化关键词,软件技术主要学什么就业前景,游戏源代码网站Zookeeper简介
Zookeeper的数据模型
层次化的目录结构#xff0c;命名符合常规文件系统规范每个节点在zookeeper中叫做znode#xff0c;并且有一个唯一的路径标识节点znode可以包含数据和子节点#xff0c;但是EPHEMERAL类型的节点不能有子节点Znode中的互刷可以有多个版本…Zookeeper简介
Zookeeper的数据模型
层次化的目录结构命名符合常规文件系统规范每个节点在zookeeper中叫做znode并且有一个唯一的路径标识节点znode可以包含数据和子节点但是EPHEMERAL类型的节点不能有子节点Znode中的互刷可以有多个版本比如某一个路径下存在多个数据版本那么查询这个路径下的数据就需要带上版本号客户端应用可以在节点上设置监视器节点不支持部分读写而是一次性完整读写
Zookeeper的节点
Znode有两种类型短暂的ephemeral和持久节点persistentZnode的类型在创建时确定并且不能修改短暂的Znode的客户端会话结束zookeeper会将该短暂znode删除短暂znode不可以有子节点持久Znode不依赖客户端会话只有当客户端明确要删除改Znode时候才会被删掉Znode有四种形式的目录节点 persistent 是永久节点persistent_sequential 是永久有序节点ephemeral 是临时节点ephemeral_sequential 是临时有序节点
Zookeeper的角色
领导者leader负责进行投票和发起决议更新系统状态学习者learner包括跟随者follower和观察者observerfollower用于接收客户端请求并向客户端返回结果在选主过程中参与投票观察者Observer可以接受客户端连接将写请求转发给leader但observer不参加投票过程只同步leader的状态observer的目的是为了扩展系统提高读取速度。客户端client请求发起方
Zookeeper的顺序号
创建Znode时设置顺序标识znode名称后面会附加一个值顺序号是一个单递增的计数器由父节点维护在分布式系统中顺序号可以被用于所有事件进行全局排序这样客户端可以通过顺序号推断事件的顺序
Zookeeper的读写机制
zookeeper是一个由多个server组成的集群一个leader多个follower每个server保存一份数据副本全局数据一致分布式读写更新请求转发由leader实施
Zookeeper的保证
更新请求顺序进行来自同一个client的更新请求按其发送顺序依次执行数据更新原子性依次数据更新要么成功要么失败全局唯一数据视图client无论链接到哪个server数据视图都是一致的实时性在一定事件范围内client能督导的最新数据
Zookeeper的api接口
String createString pathbyte[] data, List acl, CreateMode createMode: 创建一个给定目录节点的path并给他设置数据CreateMode标识有四种形式目录分别是PERSISTENT持久化目录节点这个目录节点存储的数据不会丢失PERSISTEN_SEQUENTIAL顺序自动编号的目录节点这种节点会根据当前已经存在的节点数自动加1然后返回给客户端已经成功创建的目录节点名EPHEMERAL临时目录节点一旦创建这个节点的客户端与服务器断开也就是session超时这种节点会被自动删除EPHEMERAL_SEQUENTIAL临时自动编号节点 Stat existsString path boolean watch 判断某个path是否存在并设置是否监控这个目录节点这里的watcher是在创建zookeeper实例时指定的watcherexists方法还有一个重载方法可以执行特定的watcher Stat existsString path Watcher watcher 重载方法这里给某个目录节点设置特定的watcherwatcher在zookeeper是一个核心功能watcher可以监控目录加点的数据变化以及子目录的变化一旦这些状态发生变化服务器就会通知所有设置在这个目录节点上的watcher从而每个客户端都很快知道他所关注的节点的状态发生变化而做出相应的反应 …
观察watcher
watcher在Zookeeper中是一个核心功能watcher可以监控目录节点的数据变化以及子目录的变化一旦这些状态发生变化服务器就会通知所有设置在这个目录节点上的 Watcher从而每个客户端都很快知道它所关注的目录节点的状态发生变化从而做出相应反应一个节点可以设置多个watcher也就是每个客户端都可以在一个节点上设置观察可以设置观察的操作existsgetChildren getData可以触发观察操作create deletesetData
写操作与zookeeper内部事件的对应关系 写操作与watcher的对应关系 每个znode被创建时候都会带有一个ACL列表用于决定谁可以对他执行何种操作 ACL访问控制列表Access Control List ACL
身份验证模式有三种 digest用户名密码host通过客户端的主机名来识别客户端ip通过客户端的ip来识别客户端 new ACLPerms.READ new Id(“host”, “example.com”); 这个ACL对应身份验证模式是host符合改模式的身份是exmple.com权限组合是READ
Znode的节点状态 Zookeeper工作原理
zookeeper的核心是原子广播这个机制保证了各个server之间的同步。实现这个机制的协议叫Zab协议。Zab协议有两种模式他们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后Zab就进入恢复模式当领导者被选举出来且大多数server的完成了和leader的状态同步后恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。一旦leader已经和多数follower进行了状态同步后他就可以开始广播消息即进入广播状态。这时候当一个server加入zookeeper服务中他会在恢复模式下启动发现leader并和leader进行状态同步。待到同步结束他也参与消息广播。Zookeeper服务一直维持在broadcast状态直到崩溃或者leader失去了大部分followers支持。广播模式需要保证proposal被按顺序处理因此ZK采用了递增的事务id号码zxid来保证所有的提议proposal都被踢出的时候加上了zxid。实现中zxid是一个64位的数字它高32位是epoch用来标识leader关系是否改变每次一个leader被选出来他都会有一个新的epoch低32位是个递增计数当leader崩溃或者leader失去大多数follower这时候zk进入恢复模式恢复模式需要重新选举出一个新的leader让所有server都恢复到一个正确的状态。
Leader选举
每个server启动以后都询问其他Server他要投票给谁对于其他server的询问server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid系统启动时每个server都会推荐自己收到所有Server回复后就计算出zxid最大的那个Server并将这个Server相关信息设置成下一次要投票的Server计算这过程中获得票数最大的server为胜者如果获胜者的票数超过半数则该server被选为leader。否则继续这个过程知道leader被选出来leader就会开始邓艾server链接Follower链接leader将最大的zxid发送给leaderLeader根据fillower的zxid确定同步点完成同步后通知follow已经成为uptodate状态Follower收到uptodate消息后又可以重新接受client的请求进行服务了
应用场景1-统一命名服务
分布式应用中通常需要有一套完整的命名规则既能够产生唯一的名称又便于人识别和记住通常情况下用树形结构是一个理想的选择树形的名称结构是一个有层次的目录结构即对人友好又不会重复。Name Service是Zookeeper内置的功能只要调用ZookeeperApi就能实现如调用create接口就可以很容易创建一个目录节点从而得到一个全局唯一的path这个path就可以作为一个名称。阿里的分布式服务框架Dubbo中使用Zookeeper来作其命名服务维护全局的服务地址列表
服务提供者在启动时候想ZK上指定节点/dubbo/${serviceName}/providers 目录下写入自己的URL地址这个操作就完成了服务的发布。服务消费者启动的时候订阅/dubbo/serviceName/providers目录下的提供者URL地址并向/dubbo/{serviceName}/consumer目录下写入自己的URL地址注意所有想ZK注册的地址都是临时节点这样就能够保证服务提供者和消费者能够自动感应资源的变化另外Dubbo还有针对服务力度的监控方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息
应用场景2-配置管理
配置管理在分布式应用环境中很常见例如同一个应用系统需要多台PCServer运行但是他们运行的应用系统的某些配置项是相同的如果需要修改这些相同的配置那么必须同时修改每台云溪这个应用系统的PCServer这样就非常麻烦而且容易出错将配置信息保存在Zookeeper的某个目录节点中然后将所有需要修改的应用机器监控配置信息的状态一旦配置信息变化每台机器就会收到Zookeeper的通知然后从Zookeeper获取新的配置信息应用到系统中。
应用场景3-集群管理
Zookeeper能够很容易的实现集群管理的功能如有多台Server组成一个服务器集群那么必须要有一个总管知道当前集群中每一台服务器的服务状态一旦有集群不能提供服务集群中其他集群必须知道从而做出调整重新分配服务策略。同当增加集群的服务能力时就会增加一台或者多台Server同样也需要让总管知道Zookeeper不仅能维护当前集群中集群的服务状态而且能够选出一个总管让这个总管来管理集群这就是Zookeeper的另一个功能Leader Election。他们的实现方式都是在Zookeeper上创建一个ephemeral类型的目录节点然后每个Server在他们创建目录节点的父目录节点上调用getChildrenString Pathboolean watch方法并设置watch为true由于是Ephemeral目录节点当创建他的Server死去这个目录节点也随之被删除所以Children将会变化这时候getChildren上的watch将会被调用所有其他Server就知道已经有某一台Server死去新增加Server也是同样的道理。Zookeeper如何实现Leader Election也就是选出一个Master Server和签名的一样每台Server 创建一个Ephemeral目录节点不同的是他还是一个SEQUENTIAL目录节点是一个有序的临时节点我们可以选出当前最小编号的Server是Master加入这个最小编号Server死去由于是Ephemeral节点死去的Server对应的节点也会被删掉所以当前的节点列表中会出现另外一个最小编号节点我们就选这个为当前Master这就实现动态选择Master避免了传统意义上单Master容易出现单节点故障问题。 zk.create(/testRootPath/testChildPath1,1.getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);zk.create(“/testRootPath/testChildPath2”,“2”.getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);zk.create(/testRootPath/testChildPath3,3.getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);zk.create(/testRootPath/testChildPath4,4.getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);System.out.println(zk.getChildren(/testRootPath, false));
//输出[testChildPath10000000000, testChildPath20000000001, testChildPath40000000003, testChildPath30000000002]规定最小编号的为Master所以我们水Servers节点做监控的时候得到服务器列表只要所有集群机器逻辑认为最小编号节点为master那么master就被选出这个master宕机znode就删除新列表推送新的列表在选出最小编号master这样就动态master选举LeaderElection关键代码 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(); } } }应用场景4-共享锁
共享锁在同一个进程中很容易实现但是在跨JVM不同Server之间就不好实现。Zookeeper却很容易实现这个功能实现方式也是需要获得锁的Server创建一个EPHEMERAL_SEQUENTIAL目录节点有序临时节点然后调用getChildren方法获取当前目录节点列表最小的目录节点是不是就是自己创建的目录节点如果正是自己创建的那么他就获得这个锁如果不是那么它就调用existsString pathboolean watch方法并且监控Zookeeper生目录节点列表的变化一直到自己创建的节点是列表中最小编号的目录节点从而获得锁释放锁很简单只要删除签名它自己所创建的目录节点就行了 - 同步锁关键代码如下
void getLock() throws KeeperException, InterruptedException{ ListString 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(); } }应用场景5-队列管理
Zookeeper可以处理两种类型的队列 当一个队列的成员都聚齐时这个队列才可用否则一直等待所有成员到大这种是同步队列队列按照FIFO方式进行入队和出队操作例如实现生产者消费者模型。 创建一个父目录/synchronizing每个成员都监控目录/synchronizing/start是否存在然后每个成员都加入这个队列创建/synchronizing/member_i的临时目录节点然后每个成员获取/synchronizing目录的所有目录节点判断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) { ListString 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) { ListString 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; } } }
}
应用场景6-负载均衡
这里的负载均衡是指的软负载均衡。分布式系统中都是多服务集群部署。服务消费者需要在集群中选择一个来执行相关业务就去比较经典的生产者消费者问题。消息中间件中发布者和订阅者的负载均衡linkedin开源的kafkaMQ和阿里开源的metaq都是zookeeper来做负载均衡这里以metaq为案例如下 生产者负载均衡metaq发送消息时候生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息因此metaq在运行过程中会吧broker和对应的分区信息全部注册到ZK指定节点上默认的策略是一个依次轮询的过程生产者在通过ZK获取分区列表后会按照brokerid和partition的顺序排列组织成一个有序的分区列表发送的时候按照从头到位循环往复的方式选择一个分区来发送消息。消费负载均衡在消费过程中一个消费者会消费一个或多个分区中的消息但是一个分区只会由一个消费者来消费。MetaQ的消费策略是:每个分区针对同一个group只挂载一个消费者如果同一个group的消费者数目大于分区数目则有部分消费者需要额外承担消费任务如果同一个group的消费者数目小于分区数目则又部分消费者需要额外承担消费任务。在某个消费者故障或者重启等情况下其他消费者会感知到这一个变化通过Zookeeper watch 消费者列表然后重新进行负载均衡保证所有分区都有消费者进行消费。
总结
Zookeeper作为Hadoop项目中子项目是Hadoop集群管理一个必不可少的模块主要用来控制集群中数量如他管理Hadoop集群中NameNode还有Hbase中Master ElectionServer之间状态同步等。Zookeeper提供了一套很好的分布式集群管理机制就是他这种基于层次型的目录树的数据结构并对树中节点进行有效管理从而可以设计出多种多样的分布式数据管理模型。
下一篇Zookeeper理解—ZAB协议
