hdfs HA 机制， 一台 namenode 宕机了， joualnode ， namenode ， edit.log fsimage 的 变 化？思维导图 代码示例（java 架构)

HDFS（Hadoop Distributed File System）的高可用性（HA, High Availability）机制旨在解决单点故障问题，确保即使在NameNode出现故障的情况下，文件系统仍然可以继续正常工作。在HA配置中，有两个或多个NameNode：一个处于活动状态（Active），另一个作为备用（Standby）。JournalNodes用于同步编辑日志（Edit Log），以确保两个NameNode之间的元数据一致性。

HDFS HA 机制概述

组件介绍

• Active NameNode：负责处理客户端的所有读写请求。
• Standby NameNode：在后台运行，保持与Active NameNode同步，并准备接管角色。
• JournalNodes：一组独立的服务节点，用于存储和同步来自Active NameNode的编辑日志条目。通常建议至少有三个JournalNodes来实现容错。

工作流程

1. 启动时：

   • Active NameNode加载FsImage到内存，并开始接收新的编辑操作。
   • Standby NameNode也加载相同的FsImage副本，但不处理任何客户端请求。

2. 正常操作期间：

   • 每次Active NameNode执行更改文件系统状态的操作时（如创建文件、删除文件等），它会将这些变更记录为编辑日志条目并发送给所有JournalNodes。
   • JournalNodes将接收到的编辑日志条目持久化到本地磁盘上的edit.log文件中。
   • Standby NameNode定期从JournalNodes拉取最新的编辑日志条目，并应用到自己的内存状态中，以保持与Active NameNode同步。

3. 故障转移时：

   • 如果Active NameNode宕机，ZooKeeper Failover Controller（ZKFC）检测到这一情况后会触发故障切换过程。
   • ZKFC确保只有一个NameNode是活动的，并促使Standby NameNode转变为新的Active NameNode。
   • 新的Active NameNode会重新加载最新的FsImage和编辑日志，恢复文件系统的最新状态，并开始处理客户端请求。

4. 恢复后：

   • 原来的Active NameNode如果重启，则自动成为Standby NameNode，并重新开始同步过程。

当一台NameNode宕机时的变化

• JournalNodes：

  • 由于它们保存了所有编辑日志条目，因此不会受到单一NameNode宕机的影响。只要大多数JournalNodes仍然可用，就可以保证编辑日志的安全性和一致性。

• NameNode：

  • 原来的Active NameNode宕机后，它的职责由Standby NameNode接管，后者变为新的Active NameNode。

• Edit Log 和 FsImage：

  • 在故障切换之前，Standby NameNode已经通过JournalNodes获取到了最新的编辑日志条目，并将其应用于自身的内存状态中。
  • 故障切换完成后，新的Active NameNode会根据需要进行FsImage和编辑日志的合并，以确保文件系统的最新状态被正确反映。

思维导图描述

• HDFS HA 机制
  • 组件
    • Active NameNode
      • 处理客户端请求
      • 记录编辑日志
    • Standby NameNode
      • 同步状态
      • 准备接管
    • JournalNodes
      • 存储编辑日志
      • 提供一致性
  • 工作流程
    • 启动时
      • 加载FsImage
      • 初始化状态
    • 正常操作期间
      • 编辑日志同步
      • 状态保持一致
    • 故障转移时
      • 触发故障切换
      • 新的Active NameNode接管
    • 恢复后
      • 自动成为Standby
      • 继续同步
  • 故障变化
    • JournalNodes
      • 不受影响
      • 继续提供服务
    • NameNode
      • Active变Standby
      • Standby变Active
    • Edit Log 和 FsImage
      • 保持最新状态
      • 必要时合并

Java代码示例（与HDFS HA交互）

以下是一个简单的Java程序，展示了如何使用Hadoop提供的API与配置好的HDFS HA集群进行交互：

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;

import java.io.IOException;
import java.net.URI;

public class HdfsHaInteractionExample {

    public static void main(String[] args) {
        // 创建并配置Hadoop Configuration对象
        Configuration conf = new Configuration();
        
        // 设置HDFS HA相关配置参数
        conf.set("fs.defaultFS", "hdfs://myhacluster"); // 替换为你的HA集群名称
        conf.set("dfs.nameservices", "myhacluster");
        conf.set("dfs.ha.namenodes.myhacluster", "nn1,nn2");
        conf.set("dfs.namenode.rpc-address.myhacluster.nn1", "namenode1:8020");
        conf.set("dfs.namenode.rpc-address.myhacluster.nn2", "namenode2:8020");
        conf.set("dfs.client.failover.proxy.provider.myhacluster", "org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider");

        try (FileSystem fs = FileSystem.get(new URI("hdfs://myhacluster"), conf)) {
            // 列出目录内容
            Path dirPath = new Path("/user/example");
            if (fs.exists(dirPath)) {
                System.out.println("Listing directory contents:");
                fs.listStatus(dirPath).forEach(status -> {
                    System.out.println(status.getPath().getName());
                });
            } else {
                System.out.println("Directory does not exist.");
            }

            // 注意：Hadoop API会自动处理HA相关的逻辑，例如故障切换等
            // 用户无需特别关心当前哪个NameNode是活跃的

        } catch (IOException | InterruptedException | URISyntaxException e) {
            System.err.println("Error interacting with HDFS HA cluster: " + e.getMessage());
        }
    }
}

这段代码通过设置适当的配置参数，使得Hadoop客户端能够透明地与HDFS HA集群通信，而不需要显式地指定当前活跃的NameNode。Hadoop库内部会处理所有的故障检测和切换逻辑，确保应用程序可以在NameNode故障时继续正常工作。

结论

HDFS HA机制通过引入多个NameNode和JournalNodes，有效地解决了单点故障的问题，提高了文件系统的可靠性和可用性。当一台NameNode宕机时，另一台可以迅速接管其职责，确保服务连续性。同时，JournalNodes的存在保证了元数据的一致性和安全性。对于开发者来说，使用Hadoop提供的API与HA集群交互是非常直观的，因为大部分复杂的细节已经被框架本身所隐藏。