深入理解Hadoop集群的高可用性：从原理到架构实践

在分布式存储领域，Hadoop分布式文件系统(HDFS)作为Hadoop生态系统的核心存储组件，其高可用性(HA)设计一直是程序员们关注的焦点。

为什么我们需要高可用？

在Hadoop 2.0之前，HDFS架构中存在一个著名的“单点故障”隐患——NameNode。

NameNode作为HDFS的“大脑”，负责维护文件系统的元数据（目录树、文件块映射等）。在早期架构中，整个集群只有一个NameNode。一旦它因为硬件故障、内存溢出或网络问题宕机，整个HDFS集群将陷入瘫痪，所有数据虽然还在磁盘上，但无法被访问。

对于追求7×24小时不间断服务的企业级应用来说，这是不可接受的。因此，Hadoop高可用架构应运而生。

HDFS高可用的核心架构

Hadoop HA的核心思想非常直观：冗余。既然一个NameNode会挂，那我们就部署两个——一个主用，一个备用。

但在分布式系统中，简单的“主备复制”远比你想象的要复杂。Hadoop HDFS的HA架构主要解决了三个核心难题：元数据同步、故障检测与自动切换、以及最棘手的“脑裂”问题。

1. 双机热备：Active与Standby

在HA架构中，我们部署两个NameNode：

• Active NameNode：负责处理所有客户端的读写请求，是集群的“真命天子”。
• Standby NameNode：处于热备状态，它不处理客户端请求，但它的核心任务是实时同步Active节点的元数据，确保自己随时准备好接管工作。

2. 共享存储：JournalNodes

Standby节点如何知道Active节点做了什么操作？这就引入了JournalNode集群。

当Active NameNode接收到修改元数据的请求（如创建文件）时，它会先将操作日志持久化写入到JournalNode集群中。Standby NameNode则时刻监控着JournalNode，一旦发现有新的日志写入，它就会立即读取并应用到自己的内存文件系统中。

通过这种机制，Standby节点始终与Active节点保持着毫秒级的数据同步。

3. 故障转移的指挥官：ZKFC

谁来监控NameNode是否挂了？谁来执行切换？答案是ZKFC。

ZKFC是一个运行在NameNode所在机器上的进程，它主要干两件事：

• 健康监控：定期向NameNode发送心跳，检查其是否健康。
• 自动故障转移：如果Active NameNode挂了，ZKFC会感知到，并通过ZooKeeper发起选举，将Standby节点提升为Active。

分布式系统的噩梦：脑裂与 fencing

这是面试中最高频的考点，也是理解HA深度的关键。

假设一种极端情况：Active NameNode并没有挂，但是它和ZooKeeper之间的网络断了（网络分区）。此时，ZKFC认为Active挂了，于是触发切换，让Standby变成了新的Active。

现在的局面是：旧的Active认为自己是老大，新的Active也认为自己是老大。如果两者同时向DataNode写入数据，元数据就会彻底混乱。这就是脑裂。

Hadoop通过Fencing机制来解决这个问题。

当发生切换时，新上任的Active NameNode会通过 fencing 机制“干掉”旧节点。常见的手段包括：

• 切断电源：通过IPMI远程管理卡强制关闭旧节点的电源。
• 切断网络：通过防火墙规则隔离旧节点。
• 共享存储锁：利用JournalNode的共享存储锁，拒绝旧节点的写入请求。

只有确保旧节点彻底“闭嘴”，新节点才会开始服务，从而保证了数据的一致性。

此外，不仅仅是HDFS：YARN的HA

除了存储层，计算资源管理层YARN同样存在单点故障——ResourceManager。

YARN的HA原理与HDFS类似，也是采用Active/Standby架构。但它略有不同的是，它通常利用ZooKeeper来维护ResourceManager的状态。当Active RM宕机时，ZooKeeper会触发选举，Standby RM会接管服务，并从状态存储中恢复之前运行任务的信息，确保计算任务不中断。