理解ZooKeeper基本原理及安装部署

转：m.blog.csdn.net/article/details?id=51209939

1. ZooKeeper 是什么

ZooKeeper 是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等； 它的目

标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

2. ZooKeeper特点

ZooKeeper 主要包含以下几个特点：

1)、最终一致性：为客户端展示同一视图，这是 ZooKeeper 最重要的性能。

2)、可靠性：如果消息被一台服务器接受，那么它将被所有的服务器接受。

3)、实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4)、等待无关（wait-free）：慢的或者失效的 client 不干预快速的client的请求。

5)、原子性：更新只能成功或者失败，没有中间其它状态。、

6)、顺序性：对于所有Server，同一消息发布顺序一致。

3. ZooKeeper 基本原理

ZooKeeper 架构

　下面我们首先看一下 ZooKeeper 的架构图。

 

针对上面的 ZooKeeper 架构图，我们需要掌握以下几点内容。

　　1）、每个Server 在内存中存储了一份数据。

　　2）、ZooKeeper 启动时，将从实例中选举一个 leader（根据Paxos协议来选举，大家知道有这么个协议即可）。

　　3）、Leader 负责处理数据更新等操作（这里用到Zab协议，大家知道有这么个协议即可）

　　4）、一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据

Zookeeper 角色

　　Zookeeper中的角色主要有以下三类，如下表所示：

角色	描述
领导者 leader）	领导者负责进行投票的发起和决议，更新系统状态。
学习者（Learner或 跟随者（Follower）	Follower 用于接收客户请求并向客户端返回结果，在选主过程中参与投票。
观察者 （ObServer）	ObServer 可以接收客户端连接，将写请求转发给leader节点。但Observer 不参加投票过程，只同步 leader的状态。ObServer 的目的是为了扩展系统，提高读取速度。
客户端 （Client）	应用程序客户端，请求发起方。

思考：1、为什么需要server? 

             ①ZooKeeper 需保证高可用和强一致性。 

　　　　②为了支持更多的客户端，需要增加更多的Server。 

　　　　③Follower增多会导致投票阶段延迟增大，影响性能。 
　　　２、在Zookeeper 中server起到什么作用？ 

　　　　①ObServer 不参与投票过程，只同步 leader的状态 

　　　　②Observers 接受客户端的连接，并将写请求转发给 leader节点 

　　　　③加入更多ObServer 节点，提高伸缩性，同时还不影响吞吐率。 

　　　３、为什么在Zookeeper中Server 数目一般为奇数？ 

　　我们知道在Zookeeper中 Leader 选举算法采用了 Paxos 协议。Paxos 核心思想是当多数 Server 写成功，则任务数据写成功。 

　　 　①如果有3个Server，则最多允许1个Server 挂掉。 

　　　 ②如果有4个Server，则同样最多允许1个Server挂掉。 

　　　 既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeper Server即可，这里选择3个Server。

ZooKeeper 写数据流程

ZooKeeper 写数据的流程图如下所示。 

ZooKeeper 的写数据流程主要分为以下几步：

1)、比如 Client 向 ZooKeeper 的 Server1 上写数据，发送一个写请求。

2)、如果Server1不是Leader，那么Server1 会把接受到的请求进一步转发给Leader，因为每个ZooKeeper的Server里面有一个是Leader。这个Leade

r 会将写请求广播给各个Server，比如Server1和Server2， 各个Server写成功后就会通知Leader。

3)、当Leader收到大多数 Server 数据写成功了，那么就说明数据写成功了。如果这里三个节点的话，只要有两个节点数据写成功了，那么就认为数据

写成功了。写成功之后，Leader会告诉Server1数据写成功了。

4)、Server1会进一步通知 Client 数据写成功了，这时就认为整个写操作成功。

4. ZooKeeper 应用场景总结

• 统一命名服务

  　统一命名服务的命名结构图如下所示。

• 
  

1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。

　　　　1）类似于域名与ip之间对应关系，ip不容易记住，而域名容易记住。

　　　　2）通过名称来获取资源或服务的地址，提供者等信息。

2、按照层次结构组织服务/应用名称。

　　　　1）可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。

配置管理

配置管理结构图如下所示。

1、分布式环境下，配置文件管理和同步是一个常见问题。

　　1）一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。

