Zookeeper_简介

之前在ActiveMQ的时候用到了zookeeper,但是那个只是一个简单的环境搭建,现在要讲zookeeper,基本上就是这几点了

就是一个简单的介绍吧,就是zookeeper是什么东西,环境搭建,JAVA怎么去操作他,然后实际的应用场景,简单的说说,

后续做项目的时候会用上,然后zookeeper原生的API,curator框架

首先zookeeper是什么?

它是一个高效的分布式协调服务,你只能说他是一个协调服务,zookeeper以后我就说zk了,你要知道zookeeper有几点,第一点是

你一定要记住的,他并不是适合存储大量的数据,他比MSQ还不适合存储大量的数据,一般来讲存一些配置信息,发布订阅的信息,

注册的信息,类似于这种东西,动态实时的监听,节点的变更,然后反馈给咱们的服务器,服务器端第一时间做出反应,zookeeper他

也暴露了一些公共的服务,比如命名配置,同步的管理,包括群组服务等等,我们一般用zookeeper实现的事,一会在说

首先zookeeper是基于ZAB算法,原子消息广播协议,你如果有信息你可以自己去看一下,paxo算法,自己百度百科去看一下,就是相当于

主从选举的算法,也可以叫做复制算法,了解这个原理就行,原子广播这个协议呢,无非是什么意思呢,它是能够保证分布式环境中的

数据一致性,说白了咱们的zookeeper,没有单节点去部署的,至少是3个节点,官方推荐是奇数个节点,要么是3个,要么是5个,要么是7

个,别整4个或者6个,其实能不能部署,其实也可以,只是不利于paxos算法去进行选举,在这里说选举是一个什么概念,比如我又奇数个

节点,在这3个节点选择一个主节点,当成leader,其他的节点当成slave,或者follow,然后他遵循这很多特性,他一般是分布式解决的一个

利器,分布式锁啊,等等一些比较头疼的问题吧,它是为了分布式服务产生的一个技术,一个框架,这是他的特点,首先说一下顺序一致性,

从一个client端发起一个事务的请求,最终将会严格的按照其发起的顺序被应用到zookeeper中去,其实咱们可以画一个图,我这个

zookeeper是一个集群,至少是3个node,zookeeper1是follower,zookeeper2是leader,zookeeper3是follower,

follower是从节点,leader是主节点,他们肯定会选举一个节点,来当成子节点,主从选举是通过paxos这个算法去做的,

这个算法叫做复制算法,遵循的协议是ZAB,这种东西你可以去看看,自己可以去扫一下盲,百度一下,

其中leader如果是挂掉的话,那就从zookeeper1和zookeeper2中选举一台,选举一台升级为leader,只要你的半数服务以上,

能够保证是好的,我就能正常的对外提供服务,跟咱们之前学的redis差不多,你比如有11台机器,你挂了5台都没有问题,

你挂了5台,还有6台,半数以上,我这6台也可以正常的对外提供服务,是这种情况,遵循数据的一致性什么概念呢,

一个client端发起一个事务请求,最终将会严格的按照其发起的顺序被应用到zookeeper中去,

在这里你就可以理解为zookeeper是一个整体,是一个整体的环境,由3个节点组成,

就是一个leader,两个follower,然后当我有一个client端,client端可能是咱们自己写的一个APP程序,就是WEB程序,

然后我想去操作一个zookeeper上的一个节点,就是操作他里面的数据的时候,其实你可以理解它是对整体进行操作的,

这里不是有三个节点吗,比如他里面有个节点叫做1,我把它改成2了,持久化更新操作,持久化写操作,只要写给

zookeeper1的时候,可能是先改成这个,这里面原先有个数据是1,把它改成2了,然后这中间,是不允许其他的customer

去访问的,访问这一个节点的,因为他们中间遵循一个原子消息广播,zookeeper1会把消息传给zookeeper2他,总之三个节点

的数据都变成2了以后,那其他的customer端,也就是其他的client端才能去更改节点,也就是在这三台机器上加了一把锁了,

也可以理解成ZAB,之间进行复制的算法,就是paxos算法,ZAB和PXOS这个你自己去扫盲,我不做过多介绍,首先说一下顺序一致性

原子性刚才也说了,所有事务请求的结果在整个集群中所有机器上的应用情况是一致的,也就是你去改zookeeper上的其中一个节点,

那两个节点的数据肯定也是一致的,这个是你要放心的,你肯定不需要考虑其他的问题,不可能会出现数据不同步的情况,

做的事情就是做数据同步,所以这个是你要放心的,它是用PAXOS算法去实现的

