Zookeeper 入门

最新推荐文章于 2024-10-23 09:45:00 发布

Java_攻城狮

最新推荐文章于 2024-10-23 09:45:00 发布

阅读量392

点赞数 1

CC 4.0 BY-SA版权

分类专栏： Web 文章标签： zookeeper 分布式应用 web

本文链接：https://blog.youkuaiyun.com/u014266877/article/details/54584960

Web 专栏收录该内容

35 篇文章

订阅专栏

一、Zookerper 简介：
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，Google Chubby 开源实现，Hadoop Hbase 重要组件；
ZooKeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等；
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户；
ZooKeeper包含一个简单的原语集，提供Java和C的接口；
ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口；

二、Zookerper 原理：
    ZooKeeper是以Fast Paxos算法为基础的，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader，只有leader才能提交proposer，具体算法可见 Fast Paxos。

三、Zookeeper中的角色主要有以下三类：
1、领导者 leader 用于更新系统状态；

2、学习者 learner
   2.1、跟随者 follower(控制层)
       用于接口客户请求并向客户端面返回结果；

   2.2、观察者 observer(业务层)
       用于接收客户端连接，将写请求转发给 leader，目的为了展扩系统，提高读取速度；

3、客户端 client；

四、Zookeeper 设计目的：
1.最终一致性：
   client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

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

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

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

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

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

五、ZooKeeper的工作原理：
    Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步,实现这个机制的协议叫做Zab协议,Zab协议有两种模式，它们分别是恢复模式(选主) 广播模式(同步);
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了,状态同步保证了leader和Server具有相同的系统状态。

    为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

   每个Server在工作过程中有三种状态：
      LOOKING：当前Server不知道leader是谁，正在搜寻;
      LEADING：当前Server即为选举出来的leader;
      FOLLOWING：leader已经选举出来，当前Server与之同步;

六、应用场景(http://www.cnblogs.com/tommyli/p/3766189.html)：
    1、数据发布与订阅(配置中心）：
    发布与订阅模型，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

    2、负载均衡：
    这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。

    3、命名服务(Naming Service)：
    命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。

    4、分布式通知/协调：
    ZooKeeper特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理。

    5、集群管理与Master选举：
    集群机器监控：这通常用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器，或者每个机器自己定时向监控系统汇报“我还活着”。这种做法可行，但是存在两个比较明显的问题：

    6、分布式锁：
    分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

    7、分布式队列：
    队列方面，简单地讲有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。