分布式协调服务Zookeeper

分布式系统介绍

分布式系统的定义
《分布式系统原理和范型》一书中定义：分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像是单个相关系统。

从进程角度看，两个程序分别运行在两台主机的进程上，它们互相协作最终完成同一个服务或者功能，那么理论上这个两个程序所组成的系统，也可以称作是"分布式系统"。

分布式系统遇到的挑战

• 1、分布式session
  集群中的各机器之间如何保证Session同步？
• 2、分布式配置中心
  如何在不停应用功能集群的情况下，调整整个集群运行时的行为特征？
• 3、分布式事务
  分布式事务解决的用户最本质诉求是数据一致性。
• 4、分布式锁
  如何解决分布式场景中的数据一致性？需要用到分布式锁。
• 5、分布式定时任务

分布式系统问题的本质

分布式各系统之间都需要进行网络通信，所以本来在单一架构中能保证的数据一致性，升级为分布式系统后数据的一致性就难以保证，而Zookeeper的诞生就可以解决这个本质问题：数据一致性，再加上Zookeeper的其他特性还可以解决分布式锁，分布式定时任务等场景问题。

Zookeeper简介

Apache Zookeeper是Apache软件基金会的一个软件项目，用于为分布式系统提供分布式配置、命名注册、分布式同步以及组服务。

下载与安装

下载地址

下载后解压缩，这里下载的事3.4.13版本，进入zookeeper根目录

conf文件夹下是存放配置文件的地方，复制一份zoo_sample.cfg，名称改为zoo.cfg，这个文件就是zookeeper默认使用的配置文件。

下面看下zoo.cfg配置文件中的各配置项

• tickTime: Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔，以毫秒为单位。Zookeeper中最小的session过期时间是tickTime的两倍。
• initLimit: Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。initLimit用于配置这个同步时间，默认是10倍的tickTime。
• syncLimit: 在发送请求和获得确认之间的时间间隔。比如，Leader发送心跳包后，如果超过了sycnLimit指定的时间间隔后，还没有收到Follower发回的响应，则认为这个Follower已经不在线了。
• dataDir:
  存储快照文件snapshot的目录。默认情况下，事务日志也会存储在这里。建议同时配置参数dataLogDir，事务日志的写性能直接影响zk性能。
• clientPort: 客户端连接服务器的端口

基础命令

• 服务端启动： bin/zkServer.sh start xxxx ，其中xxxx代表配置文件路径（默认使用zookeeper/conf/zoo.cfg），其中start表示启动，选项包括（start|start-foreground|stop|restart|status|upgrade|print-cmd）。

• 客户端连接ZK： bin/zkCli.sh -server ip:port ，ip:port默认使用localhost:2181

• help查看可用的执行命令

• ls /列出根目录下的内容

• 创建节点：
  create /zk_test my_data 在根目录下创建节点，节点名称 zk_test，节点中保存的数据my_data。可以使用flag指定创建的节点是临时的，持久的还是顺序的。不填写代表默认持久。

  • 临时节点： create -e /zk_ephemeral，客户端断开连接时，临时节点会被清除。
  • 顺序节点： create -s /zk_seq，zookeeper会向节点路径填充10为序列号，节点/zk_seq将转换为/zk_seq0000000001，下一个序列号是/xxxx0000000002(xxxx代表输入的节点名称)，顺序递增。

• 获取数据：
  get /zk_test 获取zk_test节点中的数据

• 设置数据：
  set /zk_test my_data2 更新/zk_test节点数据为my_data2

• 删除数据：
  delete /zk_test 删除zk_test节点，有子节点则无法删除

• 递归删除数据：

• rmr /zk_test 删除zk_test节点，包含子节点

• 检查状态：

• stat /zk_test，获取指定znode的元数据，包含时间戳、版本号、ACL、数据长度和znode等细项

更多信息可参考ZooKeeper Programmer’s Guide

zookeeper集群搭建

集群的角色

• 领导者Leader: 选举产生，领导者不接收client的请求，负责进行投票的发起和决议，最终更新状态。
• 跟随者Follower: 用于接收客户请求并返回结果，参与Leader发起的投票。 过多会导致选举算法耗时较多。
• 观察者Observer: 可以接收客户端连接，只接受读请求，将写请求转发给Leader节点，Observer不参与投票，只是同步Leader的状态。
• 学习者Learner: 和Leader进行状态同步的server统称为Learner，上述Follower和Observer都是Learner。

为了方便模拟集群，在单台机器上搭建一套包含4个实例的zookeeper集群(其中包含一个observer)，生产环境中一般在不同的机器上安装实例，并且参加选举的ZK实例数最好是单数。

第一步：复制4个配置文件

端口号分别设为2181、2182、2183、2184

新增数据存放位置，zkjdata文件夹下分别设为 data1、data2、data3、data4

其中zkjqdata，是在zookeeper根目录下新建的文件夹，由于存放集群数据，可根据实际情况自行指定。

第二步：配置文件中增加集群配置

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.4=localhost:2890:3890:observer

其中localhost后面的第一个端口用于同步，第二个端口用于选举Leader。

observer标识该实例的角色是观察者，另外observer所在的节点配置中还需要增加peerType=observer。

peerType=observer 这个选项更多是为了方便运维人员识别哪台机器是Observer，底层并不根据这个配置来判定谁是Observer角色，所以也可以不配

四个配置文件内容如下：
zoo1.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/zookeeper-3.4.13/zkjqdata/data1
clientPort=2181

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.4=localhost:2890:3890:observer