　　2）对配置文件修改后，希望能够快速同步到各个节点上。

2、配置管理可交由ZooKeeper实现。 

　　1）可将配置信息写入ZooKeeper上的一个Znode。

　　2）各个节点监听这个Znode。

　　3）一旦Znode中的数据被修改，ZooKeeper将通知各个节点。

集群管理

　　　集群管理结构图如下所示。

1、分布式环境中，实时掌握每个节点的状态是必要的。

　　1）可根据节点实时状态做出一些调整。

2、可交由ZooKeeper实现。

　　1）可将节点信息写入ZooKeeper上的一个Znode。

　　2）监听这个Znode可获取它的实时状态变化。

3、典型应用

　　1）HBase中Master状态监控与选举。

分布式通知与协调

1、分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。

　　1）NameNode需知道各个Datanode的状态。

　　2）JobTracker需知道各个TaskTracker的状态。

2、心跳检测机制可通过ZooKeeper来实现。

3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统。

• 分布式锁
• 
  

处于不同节点上不同的服务，它们可能需要顺序的访问一些资源，这里需要一把分布式的锁。分布式锁具有以下特性：

1、ZooKeeper是强一致的。比如各个节点上运行一个ZooKeeper客户端，它们同时创建相同的Znode，但是只有一个客户端创建成

功。

2、实现锁的独占性。创建Znode成功的那个客户端才能得到锁，其它客户端只能等待。当前客户端用完这个锁后，

会删除这个Znode，其它客户端再尝试创建Znode，获取分布式锁。

3、控制锁的时序。各个客户端在某个Znode下创建临时Znode，这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL，

这样该Znode可掌握全局访问时序。

• 分布式队列
• 
  

分布式队列分为两种：

1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。

　　1）一个job由多个task组成，只有所有任务完成后，job才运行完成。

　　2）可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，

则表明job运行完成。

2、队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型。

５. ZooKeeper 安装部署

• 分布式模式
• 
  

1.上传zookeeper安装包

2.解压 

tar -zxvf zookeeper-3.4.5.tar.gz -C /zookeeper/ 

3.配置（先在一台节点上配置） 

　　3.1添加一个zoo.cfg配置文件 

　　　在解压目录　/zookeeper/zookeeper-3.4.5/conf　下将zoo_sample.cfg重新命名为zoo.cfg 

　　   mv zoo_sample.cfg zoo.cfg

　　3.2修改配置文件（zoo.cfg） 

tickTime=2000
initLimit=5
syncLimit=2
dataDir=/home/zookeeper-3.4.5/data
dataLogDir=/home/zookeeper-3.4.5/logs 
clientPort=2181
server.1=cs1:2888:3888
server.2=cs2:2888:3888
server.3=cs3:2888:3888

initLimit: zookeeper集群中的包含多台server, 其中一台为leader, 集群中其余的server为follower. initLimit参数配置初始化连接时, 

follower和leader之间的最长心跳时间. 此时该参数设置为5, 说明时间限制为5倍tickTime, 即5*2000=10000ms=10s.

syncLimit: 该参数配置leader和follower之间发送消息, 请求和应答的最大时间长度. 此时该参数设置为2, 说明时间限制为2倍tickTime, 即4000ms.

server.X=A:B:C 其中X是一个数字, 表示这是第几号server. A是该server所在的IP地址. B配置该server和集群中的leader交换消息所使用的端口. C配置选举leader时所使用的端口. 由于配置的是伪集群模式, 所以各个server的B, C参数必须不同.

3.3在（dataDir=/zookeeper/zookeeper-3.4.5/data）创建一个myid文件，里面内容是server.N中的N（server.2里面内容为2） 

echo “1” > myid

　　3.4将配置好的zk拷贝到其他节点

scp -r /zookeeper/zookeeper-3.4.5/ 　cs1:/ 

scp -r /zookeeper/zookeeper-3.4.5/　 cs2:/

3.5注意：在其他节点上一定要修改myid的内容

在cs1应该讲myid的内容改为2 （echo “2” > myid） 

在cs2应该讲myid的内容改为3 （echo “3” > myid）

4.在解压目录下启动集群 

　　分别启动zk 

　　　　bin/zkServer.sh start 

　　查看znode的状态 

　　　 　bin/zkServer.sh status