Storm之Zookeeper安装部署

Zookeeper 导读

CAP理论概述

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

CAP的定义

Consistency 一致性:

一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

Availability 可用性:

可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。也就是，该系统使用的任何算法必须最终终止。当同时要求分区容忍性时，这是一个很强的定义：即使是严重的网络错误，每个请求必须终止。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。通常情况下可用性和分布式数据冗余，负载均衡等有着很大的关联。

Partition Tolerance分区容错性:

分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，或者是机器之间有网络异常，将分布式系统分隔未独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。

CAP权衡

通过CAP理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。

CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流失的严重程度。

对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CA，舍弃P。貌似这几年国内银行业发生了不下10起事故，但影响面不大，报到也不多，广大群众知道的少。还有一种是保证CP，舍弃A。例如网络故障事只读不写。

Zookeeper 定义

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。它使用Java语言编写，通过ZAB协议来保证节点的一致性。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

Zookeeper 基础环境搭建

1. 使用VMware（用户根据自己需要选择Virtualbox/docker等工具）安装centos系统

2. 配置centos系统的网络连接方式为桥接模式，使虚拟机可以上网

a) 点击“编辑”按钮，选择“虚拟网络编辑器”

b) 修改上网方式为桥接模式

c) 查看主机是否获取了IP地址

d) 通过dhclient命令获取IP地址

3. 创建hadoop账户并配置密码

4. 切换到hadoop账户下

cd直接回车，切换到hadoop的主目录下

5. 安装Java

命令安装比较简单：yum install java-1.8.0-openjdk-devel

下面主要介绍下载安装

a) 下载JAVA安装包

wget http://download.oracle.com/otn-pub/java/jdk/8u66-b17/jdk-8u66-linux-x64.tar.gz

b) 创建java目录，并将安装包移到java目录下

c) 进入java目录，并解压该安装包

d) 配置环境变量

编辑主目录下的.bashrc文件，添加java路径

e) 退出hadoop账户再重新进入，测试java能否执行

6. 安装Zookeeper

a) 下载zookeeper安装包

wget http://mirrors.cnnic.cn/apache/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

b) 创建zookeeper目录，并将zookeeper安装包移到zookeeper目录下

c) 进入zookeeper目录，并解压zookeeper压缩包

d) 配置环境变量

编辑主目录下的.bashrc文件，添加zookeeper路径

e) 退出hadoop账户再重新进入,查看环境变量是否导出

f) Zookeeper配置文件修改

创建/var/data/zookeeper文件夹，用于保存zookeeper数据

切到zookeeper配置文件下，修改配置

g) 修改/etc/hostname文件

这样，我们以后就可以通过nimbus、slave1、slave2找到相应的机器，而不用记住IP地址

h) 添加Host-only网卡，组成内部网络 关闭虚拟机，点击“编辑虚拟机配置”选项

点击“添加”选项

点击“网络适配器”，继续

选择“仅主机模式”完成

i) 根据该虚拟机clone出slave1、slave2两个虚拟机 这样我们就可以共享对第一台机器的修改了。

点击“克隆

点击“下一步”

点击“下一步”

此时两个虚拟机的环境和第一台是一样，均已安装好java、zookeeper等软件。

j) 启动三台虚拟机，并分别修改主机名称

在root账户下，分别执行如下命令:

hostnamectl –static set-hostname nimbus

hostnamectl –static set-hostname slave1

hostnamectl –static set-hostname slave2

退出后重新登陆，可以看到hostname名称已经生效

k) 修改host-only网卡静态IP配置，保证每次重启后，该网卡的IP不会改变

nimbus机器的修改如下:

将slave1的 IPADDR0设置为172.xx.1.2

将slave2的 IPADDR0设置为172.xx.1.3

注意：这些IP地址和“g）修改/etc/hostname文件”的IP地址是对应的。

l) 重启机器，确保上步修改的IP地址生效

nimbus拥有IP 172.xx.1.1

slave1拥有IP 172.xx.1.2

slave2拥有IP 172.xx.1.3

在nimbus上分别ping nimbus、salve1和slave2，查看ip地址是否正确以及网络是否正常：

m) 分别修改nimbus、slave1、slave2的zookeeper id

nimbus机器

参考“ f）Zookeeper配置文件修改”

slave1机器

slave2机器

n) 以hadoop账号分别启动zookeeper进程

nimbus：

slave1:

slave2:

o) 查看zookeeper状态

分别在nimbus、slave2、slave3节点查看状态：

各个节点的状态正常，zookeeper集群搭建成功

可以通过zkCli.sh连到zookeeper集群看看集群内部结构