然后就是单一视图,单一视图什么概念呢,无论客户端连接哪一个zookeeper服务器,无论你去连接follower还是leader,

还是连接另一个follower,你看到的数据肯定都是一致的,因为这三个数据是严格的遵循原子数据广播,肯定是一致的,

这是你需要放心的,可靠性理论上来讲,一旦一个服务器去应用了一个事务,并完成了对客户端的响应,也就是说我是这样去做的,

当前这三台zookeeper集群数据肯定是一致的,理论上来讲去修改一条数据,它会把数据同步到两台机器上,然后给我一个response,

一个反馈,并完成对客户端的响应,就是一问一答的形式,会引起服务器的状态会一致的保存下来,除非有另一个事务对其更改,

其实呢怎么说呢,既然用这个zookeeper,你就应该相信他就OK了,一般来说还没有出现过这种问题的,如果节点出现网络的问题,

那这个东西就锁住了,能理解我的意思吧,数据同步不过去,比如我先做数据同步不过去,client端就一直等待着,一问一答的形式,

是三个节点数据都一致了才会反馈的,如果三方网络延迟,他们三有问题,那他就会报一个超时错误,返回给客户端,

只要你数据不同步不成功,那client端返回的就是一直等待,等待超时,如果要是一半以上的节点挂掉的话,

那就不对外提供服务了,能理解我说的意思吧,那他就不会对外提供服务了,然后节点之间出现网络问题,

那就是延迟,就是你操作的时候不给你返回,这是一个很简单的道理实时性这个东西,什么东西你不能说到百分之百,

一般来说咱们的应用使用zookeeper就足够了,通常来讲,除非你到了天猫那个级别,你要用zookeeper,

可能就会有些问题,所以RocketMQ之后的版本,都是用nameserver,代替了Zookeeper了,nameserver比zookeeper更轻,

更轻量级,包括很多的优化,存储的策略,你如果有兴趣你可以看看nameserver,但是他只是一个内部的,针对broker,

因为他的功能比较单一,就是对broker进行服务的,因为它可以写的代码很少,客户端可以立刻从服务器上获得变更后的数据,

zookeeper仅仅保持一段时间内,客户端最终一定能从服务器端读取最新的数据状态,我觉得这一块这么说,就是网络有延迟的,

可以做分布式事务,他做分布式事务还是不太好,他能做分布式锁,分布式的建立时间戳,这些也都是可以做的,

要做分布式事务的话怎么说呢,除非你能保证三个zookeeper三个节点,能够保证高可用,也不算是高可用吧,

你的网络问题没有问题的话,没有网络问题的话,你也可以尝试着用zookeeper去做,分布式事务和分布式锁有啥区别,

这个后续讲的时候再说吧,反正都是分布式了,现在不考虑那么多,总之这就是zookeeper的几个特性

看一下zookeeper的设计目标,简单的数据结构,他要求的是很简单的数据结构,然后就是树形的结构就是最简单的,就是

有父子关系的树形空间,这是zookeeper一个比较好用的,它是参考linux的,然后它是可构建集群的,一般最好是遵行3,5个

节点,只要集群中半数以上的机器能够正常的工作,那我整个集群就可以正常的对外提供服务,顺序访问,每一个客户端的

每一个请求,zookeeper都会分配一个全局的惟一的ID,每个编号都是反映了事务操作的顺序,所以他能够严格的去保证顺序,

然后还有目标4是高性能,zookeeper是将全量的数据是保存在内存中的,并且直接服务与所有的非事务请求,内存是操作非

事务的请求,如果是事务那肯定要操作zookeeper的文件了,因此它是在读的场景下性能是非常突出的,Redis是把所有的数据

都写在内存中了,然后我的读的性能是非常突出的,然后在JMater压力测试下,如果你是百分百读的场景下,QPS可以达到12到

13万,这应该是一个很不错的数据,然后这是设计目标

zookeeper的结构他就是和linux差不多,每一个节点占时称作znode吧,基本上最上层是一个斜杠,跟linux差不多,

然后你想创建数据呢,/app啊,如果/app下面还想创建,你再写,就是类似于一个树状结构,一种树状结构的这种形式,

或者这边也有,你这个分支怎么写都行,差不多是这个结构

数据模型,在这里有一个znode的概念,znode你可以理解为每一个层级的节点吧,znode节点有两种方式,

一种是持久化的,还有一种是可以设置临时的znode节点,这个后期再去说吧,znode也是可以被监控的,他有watch的机制,

这个后期再说吧,这个数据模型往后再说

