一、概述
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应,从而实现集群中类似Master/Slave管理模式。
二、应用场景
提供的服务包括:
- 分布式消息同步和协调机制
- 服务器节点动态上下线
- 统一配置管理
- 负载均衡
- 集群管理
- 。。。。。。
三、数据结构
zookeeper的数据模型的结构和unix文件系统很相似,整体上看是一颗目录树,每一个节点称为ZNode(每个节点不但有目录名称,还必须要有值,类似于键值对)。
zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构,其上的每一个节点,我们称之为”znode”,每一个znode默认能够存储1MB的数据,每个ZNode都可以通过其路径唯一标识。
四、特点
- Zookeeper:一个领导者(leader),多个跟随者(follower)组成的集群。
- Leader负责进行投票的发起和决议,更新系统状态和数据
- Follower用于接收客户请求并向客户端返回结果,在选举Leader过程中参与投票,follower没有权限更新数据,只能读数据。
- 集群中只要有半数以上节点存活,Zookeeper集群就能正常服务。例如:3台设备挂了1台,还是能继续工作,挂了两台就不工作了。
- 全局数据一致:每个server保存一份相同的数据副本,client无论连接到哪个server,数据都是一致的。
- 更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行,相当于一个队列,先进先出。
- 数据更新原子性,一次数据更新要么成功,要么失败。
- 实时性,在一定时间范围内,client能读到最新数据。
五、节点类型
Znode有四种类型:
- 短暂(ephemeral):客户端和服务器端断开连接后,创建的节点自己删除。
- 持久(persistent):客户端和服务器端断开连接后,创建的节点不删除。
- 持久化顺序编号目录节点(PERSISTENT_SEQUENTIAL):客户端与zookeeper断开连接后,该节点依旧存在,只是Zookeeper给该节点名称进行顺序编号,顺序编号有小到大。
- 临时顺序编号目录节点(EPHEMERAL_SEQUENTIAL):客户端与zookeeper断开连接后,该节点被删除,只是Zookeeper给该节点名称进行顺序编号,顺序编号有小到大。
六、选举机制
- 半数机制:集群中半数以上机器存活,集群可用。所以zookeeper适合装在奇数台机器上。
- zookeeper没有指定leader和follower,它是由内部的选举机制产生的。
- 选举过程:
假如有5台服务器,编号分别为server1~5,
- 当server1启动时,它向配置中的server发出请求,但是其他服务器没有启动,没有回应,所以zookeeper一直在looking状态。
- 当server2启动时,开始与server1进行交流,开始选举,它们首先分别给自己一票,但是这样没法选举出leader,所以服务器号数低的向高的投票,这时候server2有两票,