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