最近一直有小伙伴私信我,问一些关于Zookeeper的知识,下边关于的Zookeeper的知识整理了一下,一起学习一下。

看完本文对于Zookeeper想深入全面了解的读者朋友们,小编这里整理了一份更加全面的zookeeper源码分析.pdf文档,需要获取的朋友们可以加入进我的Q裙来获取到!

907831724  点击群号即可立刻加入群聊!

一、ZooKeeper 基本概念

1、ZooKeeper 是什么?

Zookeeper官网地址: http://zookeeper.apache.org/

Zookeeper官网文档地址:http://zookeeper.apache.org/doc/trunk/index.html

ZooKeeper 是Hadoop下的一个子项目,它是一个针对大型分布式系统的可靠协调系统;它提供的功能包括:配置维护、名字服务、分布式同步、组服务等; 它的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。

Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心,服务生产者将自己提供的服务注册到Zookeeper中心,服务的消费者在进行服务调用的时候先到Zookeeper中查找服务,获取到服务生产者的详细信息之后,再去调用服务生产者的内容与数据,简单示例图如下:

2、ZooKeeper设计目标:

ZooKeeper允许分布式进程通过共享的层次结构命名空间进行相互协调,这与标准文件系统类似。 名称空间由ZooKeeper中的数据寄存器组成 - 称为znode,这些类似于文件和目录。 与为存储设计的典型文件系统不同,ZooKeeper数据保存在内存中,这意味着ZooKeeper可以实现高吞吐量和低延迟。

Zookeeper层次结构命名空间示意图如下:

通过这种树图结构的数据模型,很容易的查找到具体的某一个服务。

3、ZooKeeper主要特点

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

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

3)、实时性:ZooKeeper 不能保证两个客户端同时得到刚更新的数据,如果

需要最新数据,应该在读数据之前调用sync()接口。

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

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

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

二、ZooKeeper 基本原理

1、ZooKeeper 系统架构

首先看一下 ZooKeeper 的架构图。

ZooKeeper 的架构图中我们需要了解和掌握的主要有:

(1)ZooKeeper分为服务器端(Server) 和客户端(Client),客户端可以连接到整个 ZooKeeper服务的任意服务器上(除非 leaderServes 参数被显式设置, leader 不允许接受客户端连接)。

(2)客户端使用并维护一个 TCP 连接,通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断,客户端将自动尝试连接到另外的 ZooKeeper服务器。客户端第一次连接到 ZooKeeper服务时,接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时,这个会话会被新的服务器重新建立。

(3)上图中每一个Server代表一个安装Zookeeper服务的机器,即是整个提供Zookeeper服务的集群(或者是由伪集群组成);

(4)组成ZooKeeper服务的服务器必须彼此了解。 它们维护一个内存中的状态图像,以及持久存储中的事务日志和快照, 只要大多数服务器可用,ZooKeeper服务就可用;

(5)ZooKeeper 启动时,将从实例中选举一个 leader,Leader 负责处理数据更新等操作,一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server 在内存中存储了一份数据。

(6)Zookeeper是可以集群复制的,集群间通过Zab协议(Zookeeper Atomic Broadcast)来保持数据的一致性;

(7)Zab协议包含两个阶段:leader election阶段和Atomic Brodcast阶段。

  • a) 集群中将选举出一个leader,其他的机器则称为follower,所有的写操作都被传送给leader,并通过brodcast将所有的更新告诉给follower。
  • b) 当leader崩溃或者leader失去大多数的follower时,需要重新选举出一个新的leader,让所有的服务器都恢复到一个正确的状态。
  • c) 当leader被选举出来,且大多数服务器完成了 和leader的状态同步后,leadder election 的过程就结束了,就将会进入到Atomic brodcast的过程。
  • d) Atomic Brodcast同步leader和follower之间的信息,保证leader和follower具有形同的系统状态。

2、Zookeeper 角色

启动 Zookeeper 服务器集群环境后,多个 Zookeeper 服务器在工作前会选举出一个 Leader。选举出 leader 前,所有 server 不区分角色,都需要平等参与投票( obServer 除外,不参与投票);

选主过程完成后,存在以下几种角色:

思考:

1、为什么需要server?

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

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

③Follower增多会导致投票阶段延迟增大,影响性能。

2、在Zookeeper 中ObServer 起到什么作用?

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

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

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

