标签：
ZooKeeper 是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等； 它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper 主要包含以下几个特点：
1)、最终一致性：为客户端展示同一视图，这是 ZooKeeper 最重要的性能。
2)、可靠性：如果消息被一台服务器接受，那么它将被所有的服务器接受。
3)、实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4)、等待无关（wait-free）：慢的或者失效的 client 不干预快速的client的请求。
5)、原子性：更新只能成功或者失败，没有中间其它状态。
6)、顺序性：对于所有Server，同一消息发布顺序一致。
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。这个Leader 会将写请求广播给各个Server，比如Server1和Server2， 各个Server写成功后就会通知Leader。
3)、当Leader收到大多数 Server 数据写成功了，那么就说明数据写成功了。如果这里三个节点的话，只要有两个节点数据写成功了，那么就认为数据写成功了。写成功之后，Leader会告诉Server1数据写成功了。
4)、Server1会进一步通知 Client 数据写成功了，这时就认为整个写操作成功。
统一命名服务
统一命名服务的命名结构图如下所示。
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方式进行入队和出队操作，例如实现生产者和消费者模型。
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）
dataDir=/zookeeper/zookeeper-3.4.5/data
server.1=cs0:2888:3888
server.2=cs1:2888:3888
server.3=cs2:2888:3888
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
标签：
原文地址：http://blog.csdn.net/u010330043/article/details/51209939
