zookeeper是什么、做什么用
- 格式：pdf
- 大小：121.69 KB
- 文档页数：2
zookeeper是什么、做什么⽤
⼀、什么是zookeeper
ZooKeeper是⼀个分布式的，开放源码的分布式应⽤程序协调服务，是Google的Chubby⼀个开源的实现，是Hadoop和Hbase的重要组件。它是⼀个为分布式应⽤提供⼀致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
简单来说，zookeeper = ⽂件系统 + 监听通知机制
⼆、⽂件系统
zookeeper有着与linux类似的⽂件系统，区别是，linux的⽬录就是⽬录，⽂件就是⽂件。⽽zookeeper中只有⼀个znode概念，本⾝可以做为“⽂件”存储⼀定的数据，⼜可以做为“⽬录”存在。/* +---+ |/ | +-+-+ | | +------+ +--|config| | +--+---+ | | +-----+ | +-----|ip | | | +-----+ | | +-----+ | +-----|port | | +-----+ | | +------+ +--|apps | +--+---+ | +-----+ +-----|app1 | | +-----+ | +-----+ +-----|app2 | +-----+*/ znode共分为四种：
1、PERSISTENT-持久化⽬录节点
此节点在客户端与zookeeper断开连接之后，依然存在，需要主动删除。
2、PERSISTENT_SEQUENTIAL-持久化顺序编号⽬录节点
同样地，此类节点也是需要主动删除，不会随着客户端的断开连接⽽删除。与PERSISTENT不同的是，zookeeper会给此类节点进⾏编号。如：app0000003362。0000003362为zookeeper给的编号，⾃动递增。由于此编号是⼀个有符号整形（4字节），当它超过2147483647时，将会溢出。
3、EPHEMERAL-临时⽬录节点
与PERSISTENT不同的是，此类节点会在客户端与zookeeper断开连接之后被删除。由于其⽣命周期与连接有关，所以其不可以有⼦节点。
4、EPHEMERAL_SEQUENTIAL-临时顺序编号⽬录节点
与PERSISTENT_SEQUENTIAL类似拥有zookeeper的⾃动编号，区别是会在客户端与zookeeper断开连接之后被删除，且不可以有⼦节点。
值得注意的是，同路径下，同名znode只能被创建⼀次。且每个znode最多只可以存储1M数据。
三、监听通知机制
客户端注册监听它关⼼的⽬录节点，当⽬录节点发⽣变化（数据改变、被删除、⼦⽬录节点增加删除）时，zookeeper会通知客户端。
四、 实际应⽤
基于⽂件系统与监听通知机制，zookeeper有诸多应⽤场景。 1、命名服务（基于⽂件系统）
名称在所有计算机系统中起着重要的作⽤，它们⽤来共享资源，唯⼀标识实体，指向位置等。命名的对象可以有多种类型，⽽且可被⼀些不同的服务来访问。命名服务器可根据给定的名字来进⾏资源或对象的地址定位，并获取有关的属性信息。（百度百科）
简单来说，就是通过名字来获取对应资源/服务地址。利⽤znode的唯⼀性，可以创建⼀个全局节点，将对应的信息记录在znode中。需要使⽤对应资源的服务直接获取此节点的信息即可。
2、配置管理（基于⽂件系统与监听通知机制）
服务有⾃⼰的配置，⽽同⼀个服务可多点部署。如果采⽤配置⽂件的形式，在修改配置的时候，需要同步⽂件⾄所有机器，再通知程度动态加载，或者直接重启。若存在这种情况，整个后台存在⼀份共享配置（路由信息等），⽽在⼀次修改中，只需要同步到某个服务（扩容、增加下游节点等）。长久之后，会出现不同服务的配置不同的情况（虽然对于他们⾃⼰所使⽤的部门是最新的）。此时可以通过配置中⼼来解决此类问题，所有配置都从配置中⼼中读取，统⼀管理。
⾃⼰实现配置中⼼毕竟是有代价。⽽利⽤zookeeper，完全可以实现配置中⼼的功能。将对应信息存储到对应的znode中，服务只需要监听⾃⼰关⼼的配置（znode）。⼀旦znode发⽣变化，利⽤watcher通知所有监听此znode的客户端（对于zookeeper⽽⾔，服务是他的客户端），从⽽更新配置。
3、集群管理（基于⽂件系统与监听通知机制）
当⼀个服务部署成集群的时候，就会有两个问题：机器的加⼊与退出，master的选举。可以在zookeeper⾥创建⼀个持久化znode A，然后让本集群所有的服务在A下创建临时znode B，需要知道此集群的服务监听A。当新机器加⼊时，创建新的B，旧机器离开（宕机、缩容等）时，⾃动删除B。不管是创建，还是删除，A都发⽣了变化，利⽤watcher通知所有监听者。于是⼤家都知道本集群的情况了。
对于master选举，同样也可以在zookeeper⾥创建⼀个持久化znode C，⽽后所有服务在C⾥创建临时顺序编号⽬录节点。每次选择编号最⼤或者最⼩的做为master。由于临时顺序编号⽬录节点的编号是⾃增的，若选择最⼤的做为master，当有新机器加⼊时，新机器就会成为master。⽽选择最⼩编号做为master，只要其不退出（znode没删），就不会产⽣切换master的情况，对数据来说是最安全的。
4、分布式锁（基于⽂件系统与监听通知机制）
有⼀个程序，有两个线程，都对相同变量进⾏100w次++操作。未加锁的情况下，得到的结果并不是200w。同样，在⼀个集群中，如果同时修改相同资源，也会出现相互覆盖的情况。此时，需要使⽤到分布式锁来处理此类问题。要开始修改此资源之前，先获取锁。获取成功之后才可以进⾏修改操作。由于zookeeper中，znode的唯⼀性，可以利⽤它来实现分布式锁服务。需要获取锁时，在指定路径下创建znode（⾮⾃动编号），需要释放时，删除此znode。若创建失败，则认为当前已有其它服务抢到了锁。
若创建的是⾮⾃动编号的znode，会有⼀个问题。每次都是集群中所有服务竞争同⼀把锁，会出现⼀个服务抢到多次，⽽其它服务⼀次都不成功的情况。此时可以将其修改为⾃动编号的znode，并监听对应⽗znode。每次需要锁时，创建⼀个⾃动编号的znode。若⾃⼰创建的znode在所有znode中编号最⼩，则认为⾃⼰抢到了锁。解锁（删除znode）之后，⼜会通知整个集群。这样不仅实现了分布式锁，⽽且⼈⼈有份，有序进⾏。
五、参考链接