3、为什么在Zookeeper中Server 数目一般为奇数?

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

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

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

3、ZooKeeper 写数据流程

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

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

  • a)、比如 Client 向 ZooKeeper 的 Server1 上写数据,发送一个写请求。
  • b)、如果Server1不是Leader,那么Server1 会把接受到的请求进一步转发给Leader,因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server,比如Server1和Server2, 各个Server写成功后就会通知Leader。
  • c)、当Leader收到大多数 Server 数据写成功了,那么就说明数据写成功了。如果这里三个节点的话,只要有两个节点数据写成功了,那么就认为数据写成功了。写成功之后,Leader会告诉Server1数据写成功了。
  • d)、Server1会进一步通知 Client 数据写成功了,这时就认为整个写操作成功。

4、ZooKeeper 组件

ZooKeeper组件显示了ZooKeeper服务的高级组件。 除了请求处理器,组成ZooKeeper服务的每个服务器复制其自己的每个组件的副本。

Replicated Database是包含整个数据树的内存数据库。 更新操作会记录到磁盘里以进行可恢复性,并且写操作将在放到内存数据库之前序列化到磁盘。

每个ZooKeeper服务器服务客户端。 客户端连接到一个服务器以提交irequest。 读取请求从每个服务器数据库的本地副本服务。 更改服务状态(写入请求)的请求由协议进行处理。

作为协议协议的一部分,来自客户端的所有写请求被转发到单个服务器,称为leader。 其余的ZooKeeper服务器(称为followers)从领导者接收消息提议并同意消息传递。 消息层负责在失败时替换领导者,并与leader同步followers。

三、ZooKeeper 应用场景总结

1、统一命名服务

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

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

a)类似于域名与ip之间对应关系,ip不容易记住,而域名容易记住。

b)通过名称来获取资源或服务的地址,提供者等信息。

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

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

2、配置管理

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

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

a)一个集群中,所有节点的配置信息是一致的,比如 Hadoop 集群。

b)对配置文件修改后,希望能够快速同步到各个节点上。

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

a)可将配置信息写入ZooKeeper上的一个Znode。

b)各个节点监听这个Znode。

c)一旦Znode中的数据被修改,ZooKeeper将通知各个节点。

3、集群管理

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

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

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

2、可交由ZooKeeper实现。

a)可将节点信息写入ZooKeeper上的一个Znode。

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

3、典型应用

a)HBase中Master状态监控与选举。

4、分布式通知与协调

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

a)NameNode需知道各个Datanode的状态。

b)JobTracker需知道各个TaskTracker的状态。

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

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

5、分布式锁

处于不同节点上不同的服务,它们可能需要顺序的访问一些资源,这里需要一把分布式的锁。

分布式锁具有以下特性:

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

2、实现锁的独占性。创建Znode成功的那个客户端才能得到锁,其它客户端只能等待。当前客户端用完这个锁后,会删除这个Znode,其它客户端再尝试创建Znode,获取分布式锁。

3、控制锁的时序。各个客户端在某个Znode下创建临时Znode,这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL,这样该Znode可掌握全局访问时序。

6、分布式队列

分布式队列分为两种:

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

a)一个job由多个task组成,只有所有任务完成后,job才运行完成。

b)可为job创建一个/job目录,然后在该目录下,为每个完成的task创建一个临时的Znode,一旦临时节点数目达到task总数,则表明job运行完成。

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

