Hadoop整体框架

大数据框架

目录

大数据框架

一、Hodoop

四大组件：HDFS/MapReduce/YARN/Common

二、Zookeeper

三、Hive

四、Spark

五、ETL

六、ngnix

七、Redis

八、Oracle

十一、Jsp/node.js/JQueryEcharts

---

一、hadoop

http://blog.csdn.net/huanglong8/article/details/63695488

视频教学来源： 
http://www.imooc.com/learn/391

hadoop 的四大组件：
HDFS：分布式存储系统
MapReduce：分布式计算系统
YARN： hadoop 的资源调度系统
Common： 以上三大组件的底层支撑组件，主要提供基础工具包和 RPC 框架等

1. Hadoop的核心-HDFS简介（Hadoop分布式文件系统HDFS）

HDFS的文件都被分块存储，并且是固定比例的。默认大小是64MB。块是作为处理的逻辑单元。

有两个节点概念： 
1. NameNode是管理节点，存放文件元数据 
主要包括 文件和数据块的映射表，数据块与数据节点的映射表。 
2. DataNode是工作节点，存放的是真正的数据块。 

基本可以理解为，当有 一个 大小为 1GB的文件 进行存储时，HD会将其划分为 64MB * 16 。也就是 会将这个文件拆成 16个块，将每块分别存储到指定位置，通过映射表来进行管理。

快速存放，副本三份。容错处理。

存放三份，基本上遵照 2份在同一机架上，另外一份在另外一个机架上。这样可以快速的进行备份补位。当一个节点出现故障时，可以从另外一个节点拿数据。这也就是说，为什么要用64MB的大小来存储，为了快速。

那么这里会有一个心跳检测 

心跳很好理解，就是实时的去检查管理当前所有节点的状态。

在NameNode的右边是 Secondary NameNode，可以理解为NameNode的备份，当此部分发生故障时，这个二级名字节点就会转正，替代保证整个分布式系统循环可用。这个二级节点也定期会做一些同步或修改等操作。

Hadoop的读文件流程 

客户端请求NameNode，NameNode会返回元数据，元数据内容主要包括哪些数据块，这些数据块都存放在哪些节点上。 
客户端收到NameNode后，去这些节点取数据块，然后拼接起来。

过程描述：

　　（1）客户端调用FileSyste对象的open()方法在分布式文件系统中打开要读取的文件。

　　（2）分布式文件系统通过使用RPC（远程过程调用）来调用namenode，确定文件起始块的位置。

　　（3）分布式文件系统的DistributedFileSystem类返回一个支持文件定位的输入流FSDataInputStream对象，FSDataInputStream对象接着封装DFSInputStream对象（存储着文件起始几个块的datanode地址），客户端对这个输入流调用read()方法。

　　（4）DFSInputStream连接距离最近的datanode，通过反复调用read方法，将数据从datanode传输到客户端。

　　（5） 到达块的末端时，DFSInputStream关闭与该datanode的连接，寻找下一个块的最佳datanode。

　　（6）客户端完成读取，对FSDataInputStream调用close()方法关闭连接。

 

Hadoop写文件流程 

客户端先将文件拆分成ABC。。。等几组数据块，然后请求NameNode存储功能，NameNode寻找可存放的区域并返回给客户端。 
客户端按照NameNode返回的数据区域进行存储，先存A，存完A，系统进行流水线复制，备份其副本到其他区域上，最后发送请求给NameNode，对元数据进行更新，保证映射表都是最新的。 
A的过程整个存完，客户端才会继续寸B，依次类推。

写文件过程分析：

　　（1） 客户端通过对DistributedFileSystem对象调用create()函数来新建文件。

　　（2） 分布式文件系统对namenod创建一个RPC调用，在文件系统的命名空间中新建一个文件。

　　（3）Namenode对新建文件进行检查无误后，分布式文件系统返回给客户端一个FSDataOutputStream对象，FSDataOutputStream对象封装一个DFSoutPutstream对象，负责处理namenode和datanode之间的通信，客户端开始写入数据。

　　（4）FSDataOutputStream将数据分成一个一个的数据包，写入内部队列“数据队列”，DataStreamer负责将数据包依次流式传输到由一组namenode构成的管线中。

　　（5）DFSOutputStream维护着确认队列来等待datanode收到确认回执，收到管道中所有datanode确认后，数据包从确认队列删除。

