Zookeeper 理论基础

下图是 Zookeeper 的架构图，ZooKeeper 集群中包含 Leader、Follower 以及 Observer 三个角色：

Client 是 Zookeeper 的客户端，请求发起方。

Observer 能很好的对 Zookeeper 集群进行扩展，Observer 可以提供 Client 读写，但不参与投票。因此，Observer 节点对集群不影响投票耗时，也不影响集群选举。另外，加入 Observer 对读性能是一个很大的提升。

应用通过客户端库来对ZooKeeper实现了调用。客户端库负责与ZooKeeper服务器端进行交互。
下展示了客户端与服务器端之间的关系。每一个客户端导入客户端库，之后便可以与任何ZooKeeper的节点进行通信。
ZooKeeper服务器端运行于两种模式下： 独立模式（standalone） 和 仲裁模式（quorum） 。
独立模式 几乎与其术语所描述的一样： 有一个单独的服务器，ZooKeeper状态无法复制 。
在 仲裁模式下 ，具有 一组 ZooKeeper服务器，我们称为ZooKeeper集合（ZooKeeper ensemble），它们之前可以进行状态的复制，并同时为服务于客户端的请求。
从这个角度出发，我们使用术语“ZooKeeper集合”来表示一个服务器设施，这一设施可以由独立模式的一个服务器组成，也可以仲裁模式下的多个服务器组成。

基于此，如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2N+1 台服务器构成的 ZooKeeper 集群。 因此，如果部署了 3 个 Zookeeper 节点（非 Observer），则如果至少有 2个节点可用则整个集群就可用，意味着 1 个节点故障，不影响 Zookeeper 集群对外提供服务；如果部署了 5 个节点，意味着 2 个节点同时故障，Zookeeper 集群依然能够正常对外提供服务。

部署的节点数一般为奇数个，这里不是说不能为偶数个。

通过以上可以发现，3台服务器和4台服务器都最多允许1台服务器挂掉，5台服务器和6台服务器都最多允许2台服务器挂掉,明显4台服务器成本高于3台服务器成本，6台服务器成本高于5服务器成本。这是由于半数以上投票通过决定的。

在对ZooKeeper集合执行任何请求前，一个客户端必须先与服务建立会话。会话的概念非常重要，对ZooKeeper的运行也非常关键。客户端提交给ZooKeeper的所有 *** 作均关联在一个会话上。 当一个会话因某种原因而中止时，在这个会话期间创建的临时节点将会消失。

会话提供了顺序保障 ，这就意味着同一个会话中的请求会以 FIFO（先进先出） 顺序执行。通常，一个客户端只打开一个会话，因此客户端请求将全部以FIFO顺序执行。如果客户端拥有多个并发的会话，FIFO顺序在多个会话之间未必能够保持。而即使一个客户端中连贯的会话并不重叠，也未必能够保证FIFO顺序。

会话的生命周期（lifetime）是指会话从创建到结束的时期，无论会话正常关闭还是因超时而导致过期。
一个会话的主要可能状态大多是简单明了的： CONNECTING 、 CONNECTED 、 CLOSED 和 NOT_CONNECTED 。状态的转换依赖于发生在客户端与服务之间的各种事件（见下图）。

如果一个客户端与服务器因超时而断开连接，客户端仍然保持CONNECTING状态。 如果因网络分区问题导致客户端与ZooKeeper集合被隔离而发生连接断开，那么其状态将会一直保持，直到显式地关闭这个会话，或者分区问题修复后，客户端能够获悉ZooKeeper服务器发送的会话已经过期。 发生这种行为是因为ZooKeeper集合对声明会话超时负责，而不是客户端负责。直到客户端获悉ZooKeeper会话过期，否则 客户端不能声明自己的会话过期。 然而， 客户端可以选择关闭会话。

创建一个会话时，你需要设置会话超时这个重要的参数，这个参数设置了ZooKeeper服务允许会话被声明为超时之前存在的时间。 如果经过时间t之后服务接收不到这个会话的任何消息，服务就会声明会话过期。 而在客户端侧，如果经过t/3的时间未收到任何消息，客户端将向服务器发送心跳消息。在经过2t/3时间后，ZooKeeper客户端开始寻找其他的服务器，而此时它还有t/3时间去寻找。