浅谈ZooKeeper基本原理与源码分析的更多相关文章

  1. Android事件分发机制浅谈(三)--源码分析(View篇)

    写事件分发源码分析的时候很纠结,网上的许多博文都是先分析的View,后分析ViewGroup.因为我一开始理解的时候是按我的流程图往下走的,感觉方向很对,单是具体分析的时候总是磕磕绊绊的,老要跳到Vi ...

  2. Android事件分发机制浅谈(二)--源码分析(ViewGroup篇)

    上节我们大致了解了事件分发机制的内容,大概流程,这一节来分析下事件分发的源代码. 我们先来分析ViewGroup中dispatchTouchEvent()中的源码 public boolean dis ...

  3. 浅谈.Net Core DependencyInjection源码探究

    前言     相信使用过Asp.Net Core开发框架的人对自带的DI框架已经相当熟悉了,很多刚开始接触.Net Core的时候觉得不适应,主要就是因为Core默认集成它的原因.它是Asp.Net ...

  4. 浅谈nornalize.css(含源码)

    Normalize.css是一种CSS reset的替代方案.经过@necolas和@jon_neal花了几百个小时来努力研究不同浏览器的默认样式的差异,这个项目终于变成了现在这样. 我们创造norm ...

  5. ConcurrentHashMap——浅谈实现原理及源码

    本文整理自漫画:什么是ConcurrentHashMap? - 小灰的文章 - 知乎 .已获得作者授权. HashMap 在高并发下会出现链表环,从而导致程序出现死循环.高并发下避免HashMap 出 ...

  6. mybatis缓存源码分析之浅谈缓存设计

    本文是关于mybatis缓存模块设计的读后感,关于缓存的思考,关于mybatis的缓存源码详细分析在另一篇文章:https://www.cnblogs.com/gmt-hao/p/12448896.h ...

  7. zookeeper源码分析之五服务端(集群leader)处理请求流程

    leader的实现类为LeaderZooKeeperServer,它间接继承自标准ZookeeperServer.它规定了请求到达leader时需要经历的路径: PrepRequestProcesso ...

  8. zookeeper源码分析之四服务端(单机)处理请求流程

    上文: zookeeper源码分析之一服务端启动过程 中,我们介绍了zookeeper服务器的启动过程,其中单机是ZookeeperServer启动,集群使用QuorumPeer启动,那么这次我们分析 ...

  9. zookeeper源码分析之三客户端发送请求流程

    znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个功能是zookeeper对于应用最重要的特性,通过这个特性可以实现的功能包括配置的 ...

随机推荐

  1. 纯HTML+JS实现轮播

    <!DOCTYPE html> <html lang="en" xmlns="http://www.w3.org/1999/xhtml"> ...

  2. python基础-流程控制(if,while,for)

    今日内容总结 --流程控制(if,while,for) if:用来判断事物的对错.真假.是否执行.根据不同的情况判断,条件满足执行某条件下的语句 语法结构(3种) # 第一种,只有if结构.条件表达式 ...

  3. 记 Maven 本地仓库埋坑之依赖包为何不能用

    记一次 Maven 本地仓库埋坑之 Verifying Availability 背景 某 Java 后端项目使用 maven 构建,因为某些原因,某些依赖库下载不了,直接找其它人索要了他电脑上的 m ...

  4. CSPS模拟 53

    T1 两种差分,拆分转化 T2 状压,hash压状态卡空间 T3 dfs,分类讨论.

  5. [UWP]使用SpringAnimation创建有趣的动画

    1. 什么是自然动画 最近用弹簧动画(SpringAnimation)做了两个番茄钟,关于弹簧动画官方文档已经介绍得够详细了,这篇文章就摘录一些官方文档核心内容. 在传统UI中,关键帧动画(KeyFr ...

  6. 重置root密码!

    偶尔把密码忘记了也不用慌,重置密码只需简单几步: 第1步:开机后在内核上敲击“e”. 第2步:在linux16这行的后面输入“rd.break”并敲击“ctrl+x“. 第3步:进入到了系统的紧急求援 ...

  7. systemd 服务管理编写

    1.编辑服务管理脚本 $ cat /lib/systemd/system/kafka.service [Unit] Description=Kafka Server Documentation=htt ...

  8. 【R语言学习笔记】 Day1 CART 逻辑回归、分类树以及随机森林的应用及对比

    1. 目的:根据人口普查数据来预测收入(预测每个个体年收入是否超过$50,000) 2. 数据来源:1994年美国人口普查数据,数据中共含31978个观测值,每个观测值代表一个个体 3. 变量介绍: ...

  9. leetcode算法笔记:二叉树,动态规划和回溯法

    在二叉树中增加一行 题目描述 给定一个二叉树,根节点为第1层,深度为 1.在其第 d 层追加一行值为 v 的节点. 添加规则:给定一个深度值 d (正整数),针对深度为 d-1 层的每一非空节点 N, ...

  10. Matlab 文件格式化/Matlab Source File Formator

    由于需要使用到别人编写的Matlab代码文件,但是呢不同的人有不同的风格,有的写得就比较糟糕了. 为了更好地理解代码的内容,一个比较美观的代码会让人身心愉悦. 但是在网上并没有找到一个比较好的实现,此 ...