　　（6）客户端完成数据的写入，对数据流调用close()方法。

　　（7）namenode确认完成。

HDFS的特点 
1. 数据冗余，硬件容错。 
2. 流式的数据访问 
3. 存储大文件

适用性和局限性 
适合数据批量读写，吞吐量高 
不适合交互式应用，低延迟很难满足 
适合一次写入多次读取，顺序读写 
不支持多用户并发写相同文件

HDFS命令行操作演示 
hadoop fs -ls / 
打印读写文件夹

hadoop fs -put [file] input/ 
将file放到input/这个目录下

hadoop fs -mkdir input 
建立一个input目录

hadoop fs -cat input/[file] 
查看文件

hadoop fs -get input/[file] [newfile] 
下载文件

hadoop dfsadmin -report 
打印hadoop使用状态和信息

2. Hadoop核心—MapReduce（分布式计算系统）

MapReduce的原理 

Mapreduce 是一个分布式运算程序的编程框架，是用户开发“基于 hadoop 的数据分析 应用”的核心框架；
Mapreduce 核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的 分布式运算程序，并发运行在一个 hadoop 集群上。

    为什么需要 MapReduce？
     (1) 海量数据在单机上处理因为硬件资源限制，无法胜任；
     (2) 而一旦将单机版程序扩展到集群来分布式运行，将极大增加程序的复杂度和开发难度；
     (3) 引入 MapReduce 框架后，开发人员可以将绝大部分工作集中在业务逻辑的开发上，而将 分布式计算中的复杂性交由框架来处理。

分而治之，就是将一个大任务拆分成多个小任务，小任务执行完后，合并整个结果。

 

MapReduce的运行流程

1. Job & Task 
   1个Job分成多个Task 
   

2. JobTracker的角色 
   作业调度，分配任务、监控任务执行进度，监控TaskTracker的状态。

3. TaskTracker的角色 
   执行任务，汇报任务状态

MapReduce的容错机制 
1. 任务出错话，尝试重复执行。如果重复4次都失败，则放弃。 
2. 推测执行，如果某一个TaskTracker计算过程中很慢或者有异于其他Task的状态时，系统会重新启动一个TaskTracker做同样的事情，如果OK了，则保证整个系统不会因为一个Task的异常而导致整个系统性能的下降或错误。

mapreduce的核心程序运行机制

     1、概述

一个完整的 mapreduce 程序在分布式运行时有两类实例进程：
 (1) MRAppMaster：负责整个程序的过程调度及状态协调  (该进程在yarn节点上)
 (2) Yarnchild：负责 map 阶段的整个数据处理流程         
 (3) Yarnchild：负责 reduce 阶段的整个数据处理流程
以上两个阶段 maptask 和 reducetask 的进程都是 yarnchild，并不是说这 maptask 和 reducetask 就跑在同一个 yarnchild 进行里
（Yarnchild进程在运行该命令的节点上）

      2、mapreduce程序的运行流程（经典面试题）

（1） 一个 mr 程序启动的时候，最先启动的是 MRAppMaster， MRAppMaster 启动后根据本次 job 的描述信息，计算出需要的 maptask 实例数量，然后向集群申请机器启动相应数量的 maptask 进程
（2） maptask 进程启动之后，根据给定的数据切片(哪个文件的哪个偏移量范围)范围进行数 据处理，主体流程为：
    A、 利用客户指定的 inputformat 来获取 RecordReader 读取数据，形成输入 KV 对
    B、 将输入 KV 对传递给客户定义的 map()方法，做逻辑运算，并将 map()方法输出的 KV 对收 集到缓存
    C、 将缓存中的 KV 对按照 K 分区排序后不断溢写到磁盘文件 （超过缓存内存写到磁盘临时文件，最后都写到该文件，ruduce 获取该文件后，删除 ）
（3） MRAppMaster 监控到所有 maptask 进程任务完成之后（真实情况是，某些 maptask 进 程处理完成后，就会开始启动 reducetask 去已完成的 maptask 处 fetch 数据），会根据客户指 定的参数启动相应数量的 reducetask 进程，并告知 reducetask 进程要处理的数据范围（数据
分区）
（4） Reducetask 进程启动之后，根据 MRAppMaster 告知的待处理数据所在位置，从若干台 maptask 运行所在机器上获取到若干个 maptask 输出结果文件，并在本地进行重新归并排序， 然后按照相同 key 的 KV 为一个组，调用客户定义的 reduce()方法进行逻辑运算，并收集运
算输出的结果 KV，然后调用客户指定的 outputformat 将结果数据输出到外部存储

      3、maptask并行度决定机制

