Hadoop生态圈(六)──Zookeeper的安装与应用

前言

思想核心

拜占庭将军问题是一个共识问题: 首先由Leslie Lamport与另外两人在1982年提出，被称为The Byzantine Generals Problem或者Byzantine Failure。核心描述是军中可能有叛徒，却要保证进攻一致，由此引申到计算领域，发展成了一种容错理论。随着比特币的出现和兴起，这个著名问题又重入大众视野。 那么今天要给大家引入的是zookeeper分布式服务…那么在区域链当中,也出现了类似的问题，而这个问题也是搁置了很久才在2008年(应该是)提出解决方案的，他的实现原理是工作量证（PoW）其实相当于提高了做叛徒（发布虚假区块）的成本，在这个系统下，只有第一个完成证明的节点才能广播区块，竞争难度非常大，需要很高的算力,如果不成功的话那么也就白白耗费了…

Zookeeper的简介

Zookeeper在官网当中给出What is Zookeeper?官网这样写到:

大致描述为ZooKeeper是一种集中式服务，用于维护配置信息，命名，提供分布式同步和提供组服务 Apache ZooKeeper是Apache软件基金会的软件项目；它为大型分布式系统中的各种协调问题提供了一个开源的解决方案。ZooKeeper最初是在Yahoo !公司开发的。

作为一个集中的协调服务，ZooKeeper是分布式且高度可靠的，运行在一个名为ZooKeeper集成的服务器集群上。分布式协商一致、组管理、存在协议和领导选举由服务实现，这样应用程序就不需要通过自己的实现来重新定义车轮。在这些之上，由ZooKeeper公开的原语可以被应用程序用来构建更强大的抽象来解决各种各样的问题。

Apache ZooKeeper是用Java实现的。它附带了C、Java、Perl和Python客户端绑定。社区提供的客户端库可以用于多种语言，如Go、Scala、Erlang等。

Zookeeper集群的搭建
最快的实现方式就是去百度搜索一下安装文档,当然笔者这里也有一份详细的安装教程(私我),下面废话就不多说了直接开始安装吧
1.准备zookeeper压缩包 (版本可以去官网下载最新)

2.上传到linux虚拟机

3.上传完毕后进行文件的解压

tar -zxf  zookeeper-3.4.10   解压到你的软件常用位置

4.配置环境变量
vi /etc/profile

5.配置zookeeper的配置
进入zookeeper家目录中conf目录下，可看到一个zoo_sample.cfg文件
拷贝重命名：cp zoo_sample.cfg zoo.cfg
配置zoo.cfg: vi zoo.cfg

6.分发配置到另外的集群

进入数据目录/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/）,否则就是把该目录的内容发过去，目录名称不会分发！！！
7.启动集群
ZkServer.sh start 开启集群
ZkServer.sh status 查看状态
ZkServer.sh stop 关闭集群
注意事项:
1.我们在开启集群的时候一定要全部开启才去查看查看状态,要不然会出现报错
2.配置文件的myid一定要写对不要重复
3.注意细节 全局环境变量 一定要source /etc/profile

zookeeper的理解

1.角色的分配

○ 领导者(leader)，负责进行投票的发起和决议，更新系统状态

○ 学习者(learner)，包括跟随者（follower）和观察者（observer），

○ follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票

○ Observer可以接受客户端请求，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。

○ 客户端(client)，请求发起方

系统模型如下:

2.工作原理
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分 别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

    为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上 了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个 新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

每个Server在工作过程中有三种状态：

• LOOKING：当前Server不知道leader是谁，正在搜寻
• LEADING：当前Server即为选举出来的leader
• FOLLOWING：leader已经选举出来，当前Server与之同步

3.选举机制

服务器ID
比如说下面有三台服务器，编号分别是1,2,3。在我们的选择算法当中编号越大被选择的权重也就是最大的,会优先考虑编号3!
数据ID
如果说我们的数据ID分别对应着 1,2,3,那么说明数据越新被选择的可能性也就是最大的
逻辑时钟
或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。我们会在最开始先去比较ID如果出现两个ID相等的话,那么它们会在进行新一轮的投票,直到结果比较出来…
选举流程图

4.zookeeper的节点类型

首先我们可以根据类型的存活时间进行一个分类持久态和临时态,那么对于临时态的理解是当我的创建临时态,我首先去访问它他会存在,当我关闭连接的时候,再次连接的时候我再次访问的时候它会消失。对于持久态来说:我创建节点后,即使我主动断开后,我再次链接的时候节点也会存在除非我主动的去删除节点才会消失…

1.连接客户端

   zkServer.sh -server 192.168.100.128:2181(默认端口)

2.持久节点的创建

  create /name

3.节点查看

 ls /

4.节点内容的查看

 cat /name

5.删除节点

 delete /name

五.zookeeper的特性

1. C 一致性（consistence）：数据在分布式环境下的多个副本之间能否保持一致性，这里的一致性更多是指强一致性；
2. A 可用性（able）：分布式系统一直处于可用状态，对于请求总是能在有限的时间内返回结果致性；
3. P 分区容错性(partition)：除非整个网络故障，分布式系统在任何网络或者单点故障时，仍能对外提供满足一致性和可用性的服务；
4. 原子性:更新数据只有成功和失败没有中间数据的特性
5. 实时性:数据是一直不断更新的…
6. 顺序性:按照顺序进行的
7. 单一视图:最终呈现的视图都是一样,那怕是我其中的一个节点中途失败了,当我再次恢复的时候我会fetch磁盘的数据,进行数据的恢复最后呈现的内容视图也是一致的!

---

参考博文

友情链接:https://blog.csdn.net/yu757371316/article/details/80742223
友情链接:https://www.cnblogs.com/ASPNET2008/p/6421571.html