手把手带你玩转大数据系列--zookeeper原理+搭建步骤
Zookeeper
不知道大家这个假期过的怎么样，反正小编这个假期真的是过的水深火热的，中间也断更了好几天，在这里和大家说一声抱歉，而且因为小编自己的原因，手把手带你玩转大数据系列在中间也有一个间断，添加了一个flink的资源任务调度流程的讲解，今天回归正题，在之前的时候和你们说的zookeeper的相关问题。
在这里，小编想和大家说一句自己对于大数据的见解，其实大数据说白了就是对于数据的一个处理，而数据又来源于生活，所以，大数据的相关理论其实都是可以在生活中找到实际的例子的，甚至说，开发的很多都是可以跟生活实际进行理解，大家可以去看一下我之前讲解的hdfs的原理，就应该能明白我说的。
那既然说每一个专业的技术总可以在生活中找到相应的实例，就比如说zookeeper，攘其外必先安其内就很好的解释了zookeeper，Hadoop集群的组件中的很多在学习的时候都会觉得每一个都不稳定，都会出现这样那样的问题---（单点故障），所以，在集群中，为了维护集群的安全和稳定，解决单点故障，可能大家会听过一个名字--高可用（HA），而在高可用的集群搭建过程中，为了将人力资源尽可能的脱离以及集群的可维护性更强，产生了这样的一个管理集群--zookeeper（分布式协调服务），那zookeeper为什么这么牛逼呢？他真的可以让集群一直可用吗？其实不是的，这一点，在zookeeper的官方定义的时候就已经说明了，zookeeper在集群出现故障到解决故障正常执行的间隔时间小于200ms，在我们看来就是整个集群一直可用的错觉
那他是怎么实现的呢？我们以HDFS为例子简单的解释一下zookeeper的工作，在开机时，两个namenode只有一个处于存活状态，每一个namenode伴随着有一个zkfc存在，zkfc一边连接namenode，另一边是zookeeper集群，当开机后，zkfc会争先去zookeeper中创建一个节点，谁先创建就可以启动并创建一个节点进行监控、注册等，节点的变化会产生一个事件，当一个namenode出现异常挂掉之后会产生一个事件，事件会向节点去注册，然后节点会回调存活的namenode并启动，挂掉的namenode处于等待状态，所以说zookeeper就是一个协调服务
Zookeeper的构成
Leader主要有三个功能：
1 .恢复数据；
2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
Observer的目的是为了扩展系统，提高读取速度
Follower主要有四个功能：
1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
2 .接收Leader消息并进行处理；
3 .接收Client的请求，如果为写请求，发送给Leader进行投票；
4 .返回Client结果。
Zookeeper 的特性：
单一视图为客户展现同一个视图，即使因为挂机或者其他原因造成版本低等现象，但是当重新连接之后数据版本等信息会进行更新，最终达到一致性的特点
可靠性如果消息被一台服务器接受，那么它将被所有的服务器接收
实时性不能保证两个客户端同时得到刚更新的数据
独立性各个Client之间互不干预
原子性 更新只能成功或者失败，没有中间状态
顺序性所有Server，同一消息发布顺序一致
那说了这么多，zookeeper到底是怎么的一个运行原理呢？
Zookeeper的基本运行流程：
Client将一条请求写入到zookeeper集群中
Follower将请求转发给leader，然后leader将请求转发给集群中的节点，投票表决
因为zookeeper集群的原子性，所以会有两个过程，首先投票表决是否可以进行这个请求操作，如果过半的节点同意进行这个请求，那么，进行下一步，将请求发送到各个节点上进行处理，这也就保证了只会有成功和失败两种状态，不会出现中间状态
当过半的节点（不同意的节点可能因为挂机或者其他原因失去联系）同意并且执行完毕之后，zookeeper会恢复所有的节点之间的通信，这个时候会将数据进行同步处理，达到整个集群中的数据的一致性
Zookeeper的核心是原子广播，（但client发送请求将hello写入到集群中时，节点会投票选择是否同意这个请求，当同意之后，leader会将hello更新到所有的节点上），保证了各个server之间的同步，实现协议是zab协议
恢复模式：leader挂掉了，需要重新选举leader或者当服务刚刚启动还没有产生leader的时候
广播模式：产生leader之后，集群处于主从结构之后的模式
而对于未产生leader之前的恢复模式，他在选举leader的时候有一套他自己的算法机制
Zookeeper内部选举算法（zab算法）：
当客户端提交请求之后 或者当集群刚启动的时候，zookeeper会进行投票的行为，投票选举出来在大家之中最适合成为领导者的那个节点，让他领导其余的节点，投票不是一轮既可以完成的，因为总有得票数相同的节点出现，素以需要进行多轮投票，直到选出那唯一的一个，，在每一轮投票结束之后会将投票信息发送到所有的节点上，这些信息包括：服务器ID，数据ID，逻辑时钟，选举状态（LOOKING，竞选状态。 FOLLOWING，随从状态，同步leader状态，参与投票。OBSERVING，观察状态,同步leader状态，不参与投票。LEADING，领导者状态)在每一轮的投票中不断的更新这些数据，最后可以得到一个的票数最多的节点，他就是众望所归的leader
具体的投票执行流程：
(1) 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。
(2) 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为3，Server3的ZXID为2；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
(3) 接收来自各个服务器的投票。与启动时过程相同。
(4) 处理投票。与启动时过程相同，此时，Server1将会成为Leader。
(5) 统计投票。与启动时过程相同。
(6) 改变服务器的状态。与启动时过程相同
如果你以为zookeeper就这点东西，那就错了，接着往下看
不知道大家在看到上面的zookeeper运行流程时有没有一个疑问，那就是这些所谓的请求以及状态信息zookeeper是怎么进行存储的？对，你没有想错，在zookeeper内部维护有一个自己的文件系统
Zookeeper的数据模型
一、 zookeeper存储节点--Znode
Znode是客户端访问Zookeeper的主要实体，每当Znode的数据改变时，他相应的版本号将会增加。
它包含以下特征
（1）Watches
客户端可以在节点上设置watch(监视器）,当节点的状态发生改变时，将会触发watch相应的操作，只会被触发一次
（2）数据访问
Zookeeper中的每个节点上存储的数据需要被原子性操作也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作
org.apache.zookeeper.CreateMode中定义了四种节点类型，分别对应：
PERSISTENT：永久节点
EPHEMERAL：临时节点
ZooKeeper的临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。另外，需要注意是，ZooKeeper的临时节点不允许拥有子节点。
PERSISTENT_SEQUENTIAL：永久顺序节点
EPHEMERAL_SEQUENTIAL：临时顺序节点
顺序节点其实就是当创建Znode的时候，用户可以请求在Zookeeper的路径结尾添加一个递增的计数
二，Zxid
致使Zookeeper节点状态改变的每一次操作都将使节点接收到一个zxid格式的时间戳，并且全局有效，每个Zookeeper都维护者三个zxid值，分别为cZxid,mZxid,pZxid
三，版本号
对节点的每一次操作都将致使整个节点的版本号增加。每个节点维护着三个版本号，他们分别是:
version(节点数据版本号），cversion(子节点版本号），avevsion(节点所拥有的ACL版本号）
一图总结一下
关于zookeeper的原理，基本就整理这么些，后面有时间我会进行更加详细的讲解，然后接下来那肯定就是搭建步骤了，光讲理论没有实践怎么行
搭建zookeeper集群 （最好配置成home，别用prefix，尤其hadoop）
上传zookeepr包
解压：tar -xf zookeeper-3.4.6.tar.gz
移动zookeeper包到/opt/sxt目录下：mv zookeeper-3.4.6 /opt/sxt
配置zookeeper的环境变量：vi /etc/profile
配置zookeeper配置文件
进入zookeeper家目录中conf目录下，可看到一个zoo_sample.cfg文件
拷贝重命名：cp zoo_sample.cfg zoo.cfg
配置zoo.cfg: vi zoo.cfg
进入数据目录/var/sxt/zk，执行：echo 1 > myid echo 2 > myid echo 3 > myid 分别在node02 node03 node04操作
（
；
）
也就是创建myid文件在服务器1,2,3分别追加1，2, 3， 代表各自zookeeper的id，跟上边zookeeper配置文件一一对应。
从node02向node03/node04分发：scp -r zookeeper-3.4.6/ node04:`pwd` （发动到当前目录，即目标目录与源目录相同；也可以自定 以/开始）
还需要注意，分发的目录后一定要加（zookeeper-3.4.6/）,否则就是把该目录的内容发过去，目录名称不会分发！！！
启动zookeeper集群：
zkServer.sh start node02、node03、node04分别操作
查看zookeeper集群个节点的启动状态：
zkServer.sh status
zkServer.sh stop
好了 ，这就是关于zookeeper今天的内容了，觉得写的还不错的，欢迎点赞呀，有什么问题也可以在下方评论指出，谢谢