maptask 的并行度决定 map 阶段的任务处理并发度，进而影响到整个 job 的处理速度 那么， mapTask 并行实例是否越多越好呢？其并行度又是如何决定呢？

一个 job 的 map 阶段并行度由客户端在提交 job 时决定， 客户端对 map 阶段并行度的规划
的基本逻辑为：
将待处理数据执行逻辑切片（即按照一个特定切片大小，将待处理数据划分成逻辑上的多 个 split），然后每一个 split 分配一个 mapTask 并行实例处理
这段逻辑及形成的切片规划描述文件，是由 FileInputFormat实现类的 getSplits()方法完成的。
该方法返回的是 List<InputSplit>， InputSplit 封装了每一个逻辑切片的信息，包括长度和位置  信息，而 getSplits()方法返回一组 InputSplit

       4、切片机制

三、 hadoop 的资源调度系统——YARN

1.Yarn产生的背景

hadoop1.0不能满足多系统集成的背景孕育了yarn的产生。由于多分布式系统可以很好的集成，因此yarn的出现使得整个集群的运维成本大大降低。同时，yarn可以很好的利用集群资源，避免资源的浪费，除此之外，yarn的出现实现了集群的数据共享问题，不同的分布式计算框架可以实现数据的共享。总结来说为以下两点：

• 直接源于MR在几个方面的缺陷 
  -扩展性受限 
  -单点故障 
  -难以支持MR之外的计算

• 多计算框架各自为战，数据共享困难 
  -MR:离线计算框架 
  -Storm:实时计算框架 
  -Spark:内存计算框架

2.Yarn的基本构成

我们通过Yarn的工作流程图来了解Yarn的组织架构，如下图： 
 
（1）Client向ResourceManager发送请求 
（2）ResourceManager指定一个NodeManager启动起ApplicationMaster 
（3）ApplicationMaster将计算任务反馈给ResourceManager 
（4）ApplicationMaster将任务分割分发到不同的NodeManager 
（5）NodeManager启动Task执行work 
接着需要了解的是Yarn的每个节点的详细功能：

• ResourceManager 
  整个集群中只有一个，负责集群资源的统一管理和调度 
  详细功能： 
  -处理客户端请求 
  -启动/监控ApplicationMaster 
  -监控NodeManager 
  -资源分配与调度

• NodeManager 
  整个集群有多个，负责单节点资源管理和使用 
  详细功能： 
  -单个节点上的资源管理和任务管理 
  -处理来自ResourceManager的命令 
  -处理来自ApplicationMaster的命令

• ApplicationMaster 
  每个应用只有一个，负责应用程序的管理 
  详细功能： 
  -数据切分 
  -为应用程序申请资源，并进一步分配给内部任务 
  -任务监控与容错

• Container 
  对任务运行环境的抽象 
  详细信息： 
  -任务运行资源（节点，内存，CPU） 
  -任务启动命令 
  -任务运行环境

下面给出Yarn的运行剖析图： 

• Yarn具有双层调度策略 
  ResourceManager将资源分配给ApplicationMaster,ApplicationMaster再将资源分配给NodeManager。此外，Yarn具有预留的调度策略，资源不够时，会为Task预留资源直到资源积累充足。

• Yarn具有较好的容错机制 
  当任务失败时，ResourceManager将失败任务告诉ApplicationMaster。由ApplicationMaster处理失败任务，ApplicationMaster会保存已经执行的Task,重启不会重新执行。

• Yarn支持内存和CPU两种资源隔离。 
  内存是一种决定生死的资源，CPU是一种影响快慢的资源，其中，内存隔离包括基于线程监控的方案和基于Cgroups的方案，而CPU隔离包括默认不对CPU资源进行隔离和基于Cgroups的方案。

• Yarn支持的调度语义 
  yarn支持的语义有请求某个特定节点/机架上的特定资源量和将某些节点加入（或移除）黑名单，不再为自己分配这些节点上的资源，请求归还某些资源。 
  Yarn不支持的语义有请求任意节点/机架上的特定资源量；请求一组或几组符合某种特质的资源；超细粒度资源；动态调整Container资源。

