Zookeeper------简介(一)
Zookeeper使用场景:作为分布式系统的分布式协同服务。
分布式系统定义:分布式系统是同事跨越多个物理主机,独立运行的多个软件组成的系统。
分布式系统的缺点在于:如何解决节点之间的信息同步和共享。
依赖于服务进程之间的通信。
两种通信方式
1.通过网络进行信息共享
类似现实中,开发leader开会、以及私聊、邮件传达任务。信息通过直接沟通,完成传递。
2.通过共享存储
类似现实中,开发leader将任务上传SVN,组员拉去svn最新的任务信息,更好⼀点的做法是,当svn⽂件版本更新时,触发邮件通知,每个组员再去拉取最新的任务分配表。
此种方式依赖于中央存储。
Zookeeper通过共享存储
其实共享存储,分布式应用也需要和存储进行网络通信。
每个分布式应用的节点类似组员,订阅这些共享信息,当主节点(组leader)从某个节点的分工信息作出改变时,相关订阅的子节点,得到Zookeeper的通知,获取自己最新的任务。完成工作后,把完成情况存储到Zookeeper。主节点订阅该任务的完成情况信息。
此处,Zookeeper作用类似于将svn和邮件系统合二为一。
而大部分分布式系统中会出现的问题,都源于信息的共享出了问题。
如果各个节点间信息不能及时共享和同步,则分布式系统就失去意义
Zookeeper的基本概念
Zookeeper是一个开源的分布式协调服务,其设计目标是将那些复杂的、且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集。并以简单的接口提供给用户使用。Zookeeper是一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它实现数据订阅/发布、负载均衡、命名服务、集群管理、分布式锁、分布式队列等功能
基本概念
1.集群角色
最典型的集群就是Master/Slave模式(主备模式),将所有能够处理写操作的机器称为Master机器,讲所有通过异步复制方式获取最新数据,并提供读服务的机器称为Slave机器。
而Zookeeper中,概念被颠覆了,引入Leader、Follower、Observer三种角色。Zookeeper集群中所有的机器通过Leader选举来选定一台被称为Leader的机器,Leader服务器为客户提供读、写服务,除Leader外,其他机器包括Follower和Observer,都能提供读服务,唯一的区别在于Observer不参与Leader选举过程,不参与写操作的过半写成功策略,因此Observer可以在不影响写性能的情况下,提升集群的性能。
2.会话(session)
Session指客户端会话,一个客户端连接是指客户端和服务端之间的一个TCP长连接,Zookeeper对外的服务器端口默认为:2181,客户端启动的时候,首先会与服务器建立一个TCP连接,从第一次连接建立开始,客户端会话的生命周期,也开始了,通过这个连接,客户端能够心跳检测与服务器保持有效的会话,也能够向Zookeeper服务器发送请求并接受响应,同事还能够通过该连接接受来自服务器的Wacth时间通知。
3.数据节点(Znode)
分布式中“节点”是指组成集群的每一台机器,而Zookeeper中,“节点”分为两类,第一类同样是指构成集群的机器,称为机器节点,第二类是指数据模型中的数据单元,称之为数据节点—Znode。Zookeeper将所有数据存储在内存中,数据模型是一棵树(Znode Tree),由斜杠(/)进行分割的路径,就是一个Znode,例如/app/path1。每个Znode上都会保存自己的数据内容,同时还会保存一系列属性信息。
4.版本
Zookeeper的每个Znode都会存储数据,对于每个Znode,Zookeeper都会为其维护一个叫做Stat的数据结构,Stat记录了这个Znode的三个数据版本,分别是version(当前Znode的版本)、cversion(当前Znode子节点版本)、aversion(当前ZNode的ACL版本)。
Watcher(事件监听器)
Watcher(事件监听器),是Zookeeper中一个很重要的特性。Zookeeper允许用户再指定节点上注册一些Watcher,并且在一些特定事件触发的时候,Zookeeper服务端会将事件通知到感兴趣的客户端,该机制是Zookeeper实现分布式协调服务的重要特性。
ACL
Zookeeper采用ACL(Access Control Lists访问控制列表)策略进行权限控制,定义了五种权限:
CREATE:创建子节点的权限
READ:获取节点数据和子节点列表的权限
WRITE:更新节点数据的权限
DELETE:删除子节点的权限
ADMIN:设置节点ACL的权限
注意:CREATE和DELETE这两种权限都是针对子节点的权限控制。