Zookeeper是一个高可用性,高性能的协调服务

Zookeeper解决哪些问题在分布式应用中,经常会出现部分失败的情况,即当节点间传递消息的时候由于网络或者接收者进程死掉等原因,发送者无法知道接收者是否收到消息。

由于部分失败是分布式系统固有的特征因此zookeeper并不能避免部分失败,但是它可以帮你在部分失败的时候进行正确处理

为了解决这个问题Zookeeper具有以下特征:1:zookeeper提供丰富的构件(building block)来实现很多协调数据结构和协议
2:访问原子性,客户端要么读到所有数据,要么读取失败,不会出现只读取部分的情况
3:zookeeper运行在一组机器上,具有高可用性,帮助系统避免单点故障,同时删掉故障服务器
4:顺序一致性:任意客户端的更新请求会被按照发送顺序提交
5:单一系统映像:当一台服务器故障,导致它的客户端需要连接其它服务器的时候,所有更新晚于故障服务器的服务器都不会接收请求,一直到更新赶上故障服务器
6:及时性:任何客户端能看到的滞后都是有限的,不会超过几十秒,且提供sync操作强制客户端所连的服务器与领导者同步
7:会话:每个客户端连接时会尝试连接到配置列表中的一台服务器,一旦失败会自动连接另一台服务器依次类推,知道成功连接一台服务器,从而创建一个会话,客户端可以位每个会话设置超时时间,一旦会话过期,则所有短暂znode会丢失,因为zookeeper会自动发送心跳包,所以很少发生
8:约会机制(rendezvous),在交互的过程中,被协调的各方不许要事先彼此了解,甚至不必同时存在
9:ACL:zookeeper提供了digest(通过用户名密码),host(通过主机名),ip(通过ip地址)3种身份验证模式,依赖与zookeeper的身份验证机制每个ACL都是一个身份对应一组权限,如果我们要给demo.com的客户端域一个读权限在Java语言中可以这样创建:
new ACL(Perms.READ, new Id("host", "demo.com"));
Ids.OPEN_ACL_UNSAFE是将所有ADMIN之外的权限授予每个人
另zookeeper还可以集成第三方的身份验证系统

10:提供关于通用协调模式的开源共享资源库
11:高性能的(官方数据)对以写为主的工作负载来说使用5台不错的机器基准吞吐量达到10000+

Zookeeper原理zookeeper使用zab协议,类似Paxos算法但在操作方面却是不同的,该协议包括2个不断重复的阶段
领导者选举:集群所有机器一起选出一台领导者,其它机器成为跟随者,一旦半数以上的跟随者将状态同步,表示这个阶段完成(官方数据这个阶段秩序200毫秒)
原子广播:所有机器将写操作转发给领导者,领导者再将更新广播给跟随者,只有半数以上的跟随者同步修改之后领导者才会提交更新,客户端才能收到更新成功的信息

它的核心是一个精简的文件系统,形成一个树状的数据结构,统一使用节点(znode)的概念,节点可以有子节点,也可以用来保存数据,并且有一个关联的ACL,因为zookeeper被设计来实现协调服务,通常使用小数据文件所以znode能存储的数据限制在1M以内
zookeeper采用斜杠分割的Unicode字符串来做引用类似文件系统路径,但必须是标准的,不支持./这种特殊字符,使用/zookeeper子树来保存管理信息
客户端与服务器通信采用tcp长连接,客户端和服务器通过心跳来保持seesion的连接。当session失效时临时节点会被删除。
通过监控节点以及节点的变化来实现功能,例如集群管理,配置的集中管理,分布式锁等
zookeeper通过复制实现高可用性,只要集群中半数以上的机器可用,就能提供服务,所以一个集群通常要奇数台机器

zookeeper的生命周期有以下3个状态:CONNECTION,CONNECTED,CLOSED
新产生的zookeeper实例是CONNECTION状态,通过建立连接进入CONNECTED状态,当zookeeper实例断开和重连的时候,zookeeper实例在CONNECTED和COONECTION之间转换,调用close方法或者会话超时会进入到CLOSE状态且不能恢复

znode特性
znode有2种,短暂node和持久node,在创建时确定,并且不能修改,短暂node在客户端session结束的时候会被移除
且不可以创建任何类型的子节点
如果在创建znode的时候设置了顺序标识,那么此znode会通过父节点维护的一个单调递增的计数器来添加一个顺序号,这个顺序号可以被用来进行全局排序
watch机制可以让客户端得到znode的变化,观察只能触发一次,为了能多次收到通知,客户端需要重新注册所需的观察