节点总结

*QuorumPeerMain

**是zookeeper集群的启动入口类，是用来加载配置启动QuorumPeer线程的。

QuorumPeer， 谷歌翻译quorum是法定人数，定额的意思， peer是对等的意思，那么QuorumPeer中quorum代表的意思就是每个zookeeper集群启动的时候集群中zookeeper服务数量就已经确定了，zookeeper是基于paxos算法实现的，那是一个唯一的分布式集群一致性算法，在zookeeper中将这一算法演绎为集群分布式协调可持续服务。在每个zookeeper的配置文件中配置集群中的所有机器

server.1=127.0.0.1:2888:3888

server.2=127.0.0.1:2888:3888

server.3=127.0.0.1:2888:3888

配置中每个server.X记录代表集群中的一个服务，QuorumPeerConfig会构建一个QuorumServer对象，其中的server.X中的X代表zookpeer的sid，每个zookeeper都会编辑自己的sid在dataDir目下的myid文件中，sid标记每个服务，在快速选举中起作用。

所以对这个进程不应该陌生，如果你要关闭，就直接zkServer.sh stop 就可以了。

JournalNode

是在MR2也就是Yarn中新加的,journalNode的作用是存放EditLog的,

在MR1中editlog是和fsimage存放在一起的然后SecondNamenode做定期合并,Yarn在这上面就不用SecondNamanode了.

Active Namenode与StandBy Namenode之间的就是JournalNode,作用相当于NFS共享文件系统.Active Namenode往里写editlog数据,StandBy再从里面读取数据进行同步.
2.作用
两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。

standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了。

3.资源配置
NameNode服务器：运行NameNode的服务器应该有相同的硬件配置。

• JournalNode服务器：运行的JournalNode进程非常轻量，可以部署在其他的服务器上。注意：必须允许至少3个节点。当然可以运行更多，但是必须是奇数个，如3、5、7、9个等等。

当运行N个节点时，系统可以容忍至少(N-1)/2(N至少为3)个节点失败而不影响正常运行。
在一个典型的HA集群中，每个NameNode是一台独立的服务器。在任一时刻，只有一个NameNode处于active状态，另一个处于standby状态。其中，active状态的NameNode负责所有的客户端操作，standby状态的NameNode处于从属地位，维护着数据状态，随时准备切换。

两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了，如图3所示。
为了确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。

对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。否则，两个NameNode的数据状态就会产生分歧，可能丢失数据，或者产生错误的结果。为了保证这点，JNs必须确保同一时刻只有一个NameNode可以向自己写数据。

ZKFC 详解

