zookeeper简单学习
今天引入zooKeeper,来解决一些问题
首先还是那个问题?我们为啥学zooKeeper?
为了解决高可用性,保证出现故障正常使用,在hadoop中的namenode有第二备份,什么时候告诉客户端namenode变了,变成什么了,这时候就需要工具来进行协调
为了再次解决高可用性,这个工具不能挂掉没人管,所以工具r中也有备份,那接下来就是备份数据恢复,谁能恢复的更快,谁就拥有更高的可用性
Zookeeper就是其中的佼佼者,他能把这个数据同步的时间压缩的更短,请求响应更快。
还可以这么理解:是一个基于观察者模式设计的分布式管理框架,负责存储和管理数据,接受观察者的注册,一但数据发生变化,zookeeper就会通知注册的观察者去做出相应的反应(注册的观察者就是hadoop中的客户机)
简单来讲就是zookeeper在其中起协调作用,协调分布式系统,也就是hadoop
借鉴柳树的文章,想深刻理解为啥学zookeeper的可以看一下 -------> 为啥需要zookeeper
借鉴李狗蛋+1的文章,想zookeepe有更深刻的了解可以看看 --------->李狗蛋+1
下面开始简单学习一下zookeeper
1.zookeeper的简单介绍
通过上面解释为啥要学zookeeper,我们知道了一些。zookeeper为了减轻构建健壮的分布式系统,分布式协调服务的开源框架,用来解决的是分布式集群中应用系统的一致性和单点故障问题。
zookeeper以二进制存储,只能存放小量数据 最大2M左右,不能当数据库使用,但是可以放大数据的路径
2.zookeeper的特性
一致,可靠,顺序,原子(可能不太理解原子性,原子是不可再分的意思,指的就是事务请求要么成功,要么失败,不会出现那种成功但不完全成功,失败但不完全失败的情况)
3.zookeeper集群中都有哪些角色
1.Leader 一个集群中只有一个Leader,它是整个集群的核心,也是写操作(事务性请求)的唯一调度者和处理者(你想想看,如果所有人都能写,要多糟糕,一个人在A的地方写了个1,另一个人在A的地方写了个2,读的时候就会存在问题)
所以同时leader还要保证顺序性,可以发起和参与投票(当然也能进行读操作) 一个集群中只能有一个leader节点
简单讲就是:是核心,写操作(可能出现脏数据AB同时写),是大哥,保证集群事物处理顺序性,发起投票,唯一调度者
2.Follower 负责读操作(非事务性操作),如果收到写操作,会发给leder,可以参与投票 几个集群中可以有多个follower节点 (对于什么是投票?下面的zookeeper的两个机制会进行说明)
简单讲就是:读操作(如果有写操作,会发给大哥),参与投票
3.Observer 观察者,观察集群的最新状态,并同步状态。与follower功能基本相同,就是不参与投票,独立处理读操作,、
简单讲就是:观察,不参与竞争Leader
(其实除了这些还有一个竞选状态)(想更深了解一些,可以看这篇文章----------->ZooKeeper的三种角色(还是不太理解的可以看一下)
那这么看来boserver不多余吗????
随着集群中 Follow 服务器的数量越来越多,一次写入等相关操作的投票也就变得越来越复杂,并且 Follow 服务器之间彼此的网络通信也变得越来越耗时,导致随着 Follow 服务器数量的逐步增加,事务性的处理性能反而变得越来越低。
其实因为 Observer 不参与 Leader 节点等操作,并不会像 Follow 服务器那样频繁的与 Leader 服务器进行通信。因此,可以将 Observer 服务器部署在不同的网络区间中,这样也不会影响整个 ZooKeeper 集群的性能,也就是所谓的跨域部署。
如果有人对这个问题还存在疑惑,可以看一下这篇文章---------------->集群中 Observer 的作用以及 与 Follow 的区别
4.zookeeper集群中数据模型
Zookeeper是由节点组成的树,树中的每个节点被称为—Znode。每个节点都可以拥有子节点。每一个Znode默认能够存储1MB的数据,每个Znode都可以通过其路径唯一标识,如图中第三层的第一个Znode,,它的路径是/app1/p_1。Zookeeper数据模型中每个Znode都是由三部分组成,分别是stat、data、children。
统一命名服务:在分布式环境下 需要对服务进行统一的命名,便于识别
统一配置管理:分布式环境下 配置文件同步非常常见 对配置文件修改后希望同步到各个节点上
数据存储类似文件系统,就像/代表根目录,如/long/shi/san
create /zk "test" 创建一个新的Znode节点“以及与他关联的字符串
ls2/ 查看数据及更新次数
Znode的类型在创建时被指定,一旦创建就无法改变。Znode有两种类型,分别是临时节点和永久节点。
临时节点:就是临时的,它们对所有的客户端还是可见的。(需要注意的是临时节点不允许拥有子节点)
永久节点: 该生命周期不依赖于会话,并且只有在客户端显示执行删除操作的时候,它们才能被删除。(可以拥有子节点)
5.zookeeper集群中两种机制
第一种机制-------------->zookeeper的watcher机制
Zookeeper允许客户端向服务端注册一个Watch监听,当服务端的一些事情触发这个监听,会实现分布式的通知功能。(系统更新,通知其他人)
为啥要有这样的机制?是为了使系统知道namenode死了,使客户端知道secondary活了在哪。
举个例子:晚上班主任要开会,班长A和所有同学B收到了通知,但是中途老师有事情开不了会了,老师想告诉你可是不认识你,只能让班长告诉所有同学(老师就是namenode,班长就是watchr,同学就是zookeeper)
zookeeper集群是给我们提供服务的,可以提供计算服务(例如单词),而hadoop则是运用这种服务是可用性更高。
同时还具有分布式通知功能 zookeeper允许客户端向服务端注册一个watch监听(可能有多个watch,不同的注册方式(借钱案例,保险公司案例))
注意:要先注册watch才能触发
第二种机制--------------->zookeeper的选举机制
选举机制非常的神奇!!!
Zookeeper为了保证各节点的协同工作,在工作时需要一个Leader角色,而Zookeeper默认采用FastLeaderElection算法,且投票数大于半数则胜出的机制。(所以说,理想的状态是奇数个机器,不然没法选)
服务器ID: 设置集群myid参数时,参数分别为服务器1、服务器2、服务器3,编号越大FastLeaderElection算法中权重越大。
数据ID: 是服务器中存放的最新数据版本号,该值越大则说明数据越新,在选举过程中数据越新权重越大。
逻辑时钟: 逻辑时钟被称为投票次数,同一轮投票过程中逻辑时钟值相同,逻辑时钟起始值为0,每投一次票,数据增加。与接收到其它服务器返回的投票信息中数值比较,根据不同值做出不同判断。
还有一些小问题:
1.leader死掉后如何通知其他人?如何使其他人上位?
2.客户端监听的这个Znode是必须是领导者吗?还是说可以是任意一个Znode?
3.Zookeeper是适合安装奇数台服务器,还是只能安装奇数台服务器?
自我回答:
1.Ledaer死后,Zookeeper内部自动协调,根据权重产生新的Leader
2.也就是说Hadoop中的namenode向zookeeper注册了一个znode,zookeeper中的一个服务不断监听这个zonde,客户端监听的znode不一定是领导者,就像上面说的,可以是追随者和观察者,只有当有写操作的时候才会把消息传给领导者
3.适合安装,如果非要杠的话,也是可以安装偶数台的
另外还看到一篇有关的有意思的文章分享给大家 --------> 面试官:zookeeper集群的leader挂了怎么办