博客

Hadoop常用组件zookeeper,kafka

ZooKeeper是一个开源的分布式应用程序协调系统。简称ZK，ZK是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于它实现数据的发布/订阅、负载均衡、名称服务、分布式协调/通知、集群管理、Master选举、分布式锁盒分布式队列等等功能。它运行在JAVA环境之中，并具有JAVA和C的绑定。

zookeeper集群

集群角色

•**Leader：**领导者，通过集群选举产生的主节点，负责集群的读与写工作

•**Follower：**追随者，有资格参与集群选举，但未能被成功选举为

Leader

的备用选举节点，负责集群的读服务

• **Observer：**观察者，没有资格参与集群选举，负责集群的读服务，同步

Leader

状态

注意：当Leader故障之后ZooKeeper集群会通过Follower选举新的Leader，如果老的Leader故障修复之后，会再次接管集群中的Leader脚本，新的Leader则退回Follower角色。一般集群当中无需设置Observer节点，Follower节点即可。

zookeeper工作原理

上图中有5个ZooKeeper节点，其中一个节点为Leader，除leader节点外，其它都是追随者Follower，Client与ZK集群建立TCP长连接，只有追随者Follower节点来与Client建立连接(我们的Client与Follower建立的连接会始终存在，只有Client不再参与集群或者客户端出现故障之后才会断开连接，是一个持久会话，通过此会话，Client会不短向自己所连接的Follower更新自己的状态信息)，并处理Client的请求，如果Client为读请求，则会转发到Follower或者本机进行处理，如果为写请求则转发给Leader处理。如果Client与连接的一台ZK集群中的服务器发生数据变更，则ZK集群中的这台服务器会把变更内容同步到ZK集群中的所有ZK服务器。

假如上图中的Client为Kafka，一共有8台Kafka，Kafka的集群配置信息全部是由ZooKeeper来维护，如果没有ZooKeeper，Kafka的单节点就不知道它们是个集群或者集群中共有那些节点，有了ZooKeeper之后，Kakfa节点会向ZK集群发出请求来询问他们的Kafka一共有几个集群节点，哪个节点还在工作，哪个节点为故障节点等等的集群信息全部都是由ZooKeeper来维护，如果想知道这些信息，Kafka就会去ZK集群节点中去请求一个

数据分支

，所有有了前面我们介绍ZooKeeper是的一个开源的分布式应用程序协调系统。通过ZooKeeper提供的服务来与Kafka集群的其它节点互知。

ZAB协议

ZooKeeper(ZooKeeper Atomic Broadcast，ZooKeeper原子广播协议)是通过ZAB协议来完成了Client各个节点选举的信息，ZAB协议是整个ZooKeeper的核心，支持崩溃保护机制，用于在Leader崩溃时重新选举出新的Leader，而且还要确保数据的完整性和一至性，此协议不仅能够保证ZooKeeper集群本身的选举，还能管理使用ZooKeeper协调服务的分布式程序的选举工作。

ZAB协议中存在的三种状态：

（1）Looking：集群刚启动，开始选举Leader，或者Leader崩溃之后再次选举新的Leader时，正在选举，被称为Looking状态。

（2）Following：Following就是Follower状态，这个时候集群中已经存在Leader，这些机器属于Follover节点称之为Following状态。

（3）Leading：Leader就被称为Leading状态。

ZAB协议中的存在的四个阶段：

•选举：election

•发现：discovery

•同步：sync

•广播：Broadcast

部署zookeeper

集群准备

hadoop1 192.168.15.10

hadoop2 192.168.15.130

hadoop3 192.168.15.131

hadoop4 192.168.15.132

[root@hadoop1 ~]# tar -xf zookeeper-3.4.13.tar.gz -C /usr/local/zookeeper/
[root@hadoop1 ~]# mv /usr/local/zookeeper-3.4.13/ /usr/local/zookeeper
[root@hadoop1 ~]# cd /usr/local/zookeeper/zookeeper/conf