HDFS:是解决存的问题
HBase:解决大表的问题,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统
Hive:是包装MapReducer的功能。基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张表,并提供类SQL查询功能
而zookeeper没有具体的功能,它在大数据区块中的位置比较特殊,好似一个润滑油,实际上它是协调大数据其他框架/组件之间的合作的。
Zookeeper是一个开源的分布式的,为分布式应用提供协调服务的Apache项目
所谓协调:即对变化或作业做及时、适当的反应、处理。
两个要点:存数据、通知
Zookeeper在大数据中是一个“潜在“”的角色,主要应用于HA、Kafka、Hbase。为何是“潜在”的角色? 因为实际上在使用时我们只需要把zookeeper打开启动就行了,一般并不需要有其他的操作,在大数据中好比一个幕后管理者,就是不懂zookeeper,能用就行。 但是原理我们还是要懂的。
简单来说就是:Zookeeper=文件系统+通知机制
1、集群最大的特点是:主次同放。譬如:Redis、hadoop、yarn都有master和slave。 同样,zookeeper也有。
zookeeper中的主称为leader,从称为follower。
2、半数以上节点存活即可正常工作:zookeeper不需要节点全部存活,只需要有半数以上节点存活,它就能正常工作。譬如5台集群的zookeeper,挂了一台两台follower,它依然可以正常提供服务。
3、全局数据一致:zookeeper存的是数据。与HDFS的区别在于,HDFS所有节点存的数据是不一样的,zookeeper所有节点存的数据是一样的,即全局数据一致
4、更新请求顺序进行
例子:假设某个Client向集群发送了两条请求1和2,交给了follower。因为全局数据一致,所以不管是什么数据,最终会发给每个Server一份(人手一份!)。 但是如果由于网络原因,Server5先收到1后收到2,Server4、Server3先收到2后收到1。 那会怎样呢? 即使它们先收到2在收到1,也会先写1再写2。
5、数据更新原子性:假设client发送数据到集群,这几台机器都往里面写数据,但是这5个好兄弟共进退:要么都成功,要么都失败!(咋一看有点像mysql中的事务哈,都成功或都失败)
6、实时性:这个是有一定的时效范围的,一个client刚写完另一个client就读是读不到的
其中:3、4、5这三个特点是最重要的!!!
上面有提到:zookeeper是可以可以存数据的!
其路径也是以‘/’作为根目录。 这和Linux有点像,但是不同的地方在于:zookeeper的节点,没有目录和文件的区别。
Linux中如果能存数据的,一定是个文件,只能存数据的文件,下面一定没有子节点(子文件或子文件夹);如果有子节点,那么它就不能存数据。
而zookeeper中并不分文件和文件夹,它只有一种东西称为:ZNode。zookeeper就是由无数个ZNode组成的。每个ZNode既可以有子节点,又可以存放数据。 默认存1,所以zookeeper不是拿来当“硬盘”用的。
提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务结点动态上下线、软负载均衡等。
zookeeper中的配置文件zoo.cfg中参数含义解读如下:
1、tickTime=2000:通信心跳数,zookeeper服务器与客户端心跳时间,单位毫秒
zookeeper使用的基本时间,服务器之间或服务器与客户端之间维持心跳的时间间隔,也就是每个tickTime时间就会发送一个心跳。
应用于心跳机制,并且设置了最小的session,超时时间为两倍心跳时间。(session的最小超时时间=2*tickTime)
2、initLimit=10:LF初始通信时限
集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接是能容忍的最多心跳数(tickTime的数量),用它来限定集群中的zookeeper服务器连接到Leader的时限。
3、syncLimit=5:LF同步通信时限
集群中Leader与Follower之间的最大响应时间单位,假如响应超过sybcLimit*tickTime,则Leader认为Follower“死掉”,从服务器列表中删除此Follower。
上面三个参数不需要修改
4、dataDir:数据文件目录+数据持久化路径
主要用于保存zookeeper中的数据
5、clientPort=2181:客户端连接端口
监听客户端连接的端口。(这个可以随心改变,任君发挥!)
help:显示所有操作命令
ls path [watch]:使用ls命令来查看当前znode中所包含的内容(加上watch表示监听一次此节点变化)
ls2 path [watch]:查看当前节点数据并能看到更新次数等数据
create:普通创建节点(-s含有序列的节点,-e创建临时节点,重启或超时消失)
get path [watch]:获得节点的值
set:设置节点的具体值
stat:查看节点的状态
delete:删除节点
rmr:递归删除节点
总结就是:增删改查(CURD永远滴神!!)
1、监听器原理
zookeeper有个重要的功能叫通知。通知的原理大致是:
zookeeper对于每个节点都存在watcher list。 所有人,如果观察这个节点,就告诉zookeeper要watch它,这样zookeeper就把你放进watcher list。假设出现了变化,就遍历这个watcher list,逐个通知,通知完了,就把你从watcher list中删除。
zookeeper是怎样保证高并发情况下,全局数据一致,且读写顺序一定?主要是通过ZAB(Zookeeper Atomic Broadcast)协议。这个也是Zookeeper原理中最重要的一部分内容。
ZAB协议主要内容是两个部分:
一是:没有leader选leader
二是:有了leader就干活!(简单直接有内涵!)
Zookeeper刚建立集群的时候没有leader,因此进入第一个阶段。选举出leader,选举完进入第二个阶段:干活! 以后Zookeeper就在这两个状态之间不停的切换。
follower挂了没事。假设leader挂了,就重新回到第一阶段,选举leader。然后再回到第二阶段。
所以Zookeeper是如何进行选举的呢? 下面我们来谈谈:选举机制。
2、zookeeper的选举机制(重点)
当集群刚启动的时候,便要进入第一阶段的选举流程:
1)半数机制:集群中半数以上机器存活,集群可用。所以zookeeper适合安装奇数台服务器
2)zookeeper虽然在配置文件中没有指定Master和Slave。但是,zookeeper工作时,是有一个节点为Leader,其他节点则为Follower,Leader是通过内部的选举机制临时产生的。选举机制如下:
首先要知道zookeeper有四个状态:
Looking(在集群中寻找leader),Leading、Following、Observing。
其中:Looking状态的机器是不能向外提供服务的,其他三个状态则可以。
假设有五个服务器:
(1)服务器1启动,状态为Looking,发起一次选举。服务器1给自己投了一票。此时服务器1票数为1,不够半数以上(3票),选举无法完成,服务器1状态保持为Looking;
(2)服务器2启动,状态也为Looking,发起一次选举。服务器1和服务器2分别投自己一票并且交换选票信息;此时服务器1发现服务器2的ID比自己目前推举的(服务器1)大,“欺软怕硬”的服务器1便更改选票为推举服务器2。此时服务器1票数为0,服务器2票数为2,均未达到半数以上(3票)。选举无法完成,服务器1、2保持Looking;
(3)服务器3启动,状态为Looking,发起一次选举并且投给自己(服务器3)一票。此时服务器1和服务器2都会更改选票为推举服务器3(同上“欺软怕硬”)。此次投票结果:服务器1为0票、服务器2为0票、服务器3为3票。服务器3票数已超半数,当选leader。 服务器1、2更改状态为Follower,服务器3更改状态为Leading;
(4)服务器4启动,发起一次选举并且投给自己(服务器4)一票。此时服务器1、2、3都不是Looking状态,不会更改选票信息。 交换投票信息结果:服务器3为3票,服务器4为1票。 此时服务器4遵从少数服从多数,更改选票信息为服务器3,并更改状态为Following;
(5)服务器5启动,同4一样当小弟。 自此选举完成
注意:交换选票信息,进行比较的时候先比较zxid,再比较myid。
zxid:事务编号,就是目前数据的版本,zxid越大,表示数据越新。zookeeper需要选举一个数据较新的作为leader。 如果是一个新集群,则zxid都一样,则是myid大的胜出。 如果是5个一起启动,因为服务器5的myid最大,因此就会使服务器5当选leader了。
3、zookeeper的部署方式?集群中的角色有哪些?集群最少需要几台机器?
部署方式:单机模式、集群模式
集群角色:Leader和Follwer
集群最少需要的机器数:3