ZooKeeper进阶（一）：Zookeeper简介

ZooKeeper进阶（一）：Zookeeper简介

zookeeper配置文件简介

  下载地址：点我下载
  ZooKeeper 的功能特性通过 ZooKeeper 配置文件来进行控制管理（ zoo.cfg 配置文件）。ZooKeeper 这样的设计其实是有它自身的原因的。通过前面对 ZooKeeper 的配置可以看出，对 ZooKeeper 集群进行配置的时候，它的配置文档是完全相同的（对于集群伪分布模式来说，只有很少的部分是不同的）。这样的配置方使得在部署 ZooKeeper 服务的时候非常地方便。另外，如果服务器使用不同的配置文件，必须要确保不同配置文件中的服务器列表相匹配。
  zookeeper的配置文件在conf目录下，有zoo_sample.cfg，需要将zoo_sample.cfg 改为zoo.cfg，因为zookeeper在启动时会找这个文件作为默认的配置文件。
  在设置 ZooKeeper 配置文档的时候，某些参数是可选的，但是某些参数是必须的。这些必须的参数就构成了 ZooKeeper 配置文档的最低配置要求。
  下面是在最低配置要求中必须配置的参数：
  参数：

最低配置

• tickTime：基本事件单元，以毫秒为单位。它用来控制心跳和超时，默认情况下最小的会话超时时间为两倍的 tickTime 。zookeeper服务器或者客户端与服务器之间维持心跳时间间隔参数。每个ticktime时间就会发送一个心跳。

• dataDir ： zookeeper数据存储目录，存储内存中数据库快照的位置。默认情况会把日志文件保存到这个目录。注意 应该谨慎地选择日志存放的位置，使用专用的日志存储设备能够大大地提高系统的性能，如果将日志存储在比较繁忙的存储设备上，那么将会在很大程度上影响系统的性能。

• clientPort ：zookeeper服务器端口，zookeeper会监听这个端口，接受客户端的请求。

高级配置

  下面是高级配置要求中可选的配置参数，用户可以使用下面的参数来更好地规定 ZooKeeper 的行为：

• dataLogDir : 这个操作将管理机器把事务日志写入到“ dataLogDir ”所指定的目录，而不是“ dataDir”所指定的目录。这将允许使用一个专用的日志设备并且帮助我们避免日志和快照之间的竞争。
• maxClientCnxns : 这个操作将限制连接到 ZooKeeper 的客户端的数量，限制并发连接的数量，它通过 IP来区分不同的客户端。此配置选项可以用来阻止某些类别的 Dos 攻击。将它设置为 0 或者忽略而不进行设置将会取消对并发连接的限制。

集群模式

  zookeeper不仅可以单机提供服务，同时也支持多机组成集群来提供服务。实际上zookeeper还支持另外一种伪集群的方式，就是可以在一台机器上配置多个zookeeper实例。
配置（zoo.cfg)：
initLimit=5
syncLimit=2
server.1=192.168.211.1:2888:3888
server.2=192.168.211.2:2888:3888

• initLimit ：此配置表示，允许 follower （相对于 leader 而言的“客户端”）连接并同步到 leader 的初始化连接时间，它以 tickTime 的倍数来表示。当超过设置倍数的 tickTime 时间，则连接失败。

• syncLimit : 此配置表示， leader 与 follower 之间发送消息，请求和应答时间长度。如果 follower 在设置的时间内不能与 leader 进行通信，那么此 follower 将被丢弃。

• server.A = B : C : D 其中A是一个数字，表示这是第几号服务器；B是这服务器的ip地址；C表示的是这个服务器与集群中的leader服务器交换信息的端口，是供follower和leader进行数据同步通信用的，这个是长连接随时同步数据，健康情况下正常运行，leader宕机就无法正常执行，此时触发选举程序选择新的leader；D表示的是万一集群中的leader服务器挂了，需要一个端口来重新进行选举新的leader。由于这两个端口号完成的是不同的功能，所以C、D两个端口号不能相同。

  除了修改zoo.cfg配置文件，集群模式下还要配置一个文件myid， 这个文件在dataDir目录下，这个文件里面就是一个数据就是A的值，zookeeper启动时会读取这个文件，拿到里面的数据与zoo.cfg里面的配置信息从而判断到底是哪个server。myid文件的内容只有一行，且内容只能为1 - 255之间的数字，这个数字亦即上面介绍server.id中的id，表示zk进程的id。

注意

    单机模式的zk进程虽然便于开发与测试，但并不适合在生产环境使用。在生产环境下，我们需要使用集群模式来对zk进行部署。
    在集群模式下，建议至少部署3个zk进程，或者部署奇数个zk进程。如果只部署2个zk进程，当其中一个zk进程挂掉后，剩下的一个进程并不能构成一个quorum的大多数。因此，部署2个进程甚至比单机模式更不可靠，因为2个进程其中一个不可用的可能性比一个进程不可用的可能性还大。

原理

    zookeeper使用zab协议，类似Paxos算法，但在操作方面却是不同的，该协议包括2个不断重复的阶段：

• 领导者选举：集群所有机器一起选出一台领导者，其它机器成为跟随者，一旦半数以上的跟随者将状态同步，表示这个阶段完成（官方数据这个阶段持续200毫秒）。
• 原子广播：所有机器将写操作转发给领导者，领导者再将更新广播给跟随者，只有半数以上的跟随者同步修改之后领导者才会提交更新，客户端才能收到更新成功的信息。

    它的核心是一个精简的文件系统，形成一个树状的数据结构，统一使用节点（znode）的概念，节点可以有子节点，也可以用来保存数据，并且有一个关联的ACL，因为zookeeper被设计来实现协调服务，通常使用小数据文件，所以znode能存储的数据限制在1M以内。zookeeper采用斜杠分割的Unicode字符串来做引用类似文件系统路径，但必须是标准的，不支持./这种特殊字符，使用/zookeeper子树来保存管理信息。

    客户端与服务器通信采用tcp长连接，客户端和服务器通过心跳来保持seesion的连接。当session失效时临时节点会被删除。

    通过监控节点以及节点的变化来实现例如集群管理，配置的集中管理，分布式锁等功能。

    zookeeper通过复制实现高可用性，只要集群中半数以上的机器可用，就能提供服务，所以一个集群通常要奇数台机器。

    zookeeper的生命周期有以下3个状态CONNECTION,CONNECTED,CLOSED。

    新产生的zookeeper实例是CONNECTION状态，通过建立连接进入CONNECTED状态，当zookeeper实例断开和重连的时候，zookeeper实例在CONNECTED和COONECTION之间转换，调用close方法或者会话超时会进入到CLOSE状态且不能恢复。

应用场景

    Zookeeper从设计模式的角度来看是一个观察者模式的分布式服务管理框架，负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据发生变化，Zookeeper就会负责通知已经注册过了的那些observer做出相应的反应，从而实现集群中类似的Master、Slave管理模式。

统一命名服务（Name Service)

  分布式应用中，通常需要有一套完整的命名规则， 能够产生唯一的名称以便于识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，既对人友好又不会重复。 Name Service是Zookeeper内置的功能， 只须调用其api就可以实现。如调用create接口就可以容易的创建 一个目录节点。（与JNDI 差不多吧）

配置管理

  配置的管理费用在分布式应用环境中很常见，例如同一个应用系统需要多个pc server运行， 但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的的配置项，那么就必须同时修改每台运行这个应用系统的PC server，这样非常容易出错。像这样的配置信息完全可以交给zookeeper管理，将配置信息保存在zookeeper的某个目录节点上，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台机器就会收zookeeper的通知。