概览
- 设计目标
- 是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用
- 简介
- 是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能
- 应用场景
- 担任服务生产者和服务消费者的注册中心(提供发布订阋服务)
- 服务生产者将自己提供的服务注册到Zookeepers中心,服务的消费者在进行服务调用的时候先到Zookeeper中查找服务,获取到服务生产者的详细信息之后,再去调用服务生产者的内容与数据
- 担任服务生产者和服务消费者的注册中心(提供发布订阋服务)
- 功能
- 集群管理：容错、负载均衡
- 配置文件的集中管理
- 集群的入口
题外话：为什么使用技术台服务器构成集群
答：拜占庭问题，假设集群中有n台服务器，剩下的服务数量必须大于n/2,2n和2n-1的容忍度是一样的，都是n-1,比如3台与4台服务器，最大运行宕机1台
概念总结
- ZooKeeper本身就是一个分布式程序(只要半数以上节点存活,ZooKeeper就能正常服务)为了保证高可用,最好是以集群形态来部暑
- Zookeeper,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么ZooKeeper本身仍然是可用的。
- ZooKeeper将数据保存在内存中,这也就保证了高吞吐量和低延迟(但是内存限制了能够存储的容量不太大,此限制也是保持znode中存储的数据量较小的进一步原因)。
- Zookeeper是高性能的。在“读”多于“写”的应用程序中尤其地高性能,因为“写”会导致所有的服务器间同步状态(“读”多于“写”是协调服务的典型场景。)
- ZooKeeper有临时节点的概念。当创建临时节点的客户端会话一直保持活动,瞬时节点就一直存在。而当会话终结时,瞬时节点被删除。持久节点是指一旦这个 Znode被创建了,除非主动进行Znode的移除操作,否则这个 Znode将一直保存在 Zookeeper上。
- Zookeeper底层其实只提供了两个功能:
- 管理(存储、读取)用户程序提交的数据;
- 为用户程序提供数据节点监听服务。
- 会话
- Zookeeper服务器与客户端会话，一个客户端连接是指客户端和服务器之间的一个TCP长连接，并通过这个连接接收服务器的watch事件通知，每个客户端都会有一个sessionId（作用？），全局唯一
- ZNode：“节点"分为两类,第一类同样是指构成集群的机器,我们称之为机器节点;第二类则是指数据模型中的数据单元,我们称之为数据节点--ZNode
- 版本
- Stat数据结构记录了三个数据版本
- verson:当前ZNode的版本
- cversion:前ZNode子节点的版本
- aversion:当前ZNode的ACL版本
- Stat数据结构记录了三个数据版本
- Watcher:该机制是Zookeeper实现分布式协调服务的重要特性
- ACL(accessControlLists)：进行权限控制
- CREATE:创建子节点的权限
- READ:获取节点数据和子节点列表的权限
- WRITE:更新节点数据的权限
- DELETE:删除子节点的权限
- ADMIN:设置节点ACL的权限
- ZooKeeper特点
- 顺序一致性:从同一客户端发起的事务请求,最终将会严格地按照顺序被应用到ZooKeeper中去
- 原子性:所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,也就是说,要么整个集群中所有的机器都成功应用了某一个事务,要么都没有应用
- 单一系统映像:无论客户端连到哪一个Zookeeper服务器上,其看到的服务端数据模型都是一致的
- 可靠性:一旦一次更改请求被应用,更改的结果就会被持久化,直到被下一次更改覆盖