3.

YARN基本组成结构

YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。在本小节中，我们将对YARN的基本组成结构进行介绍。

图2-9描述了YARN的基本组成结构，YARN主要由ResourceManager、NodeManager、ApplicationMaster（图中给出了MapReduce和MPI两种计算框架的ApplicationMaster，分别为MR AppMstr和MPI AppMstr）和Container等几个组件构成。

 

 

1.ResourceManager（RM）

RM是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）。

（1）调度器

调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。

需要注意的是，该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。

 

（2） 应用程序管理器

应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

 

2. ApplicationMaster（AM）

用户提交的每个应用程序均包含1个AM，主要功能包括：

与RM调度器协商以获取资源（用Container表示）；

将得到的任务进一步分配给内部的任务；

与NM通信以启动/停止任务；

监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

当前YARN自带了两个AM实现，一个是用于演示AM编写方法的实例程序distributedshell，它可以申请一定数目的Container以并行运行一个Shell命令或者Shell脚本；另一个是运行MapReduce应用程序的AM—MRAppMaster，我们将在第8章对其进行介绍。此外，一些其他的计算框架对应的AM正在开发中，比如Open MPI、Spark等。

3. NodeManager（NM）

NM是每个节点上的资源和任务管理器，一方面，它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自AM的Container启动/停止等各种请求。

4. Container

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。

需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。截至本书完成时，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups进行资源隔离。

 

1.3  YARN工作流程

当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：

第一个阶段是启动ApplicationMaster；

第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。

如图2-11所示，YARN的工作流程分为以下几个步骤：

     

 

步骤1　用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

步骤2　ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。

步骤3　ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。

步骤4　ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

步骤5　一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。

步骤6　NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。

步骤7　各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。

     在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

 

步骤8　应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

 

1.4 多角度理解YARN

可将YARN看做一个云操作系统，它负责为应用程序启动ApplicationMaster（相当于主线程），然后再由ApplicationMaster负责数据切分、任务分配、启动和监控等工作，而由ApplicationMaster启动的各个Task（相当于子线程）仅负责自己的计算任务。当所有任务计算完成后，ApplicationMaster认为应用程序运行完成，然后退出。

   

二、Zookeeper

1.ZooKeeper是什么？
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户

2.ZooKeeper提供了什么？

1)文件系统

2)通知机制

3.Zookeeper文件系统

每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。 

有四种类型的znode： 

1、PERSISTENT-持久化目录节点 

客户端与zookeeper断开连接后，该节点依旧存在 

2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 

3、EPHEMERAL-临时目录节点 

客户端与zookeeper断开连接后，该节点被删除 

4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 

<ignore_js_op> 

4.Zookeeper通知机制

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

5.Zookeeper做了什么？

1.命名服务   2.配置管理   3.集群管理   4.分布式锁  5.队列管理

6.Zookeeper命名服务

在zookeeper的文件系统里创建一个目录，即有唯一的path。在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path，通过path即能互相探索发现。

7.Zookeeper的配置管理

程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好

<ignore_js_op> 

8.Zookeeper集群管理

所谓集群管理无在乎两点：是否有机器退出和加入、选举master。 

对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。

新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了，对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。

<ignore_js_op> 

9.Zookeeper分布式锁

有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。 

对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。 

对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。

<ignore_js_op> 

10.Zookeeper队列管理

两种类型的队列：

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

2、队列按照 FIFO 方式进行入队和出队操作。 

第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。 

第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。

11.分布式与数据复制 

Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处： 

1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作； 

2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力； 

3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。 

从客户端读写访问的透明度来看，数据复制集群系统分下面两种： 

1、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离； 

2、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。

对zookeeper来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立observer的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。

12.Zookeeper角色描述

<ignore_js_op> 

13.Zookeeper与客户端

<ignore_js_op> 

14.Zookeeper设计目的

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

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

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

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

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

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

15.Zookeeper工作原理

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

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

16.Zookeeper 下 Server工作状态

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

LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步

17.Zookeeper选主流程(basic paxos)

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

1.选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server； 

2.选举线程首先向所有Server发起一次询问(包括自己)； 

3.选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中； 

4.收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server； 

5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。 通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图所示： 

<ignore_js_op> 

18.Zookeeper选主流程（fast paxos）

fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。

<ignore_js_op>