在仲裁模式下，客户端有多个服务器可以连接，而在独立模式下，客户端只能尝试重新连接单个服务器。在仲裁模式中，应用需要传递可用的服务器列表给客户端，告知客户端可以连接的服务器信息并选择一个进行连接。

当尝试连接到一个不同的服务器时，非常重要的是， 这个服务器的ZooKeeper状态要与最后连接的服务器的ZooKeeper状态保持最新。
ZooKeeper通过在服务中排序更新 *** 作来决定状态是否最新。 ZooKeeper确保每一个变化相对于所有其他已执行的更新是完全有序的。因此，如果一个客户端在位置i观察到一个更新，它就 不能连接到只观察到i'<i的服务器上。
在ZooKeeper实现中，系统根据每一个更新建立的顺序来分配给事务标识符。下图描述了在重连情况下 事务标识符（zkid） 的使用。当客户端因超时与s1 断开连接后，客户端开始尝试连接s2 ，但s2 延迟于客户端所知的变化。然而，s3 对这个变化的情况与客户端保持一致，所以s3 可以安全连接。

Zookeeper 集群高可用部署详解

zookeeper集群只有超过半数节点OK集群才能正常工作,所以集群内节点数量最好为奇数

第一步：主机名称到IP地址映射配置(不做映射也可以直接写ip)

ZooKeeper集群中具有两个关键的角色：Leader和Follower。集群中所有的结点作为一个整体对分布式应用提供服务，集群中每个结点之间都互相连 接，所以，在配置的ZooKeeper集群的时候，每一个结点的host到IP地址的映射都要配置上集群中其它结点的映射信息。

例如:

19216836101 slave-01

19216836102 slave-02

19216836103 slave-03

第二步：修改ZooKeeper配置文件

解压出一个zookeeper程序,然后修改配置文件zoocfg

tickTime=2000 # Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，每个 tickTime 时间就会发送一个心跳。 dataDir=/home/hadoop/storage/zookeeper #Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里

clientPort=2181 #zookeeper提供服务的接口也就是监听客户端连接的端口

initLimit=5 #用来配置 Zookeeper 接受客户端初始化连接时最长能忍受多少个心跳时间间隔数。5就表示最长接受52000=10秒间隔

syncLimit=2 #Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 22000=4 秒

server1=127001:2887:3887

server2=127001:2888:3888

server3=127001:2889:3889

1表示这是第几号服务器/127001是服务器ip/2883是集群Leader交换信息的端口/Leader挂了重新选举Leader的端口

第三步：复制分发安装文件

如果各个zookeeper在不同服务器,集群中的zookeeper 配置文件都是跟上面相同的,所以只需要复制然后放在需要的主机上就可以

还有修改dataDir 和logDir 保证各自使用自己的配置文件

例如:

server1=127001:2887:3887

server2=127001:2888:3888

server3=127001:2889:3889

第四步：设置myid

在我们配置的dataDir指定的目录下面，创建一个myid文件，里面内容为一个数字，用来标识当前主机，对应于conf/zoocfg文件中配置的serverX中的X，例如：server1的dataDir下应该建立一个myid的文件,其中写入1

第五步：启动ZooKeeper集群

第六步：验证

由于前面的节点在启动时候会尝试去连接其他节点,所以先启动的节点会有报错信息,这是正常的不用理会,等到leader选举出来了就可以正常工作了

如何启动zookeeper-336？

启动zookeeper-336的方法：下载安装配置zookeeper的服务器环境-创建文件-设置权限-编辑-重启即可。

具体步骤：

一、登陆linux服务器用cd 命令切换到/etc/rcd/initd/目录下。

二、touch zookeeper创建一个文件。

三、为文件添加可执行权限chmod +x zookeeper。

四、用vi zookeeper来编辑这个文件。

五、在zookeeper里面输入如下内容。

六、保存退出。

七、用service zookeeper start/stop来启动停止zookeeper服务。

八、使用chkconfig --add zookeeper命令吧zookeeper添加到开机启动里面。

九、使用chkconfig --list 来看看添加的zookeeper是否在里面。

十、重启即可。

---