ZooKeeper是一个分布式、开源的分布式应用协调服务。
设计目标
简单的数据模型
在ZooKeeper中,分布式进程之间的相互协调,是通过类似于标准文件系统的层次命名空间的(图如下)。类似于文件和目录,每个组成部分称之为znode,znode是zookeeper中的最小数据单位,但是与存储的文件系统不同的是,这些数据是存在于内存的,所以ZooKeeper可以实现高吞吐量和低延迟。
另外一个不同的是,节点既可以有自己的数据,也可以有自己的子节点,在存储系统中,是不可能自己既是目录,还是文件的。Znode中有一个stat结构,其中包含数据更改、ACL更改和时间戳的版本号,以允许缓存验证和协调更新。
节点有4种类型:
- 持久化节点:永久保存在服务器上,除非主动删除
- 持久化有序节点:节点的名称后加入有序的数字,类似自增长id
- 临时节点:在会话时间内保持,类似web项目的session
- 临时有序节点:临时节点的名称后加入有序的数字,类似自增长id
可复制
这个特性,支持他可以做集群,只要大多数服务是可用的,那ZooKeeper就是可用的。
客户端连接ZooKeeper服务时,需要知道每个ZooKeeper的地址。当客户端连接到单个ZooKeeper时,会维护一个TCP连接,通过它发送请求、获取响应、获取监视事件和发送心跳。如果到服务器的TCP连接中断,客户端将连接到另一台服务器。
有序
ZooKeeper用一个数字来标记每个更新,这个数字反映了所有ZooKeeper事务的顺序。
快
数据是存在于内存的,所以ZooKeeper可以实现高吞吐量和低延迟。
特点
- 顺序一致性:客户端发起的事务请求,在也会顺序的应用在Zookeeper中。
- 原子性:要么在所有的Zookeeper中都成功,要么都失败,不会有部分成功,部分失败的情况。
- 单一镜像:不管连的是哪个服务器,客户端读取的数据是一样的
- 可靠性:一旦事务成功提交,那就会保留下来
- 及时性:客户端在一定范围时间内,读取的数据是一样的
Watcher
事件监听器。客户端可以在znode上设置监听,当znode发生变化时,这个监听就会被移除,然后客户端就会收到通知。要想不停的监听,就需要继续注册。
ACL
控制节点访问权限
- CREATE:创建子节点的权限
- DELETE:可以删除子节点(仅下一级节点)
- WRITE:更新子节点的权限
- READ:读取节点数据及显示子节点列表
- ADMIN:设置节点ACL权限
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。