zoo2.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/zookeeper-3.4.13/zkjqdata/data2
clientPort=2182

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.4=localhost:2890:3890:observer

zoo3.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/zookeeper-3.4.13/zkjqdata/data3
clientPort=2183

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.4=localhost:2890:3890:observer

zoo4.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/zookeeper-3.4.13/zkjqdata/data4
clientPort=2184
peerType=observer

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.4=localhost:2890:3890:observer

第三步：新增myid文件
在第一步创建的每个数据文件夹下新增myid文件，文件的内容要和第二步中server.X中".后面的X值对应

比如第一个实例的配置文件内容如下：

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/iflytek/zookeeper-3.4.13/zkjqdata/data1
clientPort=2181

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.4=localhost:2890:3890:observer

那么需要在data1文件夹下新增myid文件，内容为1。

第四步：指定配置文件启动实例
bin/zkServer.sh start /zookeeper-3.4.13/conf/zoo1.cfg
bin/zkServer.sh start /zookeeper-3.4.13/conf/zoo2.cfg
bin/zkServer.sh start /zookeeper-3.4.13/conf/zoo3.cfg
bin/zkServer.sh start /zookeeper-3.4.13/conf/zoo4.cfg

然后使用bin/zkCli -server localhost:2181，bin/zkCli -server localhost:2182，bin/zkCli -server localhost:2183，bin/zkCli -server localhost:2184，分别登录系统看实例是否能成功连上ZK Server。

测试：
1、在某个ZK Server下执行新建命令，看看其它ZK Server是否同步到数据。
2、停止某个ZK Server Leader，看下新选举出来的Leader是哪一个。
3、参与选举的ZK Server 停掉过半，整个集群会处于无法使用状态。
4、停掉observer所在Server，会发现对集群没有影响。

以上请自行测试，这里不再演示。

Observer存在的意义

Zookeeper服务中的每个Server可服务于多个Client，并且Client可连接到ZK服务中的任一台Server来提交请求。若是读请求，则由每台Server的本地副本数据库直接响应。若是改变Server状态的写请求，需要通过一致性协议（Zab协议）来处理。

简单来说，Zab协议规定： 来自Client的所有写请求，都要转发给ZK服务集群中唯一的Leader，由Leader根据该请求发起一个Proposal，然后，其他的Server对该Proposal进行投票。之后，Leader对投票进行收集，当投票数量过半时Leader会向所有的Server发送一个通知消息。最后，当Client所连接的Server收到该消息时，会把该操作更新到内存中并对Client写请求做出回应。

Zookeeper服务器在上述协议中实际扮演了两个职能。一方面从客户端接收连接与操作请求，另一方面对操作结果进行投票。这两个职能在Zookeeper集群扩展的时候彼此制约。例如，当我们希望增加ZK服务中CLient数量的时候，那么我们需要增加Server的数量。然而，从Zab协议对写请求的处理过程中我们可以发现，增加服务器的数量，会增加对协议中投票过程的压力。因为Leader节点必须等待集群中过半Server响应投票，于是节点的增加拖慢整个投票过程的可能性随之增加，导致写操作随之下降。

为此我们引入了不参与投票的服务器，Observer可以接受客户端的连接，并将写请求转发给Leader节点。但是Leader节点不会要求Observer参加投票。相反，Observer不参与投票过程，只接受投票结果。但这种方式也存在一定问题，因为协议中的通知阶段，仍然与服务器的数量呈线性关系。但是这里的串行开销很低，我们可以认为这个阶段的开销不会成为主要瓶颈。

Zookeeper的应用场景

• 统一命名服务
  在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务地址，提供者等信息。比如分布式服务框架中的服务地址列表，在Zookeeper中，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。

• 配置中心
  分布式系统的配置项可以交给Zookeeper管理，将配置信息保存在ZK的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到ZK的通知，然后从ZK中获取新的配置信息应用到系统中。

• 集群管理和Master选举
  利用Zookeeper的两个特性，可以实现对集群机器存活性的监控：

  • 1.客户端在某个节点x上注册一个Watch，那么如果x的子节点发生变化，会通知该客户端
  • 2.创建EPHEMERAL类型的节点，一旦客户端和服务器的回话结束或郭琦，那么该节点就会消失。

  在分布式系统中，有些业务逻辑往往只需要整个集群中的某一台机器执行，其余机器可以共享这个结果，master选举便是这种场景下需要解决的问题。

• 分布式锁
  分布式锁主要得益于Zookeeper为我们保证了数据的强一致性。锁服务可以分为两类：

  • 保持独占
    所有试图来获取这个锁的客户端，最终只有一个可以成功获取。通常的做法是把ZK上的一个znode看做是一把锁，通过create znode的方式来实现。所有客户端都去创建/distribute_lock节点，最终成功创建的客户端也即拥有了这把锁。

  • 控制时序
    所有试图来获取这个锁的客户端，最终都会被安排执行，只是有个全局时序了。做法和保持独占基本类似，只是这里/distribute_lock已经预先存在，客户端在它下面创建临时有序节点。父节点/distribute_lock维持一份sequence，保证子节点创建的时序性，从而形成了每个客户端的全局时序。

Zookeeper中的CAP

Zookeeper满足CAP定理中的CP原则。如果Leader服务器挂掉，需要重新进行选举，在选举过程中，集群是不可用的，牺牲了可用性。

---

------------本文结束感谢您的阅读------------