链接：[https://blog.csdn.net/wz_TXWY/article/details/99888654?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param]

zkfc是什么？ZooKeeperFailoverController
它是什么？是Hadoop中通过ZK实现FC功能的一个实用工具。
主要作用：作为一个ZK集群的客户端，用来监控NN的状态信息,主备NN的切换
谁会用它？每个运行NN的节点必须要运行一个zkfc

有啥功能？
1.Health monitoring (健康监测) 对NN的健康监测
zkfc定期对本地的NN发起health-check的命令，如果NN正确返回，那么这个NN被认为是OK的。否则被认为是失效节点。

2.ZooKeeper Session Management ( 作为一个ZK集群的客户端, 管理与zk的会话 )
当本地NN是健康的时候，zkfc将会在zk中持有一个session。如果本地NN又正好是active的，那么zkfc还有持有一个”ephemeral”的节点作为锁，一旦本地NN失效了，那么这个节点将会被自动删除。

3.ZooKeeper-based election ( 主备NN选举, 主备NN的切换)
如果本地NN是健康的，并且zkfc发现没有其他的NN持有那个独占锁。那么他将试图去获取该锁，一旦成功，那么它就需要执行故障转移(Failover)，然后成为active的NN节点。Failover的过程是：第一步，对之前的NN执行fence，如果需要的话。第二步，将本地NN转换到active状态。
另外：
如果一个Active因HealthMonitor监控到状态异常，这里会作出判断，先通过隔离(Fencing)功能关闭它（确保关闭或者不能提供服务），然后在ZK上删除它对应ZNode。
发生上述事件后，在另外一台机器上的ZKFC中的ActiveStandbyElector 会收到事件，并重新进行选举（尝试创建特定ZNode），它将获得成功并更改NN中状态，从而实现Active节点的变更

(一) 基本原理
zk(zookeeper)的基本特性：
(1) 可靠存储小量数据且提供强一致性
(2) ephemeral node（创建的锁节点）, 在创建它的客户端关闭后，可以自动删除
(3) 对于node状态的变化，可以提供异步的通知(watcher)

zk在zkfc中可以提供的功能：
(1) Failure detector（通过watcher监听机制实现）: 及时发现出故障的NN，并通知zkfc
(2) Active node locator: 帮助客户端定位哪个是Active的NN
(3) Mutual exclusion of active state（通过加锁）: 保证某一时刻只有一个Active的NN
(二) 模块
(1) ZKFailoverController(DFSZKFailoverController): 驱动整个ZKFC的运转，通过向HealthMonitor和ActiveStandbyElector注册回调函数的方式，subscribe HealthMonitor和ActiveStandbyElector的事件，并做相应的处理

(2) HealthMonitor: 定期check NN的健康状况，在NN健康状况发生变化时，通过回调函数把变化通知给ZKFailoverController

(3) ActiveStandbyElector: 管理NN在zookeeper上的状态，调用zookeeper客户端API监控zookeeper上结点的状态,zookeeper上对应node的结点发生变化时，通过回调函数把变化通知给ZKFailoverController

(4) FailoverController: 提供做graceful failover的相关功能(dfs admin可以通过命令行工具手工发起failover)

(三) 线程模型
ZKFC的线程模型主要包括三类线程，
一是 主线程
二是 HealthMonitor线程
三是 zookeeper客户端的线

它们的主要工作方式是

(1)主线程在启动所有的服务后就开始循环等待

(2) HealthMonitor是一个单独的线程，它定期向NN发包，检查NN的健康状况
当NN的状态发生变化时，HealthMonitor线程会回调ZKFailoverController注册进来的回调函数，通知ZKFailoverController NN的状态发生了变化
ZKFailoverController收到通知后，会调用ActiveStandbyElector的API，来管理在zookeeper上的结点的状态

(3) ActiveStandbyElector会调用zookeeper客户端API监控zookeeper上结点的状态，发生变化时，回调ZKFailoverController的回调函数，
通知ZKFailoverController，做出相应的变化
(四) 自动触发主备选举
NameNode 在选举成功后，ActiveStandbyElector会在 zk 上创建了一个/hadoopha/${dfs.nameservices}/ActiveStandbyElectorLock 临时节点，而没有选举成功的备 NameNode 中的 ActiveStandbyElector会监控这个节点，通过 Watcher 来监听这个节点的状态变化事件，ZKFC 的 ActiveStandbyElector 主要关注这个节点的 NodeDeleted 事件（这部分实现跟 Kafka 中 Controller 的选举一样）。

如果 Active NameNode 对应的 HealthMonitor 检测到 NameNode 的状态异常时， ZKFailoverController 会主动删除当前在 Zookeeper 上建立的临时节点 /hadoop-ha/{dfs.nameservices}/ActiveStandbyElectorLock，这样处于 Standby 状态的 NameNode 的 ActiveStandbyElector 注册的监听器就会收到这个节点的 NodeDeleted 事件。收到这个事件之后，会马上再次进入到创建 /hadoop-ha/{dfs.nameservices}/ActiveStandbyElectorLock 临时节点的流程，如果创建成功，这个本来处于 Standby 状态的 NameNode 就选举为主 NameNode 并随后开始切换为 Active 状态。

当然，如果是 Active 状态的 NameNode 所在的机器整个宕掉的话，那么跟zookeeper连接的客户端线程也挂了,会话结束,那么根据 Zookeepe的临时节点特性，/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换

(五) HDFS 脑裂问题
在实际中，NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整个系统无响应，因此，zkfc客户端也就无法向 zk 写入心跳信息，这样的话可能会导致临时节点掉线，备 NameNode 会切换到 Active 状态，这种情况，可能会导致整个集群会有同时有两个 NameNode，这就是脑裂问题。

脑裂问题的解决方案是隔离（Fencing），主要是在以下三处采用隔离措施：

1.第三方共享存储：任一时刻，只有一个 NN 可以写入；
2.DataNode：需要保证只有一个 NN 发出与管理数据副本有关的删除命令；
3.Client需要保证同一时刻只有一个 NN 能够对 Client 的请求发出正确的应。

解决方案的实现如下：(在NN上下手)
ActiveStandbyElector 为了实现 fencing，会在成功创建 Zookeeper 临时节点 hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock成为ActiveNameNode之后，创建另外一个路径为hadoop−ha/dfs.nameservices/ActiveStandbyElectorLock成为ActiveNameNode之后，创建另外一个路径为hadoop−ha/{dfs.nameservices}/ActiveBreadCrumb 的持久节点，这个节点里面保存了这个 Active NameNode 的地址信息；

Active NameNode 的 ActiveStandbyElector 在正常的状态下关闭 Zookeeper Session 的时候，会一起删除这个持久节点

但如果 ActiveStandbyElector 在异常的状态下 Zookeeper Session 关闭 (比如前述的 Zookeeper 假死)，那么由于 /hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb 是持久节点，会一直保留下来，后面当另一个 NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留下来的这个节点，从而会回调 ZKFailoverController 的方法对旧的 Active NameNode 进行 fencing。

在进行 隔离(fencing )的时候，会执行以下的操作：
首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态；

如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施。

Hadoop 目前主要提供两种隔离措施，通常会选择第一种：

1. sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死；
2. shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离。

只有在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调 ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始对外提供服务。

DataNode nameNode SecondaryNameNode

以下来源于这超链接内容

NameNode：是Master节点，有点类似Linux里的根目录。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；

SecondaryNameNode：保存着NameNode的部分信息（不是全部信息NameNode宕掉之后恢复数据用），是NameNode的冷备份；合并fsimage和edits然后再发给namenode。（防止edits过大的一种解决方案）

DataNode：负责存储client发来的数据块block；执行数据块的读写操作。是NameNode的小弟。

热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。

冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。

fsimage:元数据镜像文件（文件系统的目录树。）

edits：元数据的操作日志（针对文件系统做的修改操作记录）

namenode内存中存储的是=fsimage+edits。
NameNode详解

作用：

Namenode起一个统领的作用，用户通过namenode来实现对其他数据的访问和操作，类似于root根目录的感觉。

Namenode包含：目录与数据块之间的关系（靠fsimage和edits来实现），数据块和节点之间的关系

fsimage文件与edits文件是Namenode结点上的核心文件。

Namenode中仅仅存储目录树信息，而关于BLOCK的位置信息则是从各个Datanode上传到Namenode上的。

Namenode的目录树信息就是物理的存储在fsimage这个文件中的，当Namenode启动的时候会首先读取fsimage这个文件，将目录树信息装载到内存中。

而edits存储的是日志信息，在Namenode启动后所有对目录结构的增加，删除，修改等操作都会记录到edits文件中，并不会同步的记录在fsimage中。

而当Namenode结点关闭的时候，也不会将fsimage与edits文件进行合并，这个合并的过程实际上是发生在Namenode启动的过程中。

也就是说，当Namenode启动的时候，首先装载fsimage文件，然后在应用edits文件，最后还会将最新的目录树信息更新到新的fsimage文件中，然后启用新的edits文件。

整个流程是没有问题的，但是有个小瑕疵，就是如果Namenode在启动后发生的改变过多，会导致edits文件变得非常大，大得程度与Namenode的更新频率有关系。

那么在下一次Namenode启动的过程中，读取了fsimage文件后，会应用这个无比大的edits文件，导致启动时间变长，并且不可控，可能需要启动几个小时也说不定。

Namenode的edits文件过大的问题，也就是SecondeNamenode要解决的主要问题。

SecondNamenode会按照一定规则被唤醒，然后进行fsimage文件与edits文件的合并，防止edits文件过大，导致Namenode启动时间过长。

DataNode详解

DataNode在HDFS中真正存储数据。

首先解释块（block）的概念：

DataNode在存储数据的时候是按照block为单位读写数据的。block是hdfs读写数据的基本单位。
假设文件大小是100GB，从字节位置0开始，每128MB字节划分为一个block，依此类推，可以划分出很多的block。每个block就是128MB大小。
block本质上是一个 逻辑概念，意味着block里面不会真正的存储数据，只是划分文件的。
block里也会存副本，副本优点是安全，缺点是占空间
SecondaryNode

执行过程：从NameNode上 下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，同时重置NameNode的edits.

工作原理（转自“大牛笔记”的博客，由于实现是清晰，受益很大，在此不做改动）

写操作：

有一个文件FileA，100M大小。Client将FileA写入到HDFS上。

HDFS按默认配置。

HDFS分布在三个机架上Rack1，Rack2，Rack3。

a. Client将FileA按64M分块。分成两块，block1和Block2;

b. Client向nameNode发送写数据请求，如图蓝色虚线①------>。

c. NameNode节点，记录block信息。并返回可用的DataNode，如粉色虚线②--------->。

Block1: host2,host1,host3

Block2: host7,host8,host4

原理：

    NameNode具有RackAware机架感知功能，这个可以配置。

    若client为DataNode节点，那存储block时，规则为：副本1，同client的节点上；副本2，不同机架节点上；副本3，同第二个副本机架的另一个节点上；其他副本随机挑选。

    若client不为DataNode节点，那存储block时，规则为：副本1，随机选择一个节点上；副本2，不同副本1，机架上；副本3，同副本2相同的另一个节点上；其他副本随机挑选。

d. client向DataNode发送block1；发送过程是以流式写入。

流式写入过程，

    1>将64M的block1按64k的package划分;

    2>然后将第一个package发送给host2;

    3>host2接收完后，将第一个package发送给host1，同时client想host2发送第二个package；

    4>host1接收完第一个package后，发送给host3，同时接收host2发来的第二个package。

    5>以此类推，如图红线实线所示，直到将block1发送完毕。

    6>host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示。

    7>client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线

    8>发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示。

    9>发送完block2后，host7,host8,host4向NameNode，host7向Client发送通知，如图浅绿色实线所示。

    10>client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了。

分析，通过写过程，我们可以了解到：

①写1T文件，我们需要3T的存储，3T的网络流量贷款。

②在执行读或写的过程中，NameNode和DataNode通过HeartBeat进行保存通信，确定DataNode活着。如果发现DataNode死掉了，就将死掉的DataNode上的数据，放到其他节点去。读取时，要读其他节点去。

③挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份。

读操作：

读操作就简单一些了，如图所示，client要从datanode上，读取FileA。而FileA由block1和block2组成。

那么，读操作流程为：

a. client向namenode发送读请求。

b. namenode查看Metadata信息，返回fileA的block的位置。

block1:host2,host1,host3

block2:host7,host8,host4

c. block的位置是有先后顺序的，先读block1，再读block2。而且block1去host2上读取；然后block2，去host7上读取；

上面例子中，client位于机架外，那么如果client位于机架内某个DataNode上，例如,client是host6。那么读取的时候，遵循的规律是：

优选读取本机架上的数据。

运算和存储在同一个服务器中，每一个服务器都可以是本地服务器

补充

元数据

元数据被定义为：描述数据的数据，对数据及信息资源的描述性信息。（类似于Linux中的i节点）

以 “blk_”开头的文件就是 存储数据的block。这里的命名是有规律的，除了block文件外，还有后 缀是“meta”的文件 ，这是block的源数据文件，存放一些元数据信息。

数据复制

NameNode做出关于块复制的所有决定。它周期性地从集群中的每个DataNode接收到一个心跳和一个阻塞报告。收到心跳意味着DataNode正常运行。Blockreport包含DataNode上所有块的列表。

NodeManager

NodeManager作为资源管理系统YARN的一个重要服务，它的主要功能包括节点健康状况检测、分布式缓存机制、目录结构管理、状态机管理、Container生命周期、资源隔离机制等机制。NM管理的是Container而不是任务，一个Container中可能运行着各种任务，但是对NM而言是透明的，它只负责Container相关操作，比如管理Container的生命周期，即启动Container、监控Container和清理Container等。
NodeManager管理一个YARN集群中的每一个节点。比如监视资源使用情况（ CPU，内存，硬盘，网络），跟踪节点健康等。

ApplicationMaster

想了解ApplicationMaster，我们需要了解一下它工作的过程。用户向YARN集群提交应用程序时：（包含ApplicationMaster程序，ApplicationMaster启动命令，用户自己的程序）后， ApplicationMaster向资源调度器申请执行任务的资源容器Container，运行用户自己的程序任务job（我们可以用浏览器看yarn 里的job进展），监控整个任务的执行，跟踪整个任务的状态，处理任务失败以异常情况