咱们zk服务器的组成,本身来讲分三个角色吧,第一个角色叫做leader,就是主节点,第二个角色叫做follower,

从节点,这两者肯定是zk服务器的,Observer或者叫做什么,叫做watcher,就是服务器节点,监控的节点叫做Observer,

或者叫做watcher,这个是一个特殊的follower,他相当于充当zookeeper的使用者吧,监控者,可以接收客户端的reader

请求,基本上你理解这三者就行了,其实咱们建的集群,你理解这两个就行了,到后期咱们写一个client端,说白了我用JAVA

去操作zookeeper,那我操作zookeeper的这段代码,可以理解为他就是Observer

然后是应用场景,他能做什么事呢,做一些配置的管理,集群配置的管理,可以做发布订阅,可以做数据库动态的切换,

做分布式日志的收集,分布式锁,队列管理等等,zookeeper都可以轻而易举的做到,之前去用zookeeper的时候,那个时候zookeeper只有

原生的API,写的话很麻烦,现在出现了一个非常强大的APACHE的开源的项目,Curator,有没有人用过,Curator这个东西,基本上他能

做很多事情,以后我们的应用啊,hadoop啊,比如storm啊,很多分布式的场景,dubbo啊,还包括之前的ActiveMQ,很多的场景都会

用zookeeper协调的框架,所以说这个很重要,这个以后再说吧

然后他并不难,应用场景后面再说,首先来讲一下配置管理吧,配置管理是在工作中很常见的一个需求,比如咱们之前

的redis,咱们之前学过Spring和Redis整合,在Spring的xml文件里面,配置Redis有几个服务,写死了那不好,一般咱们是要做

动态的,你的服务能够动态的变更,你最好用zookeeper做,这是最合理的,他能做一些配置,数据量比较小,你满足这三条

就可以选择,数据量一定是比较小的,zookeeper你千万别存一个大的数据,然后数据同步的时候还很慢,数据内容在运行

时还动态的发生变化,集群中各个节点共享信息,这是啥意思,配置一致,各个机器,集群中各个节点共享一份信息,

配置一致,就是你以后在什么场景下选择zookeeper,满足这三条,你要同步的数据数据量比较小,并且这个数据总是在运行

时发生动态的变化,比如三个节点收到同一个数据的时候,你可以做这个事情,包括其他集群的管理,zookeeper讲完之后要讲dubbo,

dubbo里面就是用zookeeper作SOA的注册的,包括发布订阅,咱们以后讲RocketMQ的时候,其实也可以用zookeeper实现更好,

我直接放在zookeeper里是最好的

数据库的切换,数据库里面开始配置死了,后来数据库挂了,直接换一台,其实也是类似于配置的管理去做,

然后也可以做日志的整理,包括其他的场景下,你有更复杂的需求,你想两个服务节点,同时这边吹个哨,他们两个都是

去执行一个分布式的事务,zookeeper里面是有实现的,我们可以通过zookeeper一个非常强大的框架,他目前是APACHE

一个顶级的项目,所以说,如果你工作中用了zookeeper,没有用Curator,那我就觉得和没有用zookeeper一样,

你自己工作中写helloworld,我觉得curator这么成熟,但是很少发现工作中有人去用curator,咱们重点是讲一下curator

他的应用场景非常广泛,包括hadoop,storm,RPC的框架dubbo,还有mysql的一些东西,包括淘宝的分布式的数据,很多

都是用的zookeeper,去做一个协调,简单给大家介绍一下zookeeper,然后他具体能干什么事,他能实现什么功能,

这个只能以后一点点来讲了,只是让你大概有一个印象,可能你会留有很多疑问,分布式锁和分布式事务是啥区别

后期咱们去讲到了你就会知道,zookeeper怎么去实现分布式锁,他有原生的实现分布式锁的方式,还有利用Curator

实现分布式锁的方式,你对比下到底是原生的API好用呢,zkclient好用,还是curator好用,到时候你就知道具体工作

中该怎么去使用zookeeper了,就是一个简单的介绍,其实我给你留的作业就是两个,zookeeper底层是怎么去实现的,

你一定要知道他是使用ZAB原子消息广播去做的,原子消息怎么回事,自己百度上去查,我就不说了,这是作业1

原子消息广播里面有个CAS的,这是单点登录,也是一个原子消息的算法,其实采用的是paxos,就是这种复制算法,

那这个是一个什么情况,刚才我百度搜了,你自己去扫盲,有的人百分百会问这两条,这是对于zookeeper底层的

概念性的,但是你得有一个概念性的认识,怎么去做同步的这个事