标签:
高可用的高性能的分布式系统协调服务。局部不可用是分布式系统的固有特征,ZooKeeper可以很好的地处理这种情况。
下面从三个方面来理解ZooKeeper服务:数据模型、操作、实现
可以把zookper看成一个文件系统,文件系统中的所有文件形成一个数状结构,zookeeper维护着这样的树形层次结构,树中的节点称为znode。每个znode有一个与之相关联的ACL(Access Control List)。这种数据模型示意图如下:
znode通过路径被引用,而且要采用绝对路径,即必须以/开头。znode存储的数据要<1m。
znode类型
短暂znode:回话结束,zookeeper就会把短暂znode删除,短暂znode不可以有子节点。
持久znode:回话结束也不会被删除,除非客户端明确要删除此znode,持久znode可以有子节点。
对于在特定时刻需要知道有哪些分布式资源可用的应用来说,使用短暂znode比较合适。
znode的观察机制
znode以某种方式发生变化时,“观察”(watch)机制可以让客户端得到通知。可以针对ZooKeeper服务的“操作”来设置观察,该服务的其他操作可以触发观察。比如,客户端可以对某个客户端调用exists操作,同时在它上面设置一个观察,如果此时这个znode不存在,则exists返回false,如果一段时间之后,这个znode被其他客户端创建,则这个观察会被触发,之前的那个客户端就会得到通知。
ZooKeeper有9种基本操作:
操作 |
描述 |
create |
创建一个znode(必须有父节点) |
delete |
删除一个znode(该znode不能有任何子节点) |
exists |
测试一个znode是否存在,并且查询它的元数据 |
getACL,setACL |
获取/设置一个znode的ACL |
getChildren |
获取一个znode的子节点列表 |
getData,setData |
获取/设置一个znode所保存的数据 |
sync |
将客户端的znode视图与ZooKeeper同步 |
Zookeeper中的更新操作是有条件的。在使用delete或者setData操作时必须提供被更新znode的版本号,如果版本号不匹配,则更新操作失败。
API
目前主要有java和C两种客户端,每种操作都有同步和异步两种执行方式。
观察触发器
可以设置观察的操作:exists,getChildren,getData
可以触发观察的操作:create,delete,setData
观察触发器 |
|||||
设置观察的操作 |
create |
delete |
setData |
||
znode |
子节点 |
znode |
子节点 |
||
exists |
NodeCreated |
NodeDeleted |
NodeDataChanged |
||
getData |
NodeDeleted |
NodeDataChanged |
|||
getChildren |
NodeChildrenChanged |
NodeDeleted |
NodeChildrenChanged |
NodeCreated:节点创建事件
NodeDeleted:节点被删除事件
NodeDataChanged:节点数据改变事件
NodeChildrenChanged:节点的子节点改变事件
ACL
每个znode被创建时都会带有一个ACL列表,用于决定谁可以对它执行何种操作。
ACL权限 |
允许的操作 |
CREATE |
create(子节点) |
READ |
getChildren getData |
WRITE |
setData |
DELETE |
delete(子节点) |
ADMIN |
setACL |
每个ACL都是身份验证模式、符合该模式的一个身份和一组权限的组合。身份验证模式有三种: digest:用户名,密码
host:通过客户端的主机名来识别客户端
ip: 通过客户端的ip来识别客户端
所以我们可以类似这样构建一个ACL类:
new ACL(Perms.READ,new Id("host","example.com"));
这个ACL对应的身份验证模式是host
符合该模式的身份是example.com
权限的组合是:READ
Zookeeper有两种运行模式:
独立模式(standalone mode):只运行在一台服务器上,适合测试环境
复制模式(replicated mode):运行于一个集群上,适合生产环境,这个计算机集群被称为一个“集合体”(ensemble)。Zookeeper通过复制来实现高可用性,只要集合体中半数以上的机器处于可用状态,它就能够保证服务继续。为什么一定要超过半数呢?这跟Zookeeper的复制策略有关:zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。
生产环境,zookeeper集群的服务器数目应该是奇数。
领导者
1.管理写请求
跟随者
1.响应客户端的读请求
2.负责把客户端提交的写请求转发给领导者
客户端与zookeeper集群中的某个服务器建立连接,就建立了一个回话,回话可以过期,可以设置ping周期来防止回话过期。
滴答(tick time):定义了zookeeper中的基本时间周期,其他设置都是根据滴答参数来定义的。2个滴答=<回话时间<=20个滴答时间
CONNECTING,CONNECTED,CLOSED
---------------------------------------------------------------------------------------------------------------------------------------
更多查看(以下摘自官网):http://zookeeper.apache.org/doc/r3.3.2/zookeeperOver.html
Zookper是一种分布式的,开源的,应用于分布式应用的协作服务。它提供了一些简单的操作,使得分布式应用可以基于这些接口主要实现了配置管理、命名服务、提供分布式同步以及集群管理。Zookper很容易编程接入,它使用了一个和文件树结构相似的数据模型。可以使用Java或者C来进行编程接入。
众所周知,分布式的系统协作服务很难有让人满意的产品。这些协作服务产品很容易陷入一些诸如竞争选择条件或者死锁的陷阱中。Zookper的目的就是将分布式服务不再需要由于协作冲突而另外实现协作服务。
Zookeeper通过一种和文件系统很像的层级命名空间来让分布式进程互相协同工作。这些命名空间由一系列数据寄存器组成,我们也叫这些数据寄存器为znodes。这些znodes就有点像是文件系统中的文件和文件夹。和文件系统不一样的是,文件系统的文件是存储在存储区上的,而zookeeper的数据是存储在内存上的。同时,这就意味着zookeeper有着高吞吐和低延迟。
Zookeeper实现了高性能,高可靠性,和有序的访问。高性能保证了zookeeper能应用在大型的分布式系统上。高可靠性保证它不会由于单一节点的故障而造成任何问题。有序的访问能保证客户端可以实现较为复杂的同步操作。
ZooKeeper Service
组成Zookeeper的各个服务器必须要能相互通信。他们在内存中保存了服务器状态,也保存了操作的日志,并且持久化快照。只要大多数的服务器是可用的,那么Zookeeper就是可用的。
客户端连接到一个Zookeeper服务器,并且维持TCP连接。并且发送请求,获取回复,获取事件,并且发送连接信号。如果这个TCP连接断掉了,那么客户端可以连接另外一个服务器。
Zookeeper使用数字来对每一个更新进行标记。这样能保证Zookeeper交互的有序。后续的操作可以根据这个顺序实现诸如同步操作这样更高更抽象的服务。
Zookeeper的高效更表现在以读为主的系统上。Zookeeper可以在千台服务器组成的读写比例大约为10:1的分布系统上表现优异。
Zookeeper的命名空间的结构和文件系统很像。一个名字和文件一样使用/的路径表现,zookeeper的每个节点都是被路径唯一标识
ZooKeeper‘s Hierarchical Namespace
下图显示了ZooKeeper服务的高级组件服务。除了请求处理器,Zookeeper服务器组的每个服务器复制他们自己的每个组件。
ZooKeeper Components
replicated database是一个存储在内存中的包含整个数据树的结构。所有的更新操作都做日志到硬盘上了。并且写操作在作用在数据库的时候会序列化存储到硬盘上。
每个ZooKeeper服务器都连接了许多个客户端。客户端连接到一个服务器来提交请求。
---------------------------------------------------------------------------------------------------------------------
Zookeeper 安装与配置
最新的代码可以到 Zookeeper 的官网:http://mirrors.cnnic.cn/apache/zookeeper/下载。Zookeeper功能强大,但是安装却十分简单,下面重点以伪分布式模式来介绍 Zookeeper 的安装
标签:
原文地址:http://www.cnblogs.com/wjoyxt/p/4182908.html