ZooKeeper原理
ZooKeeper包含一个树形的数据模型znode。一个znode中包含了存储的数据和ACL(Access Control List)ZooKeeper设计适合存储少量的数据,并不适合大量数据,所以znode存储限制最大不超过1M。
数据的访问被定义为原子性的,一个客户端访问一个znode时,不会只得到一个数据,要么得到全部数据,要不全部失败,写操作也类似。
为什么不能使用zookeeper命名节点?
ZooKeeper默认使用zookeeper来命名根节点,来存储一些管理数据。
znode有两种类型:
ephemeral和persistent
在创建znode时,我们指定znode的类型,并且在之后不会再被修改
创建结束后,ephemeral类型的znode将被删除,persistent类型的znode被创建后,就与客户端无关,除非主动删除,否则一直存在。
Ephemeral znode没有任何子节点。
在使用排序标志创建znode时,ZooKeeper会在我们指定的znode名字后面加上一个数字
观察模式:Watches
观察模式使得客户端在某一个znode发生变化时得到通知,由ZooKeeper服务的某些操作启动,并由其他操作来触发。
一个客户端对一个znode进行了exists操作,来判断znode是否存在,同时在znode上开启了观察模式。如果znode不存在,exists将返回false。如果稍后另外一个客户端创建了这个znode,观察模式将被触发。
观察模式只能被触发一次。
ZooKeeper服务可以在两种模式下运行
standalone模式:运行一个单独的ZooKeeper服务器,用来进行基本功能的简单测试。
缺点:没有办法体现ZooKeeper的搞可用性和快速恢复特性。
replicated模式: 安装在多台服务器上,组建一个叫做ensemble的集群。
例:在11个节点的ensemble中,最多允许5个节点脱离集群,因为节点进行投票时要超过总数的一半。
所以ensemble中服务器的数量是奇数。
Zab协议:
阶段一:领导选举
ensemble中的成员通过一个程序选举出一个首领成员Leader,其他成员称为follower,当大多数follower完成与leader状态同步时,这个阶段才结束。
阶段二:原子广播
所有请求发送给leader,再广播给follower。当大多数的follower完成了数据改变,leader才会将更新提交,客户端就会随之得到leader更新成功的消息。
协议中的设计也具有原子性,所以写入操作只存在成功和结束。
如果leader脱离了集群,剩下的节点将选举一个新的leader,如果之前的leader回到了集群中,那么将被视作一个follower。leader的选举很快,大概每200ms就能够产生结果,不会影响执行效率。
ensemble中所有节点都会在更新内存的znode树的副本之前,现将更新数据写到硬盘上,读操作可以请求任何一台ZooKeeper服务器,读取速度很快。
数据的一致性Consistency
在ensemble中的follower的update操作会滞后于leader的update完成。我们在提交更新数据之前,不必在每一台ZooKeeper服务器上执行持久化变更数据,只需在服务器上执行持久化变更数据。
在进行读操作的时候,leader和follower都可以进行相关操作,而进行write操作时要通过follower再发送给leader。
ZooKeeper的数据一致性实现了如下方面
顺序一致性:客户端讲一个znode z赋值为a,然后将z的值改成b,那么取的值是a
原子性:更新操作的结果不是成功过就是失败
系统视图唯一性:无论客户端连接到那个服务器,都将看见唯一的系统视图。
持久性:一旦更新成功,数据会被持久化到服务器上并且不能撤销。
时效性:系统视图的状态更新的延迟时间上限最多不超过几十秒。
会话Sessions
ZooKeeper客户端配置了一个ensemble服务器列表,当启动时首先去链接其中一个服务器,如果尝试连接失败,会继续尝试连接下一个服务器,知道连接成功或者全部连接失败。
一旦连接成功,服务器就会为客户端创建一个会话(session),如果在时间内服务器没有收到客户端任何请求,那么session将被视为过期,并且这个session不能被重新创建,创建的ephemeral znode将随着session过期被删除掉。
在长时间的空闲下,客户端会不断发送ping请求来保持session。ping请求的间隔时间足够短以便可以及时发现服务器失败。
tick是ZooKeeper的基础时间单位。
通常tick等于2秒,设置session过期时间太短会造成加快物理失败的检测频率。通常越大规模的ensemble,就需要越长的session过期时间。
ZooKeeper常见应用场景
可靠存储:表现为配置管理,名字服务
集群管理:利用ZK通讯回调机制完成分布式集群的机器状态监视。
服务注册发现管理:可靠存储加上通知回调机制满足了注册服务发现的最基本要求。
选主服务:
分布式同步机制:分布式锁
负载均衡:
ZooKeeper的特性与优势
通知回调机制
可靠存储系统
连接状态维护
文件系统模型
自增长序列