一、Hadoop-HDFS-Ha模式是什么？

部分转载 ：https://blog.csdn.net/qq_37163925/article/details/105584223

hadoop分布式文件系统的高可用模式。H-high a-avaliable,是为了解决单台NameNode所带来的单点故障问题而提出的机制。2.0支持一主一备，3.0最多支持一主五备。

二、为什么要存在Ha模式

单点模式的优缺点

优点：

• 主从集群（一台nameNode 、多台dataNode），结构简单，主从写作。
• 不存在数据一致性问题。

缺点：

• 单点故障，nameNode有问题，服务不可用。
• 压力过大，因为nameNode是基于内存，内存受限。

解决方式：

• 单点故障：高可用方案。多个nameNode。主备切换。Ha模式。
• 压力过大：联邦机制：Federation(元数据分片) 多个NN,管理不同的元数据。

ha 模式就是为了解决单点故障，提供高可用的服务的解决方案。

三 HDFS-HA

1.解决单点故障。

• 为解决nameNode单点故障，我们将nameNode添加到多台，形成一主多备的形态(多主会出现脑裂的现象)。
• 此时会出现两种nameNode，一种是提供服务的activeNameNode，有且只有一台可以。一种是standeByNameNode。它不会和clint交互。
• 当activeNameNode出现问题时，需要将原来的ActiveNN下线，并将standBy切换成activeNameNode。
• 此时出现一个问题，如何保证新的activeNN的元数据是最新的。

2.解决多台NN的数据同步问题

为保证系统的可用性。提供两种实现可能

1.同步阻塞式的

当client与activeNN交互时，active验证完毕并创建文件的元数据，此时阻塞时的同步standByNN，等standByNN返回创建成功时，activeNN返回client,但是网络是不可信的，等待standByNN返回ok情况太多了，这就导致了为了保证强一致性破坏了可用性。

2.异步非阻塞式

找到一种相对可靠的中间件，activeNN创建完元数据后，向中间件写入消息，之后standByNN读取消息写入自己的内存，此时两个NN的数据保持一致。中间件需要既可靠又高可用，此时HDFS提供了了解决方案。JNN。

3.Journal Node

HDFS-HA引入了Journal Node(>3台)来作为消息中间件，Journal Node是一个有主从机制的消息中间件，一开始是无主状态，在JournalNode启动时会选举出主JournalNode，选举策略默认是选举ID最大的JournalNode作为主节点。NameNode与主JournalNode通信，将请求写入JournalNode，然后由主JournalNode将请求更新到其他节点，为保证更新的请求为最新，JournalNode采用了Paxos算法(与Zookeeper类似)，简单来说，就是当集群中超过一半的节点都更新完这条请求，就认为这条请求写入成功。这样就保证了Standby NameNode访问JournalNode时，可以访问到最新的元数据并进行同步

使用ZKFC实现自动切换Active NameNode

上面的方法基本解决了数据一致性的问题，但是需要手动去切换NameNode，所以HDFS-HA引入了ZKFC来实现自动切换Active NameNode。在Active NameNode和Standby NameNode所在的物理机中，都会有一个叫FailoverController的进程，那么它是如何实现Active NameNode的切换的呢？
ps:为什么要把FailoverController和NameNode放到一台物理机上呢？因为如果放到不同的物理机，那么它们沟通就需要通过网络传输来进行，就会产生很多的不可靠性，加大了监控的风险。

ZKFC的功能

监控NameNode:监控NameNode的存活状态、操作系统和硬件信息。
连接Zookeeper并创建Active NameNode：Zookeeper中有目录树，当所有NameNode 和 ZKFC启动时，ZKFC首先向Zookeeper申请一个创建锁，谁拿到了创建锁，谁就能创建一个临时子节点，这意味着2个ZKFC只有一个能创建子节点，这个被ZKFC创建成功的子节点中包含的就是Active NameNode。
降级Active NameNode，升级Standby NameNode：假设Active NameNode存活但是ZKFC进程异常退出，这时候就会触发此机制，Zookeeper的临时子节点会被删除，然后触发callback机制，第二个ZKFC就会抢到创建锁，并自己将Active NameNode降级成Standby NameNode，升级Standby NameNode为Active NameNode。

Active NameNode切换过程

首先，ZKFC在Zookeeper中创建的节点是一个临时节点，当ZKFC和Zookeeper保持连接时，节点会一直存在，一旦连接断开，节点就会被删除，节点删除会触发回调(callback)，当所有NameNode 和 ZKFC启动时，ZKFC首先向Zookeeper申请一个创建锁，谁拿到了创建锁，谁就能创建一个临时子节点，这意味着2个ZKFC只有一个能创建子节点，这个被ZKFC创建成功的子节点中包含的就是Active NameNode。
此时若Active NameNode挂了，这时候第一个ZKFC将Active NameNode降级成Standby NameNode并将Zookeeper的临时子节点删除，然后触发callback机制，第二个ZKFC就会抢到创建锁，并去查看Active NameNode是否真的挂了，如果挂了，就升级Standby NameNode为Active NameNode。
若Active NameNode还存活，但是当前Active NameNode主机的ZKFC挂了，Zookeeper的临时子节点会被删除，然后触发callback机制，第二个ZKFC就会抢到创建锁，并自己将Active NameNode降级成Standby NameNode，升级Standby NameNode为Active NameNode。
极端现象：Active NameNode和ZKFC都没有问题，并且Active NameNode也能和DataNode通信，但是ZKFC和Zookeeper不能通信，且第二个ZKFC也不能访问Active NameNode来判断Active NameNode是否真的挂了，所以也不会把自己监控的NameNode升级为Active NameNode。此时Zookeeper的子节点被删除，又不能创建新节点，导致程序出错。这种情况出现的概率极其低，所以解决办法也较极端，一种办法是遇到此情况时触发一种机制将当前的Active NameNode的电源切断。