linux下的Zookeeper集群介绍

一、Zookeeper原理简介

ZooKeeper是一个开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。

• zookeeper是一个分布式服务协调开源框架，用来解决分布式集群应用系统一致性的问题。例如避免同时读写一个数据造成的脏读问题。
• zookeeper是一个分布式小文件存储系统，提供类似于文件系统目录树方式的数据存储，并且可以对树中的节点进行有效的管理。从而用来维护和监控存储的数据变化，通过监控这些数据状态的变化来，从而达到基于数据的集群管理。例如统一命名服务、分布式配置管理、分布式消息队列、分布式协调、分布式锁等。

二、Zookeeper设计目的

1. 最终一致性：client不论连接到那个Server，展示给它的都是同一个视图。每一个服务保存一份相同的数据副本，客户端无论访问哪一个服务，展示的数据都是一致的，这个特征最重要！
   

2. 可靠性：具有简单、健壮、良好的性能、如果消息m被到一台服务器接收，那么消息m将被所有服务器接收。

   如果消息被其中的一台服务器接受，那么将被所有的服务器接受，比如：上图中，在机器cs-1上面把文件cd删除了，那么其他机器上面cd文件都会被删除，这就保证了全局数据一致性。

3. 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4. 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5. 原子性：一次数据更新要么成功（半数以上节点成功，如上图只要2台机器上面的数据操作成功，那么就是数据更新成功），要么失败，不存在中间状态。

6. 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

三、Zookeeper工作原理

1、在zookeeper的集群中，各个节点共有下面3种角色和4种状态：

角色：leader,follower,observer
状态：leading,following,observing,looking

• Leader:是Zookeeper集群的核心，是事务请求的唯一调度者和处理者，保证集群事务处理的顺序性，集群内部服务器调度者（同步状态、信息），对于像创建、修改、删除等有写操作的请求，那么会统一转发给leader处理，leader统一全局编号、执行操作这个过程称为一个事务。

  比如：client1访问其中的一个服务器（非leader），执行一个文件的修改操作，而client2也访问这台机器，也要修改这个文件，那么这个server，会把这个两个请求转发给leader服务器，让leader决定执行顺序，然后根据顺序执行修改，保证数据的一致性。

• Follower:处理非事务性请求，读操作；转发事务性请求给leader；参与集群leader选举，比如集群启动的时候要选举一个leader出来或者中间leader宕机，重新选举一leader出来。

• observer：访问量较大的集群，还会有观察者角色observer观察Zookeeper集群最新状态并将这些装填同步过来；独立处理非事务性请求；转发事务性请求给leader；不参与任何形式的投票。通常被用来扩展集群的非事务集群能力，提高客户端请求速度。

每个Server在工作过程中有4种状态：

• LOOKING：当前Server不知道leader是谁，正在搜寻。
• LEADING：当前Server即为选举出来的leader。
• FOLLOWING：leader已经选举出来，当前Server与之同步。
• OBSERVING：observer的行为在大多数情况下与follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果。