导航：首页 > 互联网科技 >

十、HDFS的namenode工作机制

发表于：2026-11-02 作者：千家信息网编辑

千家信息网最后更新 2026年11月02日，[TOC]一、fsimage和edits文件1、基本概念txid：namenode对每个操作事件（增删改操作）都给了一个唯一的id标识，称为txid，一般是从0开始自增，每多一个操作，txid就自增1

千家信息网最后更新 2026年11月02日十、HDFS的namenode工作机制

[TOC]

一、fsimage和edits文件

1、基本概念

txid：
namenode对每个操作事件（增删改操作）都给了一个唯一的id标识，称为txid，一般是从0开始自增，每多一个操作，txid就自增1。

fsimage：
是namenode在内存中的元数据在本地磁盘的一个镜像文件，但是通常情况fsimage并没有包含自新的操作事件，所以本质上和内存中元数据还是有差距的。这里记录的不是操作日志，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。一般命名方式是fsimage_txid 的形式，后面的txid表示该fsimage记录的最新的操作事件的txid。

edits：
是记录对namenode进行增删改操作的操作日志文件，如果有知道mysql的话，这和mysql 的二进制日志有点相似。

2、namenode的目录结构

[root@bigdata121 tmp]# tree dfs/namedfs/name├── current│   ├── edits_0000000000000000001-0000000000000000002│   ├── edits_0000000000000000003-0000000000000000004│   ├── edits_0000000000000000005-0000000000000000006│   ├── edits_0000000000000000007-0000000000000000008│   ├── edits_0000000000000000009-0000000000000000009│   ├── edits_0000000000000000010-0000000000000000011│   ├── edits_0000000000000000012-0000000000000000013│   ├── edits_0000000000000000014-0000000000000000015│   ├── edits_0000000000000000016-0000000000000000017│   ├── edits_0000000000000000018-0000000000000000019│   ├── edits_0000000000000000020-0000000000000000021│   ├── edits_0000000000000000022-0000000000000000024│   ├── edits_0000000000000000025-0000000000000000026│   ├── edits_inprogress_0000000000000000027│   ├── fsimage_0000000000000000024│   ├── fsimage_0000000000000000024.md5│   ├── fsimage_0000000000000000026│   ├── fsimage_0000000000000000026.md5│   ├── seen_txid│   └── VERSION└── in_use.lock

总结来说，其实简化成以下结构：

dfs/name├── current│   ├── edits_txid1-txid2        可能有多个，是已经滚动生成的旧的edits文件│   ├── edits_inprogress_txid3   是目前正在使用的edits│   ├── fsimage_0000000000000000024       fsimage文件│   ├── fsimage_0000000000000000024.md5   fsimage文件的md5校验值│   ├── seen_txid                 记录最新的txid│   └── VERSION                    记录hdfs集群的一些简单信息└── in_use.lock                    锁文件，避免该目录用于启动多个namenode

（1）VERSION文件的内容

# 在hdfs中会有多个namenode，不同的namenode的namenodeID是不同的，分别管理一组blockpoolIDnamespaceID=983105879# 集群ID，全局唯一clusterID=CID-c12b7022-0c51-49c5-942f-edc889d37fee# 标记该namenode的存储目录创建的时间。对于刚刚创建的存储系统，这个属性为0.但在文件系统升级之后，该值会更新到新的时间戳cTime=1558262787574           # 标记该存储目录是namenode还是datanodestorageType=NAME_NODE              # 一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。blockpoolID=BP-473222668-192.168.50.121-1558262787574 # 这个没什么用layoutVersion=-63

（2）seen_txid
这个文件中记录了目前最新的一个txid

（3）SNN的目录结构和namenode是一样的，只是缺少了部分最新的edits文件。

3、fsimage和edit文件命名方式的联系

我们可以看到上面fsimage和edits文件的文件名都跟着很长一串数字，那是什么呢，其实是txid，从两者命名方式上，我们可以看出一些规律来。

edits文件：
我们可以看到edits文件都是 edits_00000xxx-000000xxx的方式命名的，其实意思就是表示该edits文件中记录了txid操作事件的范围。而 edit_inprogess_00000xxx 则表示当前所记录到的最新的txid事件，以及该文件是目前正在使用的edits文件。

fsimage文件：
以fsimage_000000xxx 的方式命名，表示的是该fsimage 文件记录到的最新的txid事件，请注意，因为fsimage是有条件触发之后，edits文件才会合并到fsimage的，否则不会合并。所以一般情况下，edits文件后面的txid会比fsimage 大的。

4、查看fsimage文件的内容

//格式 ： hdfs oiv -p 输出格式 -i 输入文件 -o 输出文件[root@bigdata121 current]# hdfs oiv -p XML -i fsimage_0000000000000000037 -o /tmp/fsimage37.xml

前面已经说到，fsimage记录的主要是元数据信息，它描述了hdfs 中存储的目录结构以及目录下的文件，还有对应的目录和文件的元信息。我们截取部分信息来看看：

            -63        1        17e75c2a11685af3e043aa5e604dc831e5b14674                983105879        1000        1014        0        1073741837        334                16407        16        这里开始是重点，记录的就是目录结构以及元信息                    16386            DIRECTORY    这个是目录，名字是test            test            1558263065070  修改时间            root:supergroup:0755 权限            -1            -1                            16387    这是个文件，名为edit_new.xml            FILE            edit_new.xml            2            1558263065045            1558269494520            134217728            root:supergroup:0644  权限               这里是block信息，包含了哪些block                                    1073741825                    1001                    580                                        0

由以上这部分fsimage信息可知，它记录当前文件系统的目录结构以及对应的元信息。和edits的差别是，edits记录的是对该文件系统的操作。

5、查看edits文件内容

//格式：hdfs oev -p 输出格式(默认XML) -i 输入文件 -o 输出文件[root@bigdata121 current]# hdfs oev -i edits_inprogress_0000000000000000038 -o /tmp/edits_inprogess.xml

同样截取部分信息查看：

  -63      OP_START_LOG_SEGMENT   表示操作的类别，这里是表示日志开始记录          38  类似于操的ID，是唯一的      每个RECORD记录的就是一次操作    OP_ADD_BLOCK     //像这个就表示上传文件的操作          34      /jdk-8u144-linux-x64.tar.gz._COPYING_              1073741825        134217728        1001                    1073741826        0        1002                  -2

每个RECORD记录了一次操作，比如图中的
OP_ADD代表添加文件操作。一般来说里面还记录了
文件路径（PATH）
修改时间（MTIME）
添加时间（ATIME）
客户端名称（CLIENT_NAME）
客户端地址（CLIENT_MACHINE）
权限（PERMISSION_STATUS）等非常有用的信息

6、手动滚动edits日志

格式：hdfs dfsadmin -rollEdits

7、NN,SNN,DN数据目录的配置

（1）配置了hadoop.tmp.dir

在core-site.xml中配置了hadoop.tmp.dir的话，各自的数据目录如下：

NN:{hadoop.tmp.dir}/dfs/name  fsimage和edits文件都会存储在这一个目录下SNN:${hadoop.tmp.dir}/dfs/namesecondary   SNN的数据目录DN:${hadoop.tmp.dir}/dfs/data            datanode的数据目录

（2）单独设置目录

如果不设置hadoop.tmp.dir 这个值，那么NN,SNN,DN都需要手动设置各自的数据目录，否则数据文件都会生成到 /tmp/hadoop-root/dfs/ 下，各自的设置参数如下：

/*都在hdfs-site.xml中设置*///如果这两个只设置了其中一个，那么fsimage和edits文件都会存储到指定的一个目录下NN:dfs.namenode.name.dir   设置fsimage存储的路径   dfs.namenode.edits.dir   设置edits存储路径DN: dfs.datanode.data.dir  这是datanode存储目录SNN：dfs.namenode.checkpoint.dir  这是SNN存储目录

（3）namenode多目录的设置

在单独设置namenode的工作目录时，我们可以给dfs.namenode.name.dir 设置多个值，以逗号分隔开，那么hdfs namenode -format格式化的时候，也会格式化出两个namenode目录，并且两个目录在运行过程中内容也保持一致，可以使用这种方式作为给namenode备份数据的补充。如：

        dfs.namenode.name.dir        file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2

二、namenode和SNN工作流程

1、namenode启动阶段

（1）第一次启动namenode时（即第一次格式化namenode之后），会自动创建fsimage和edits文件。如果不是第一次启动，则namenode会加载最新的fsimage以及从fsimage开始到最新的操作事件（以seen_txid文件记录的txid为准）的所包含的edits文件到内存中，最终在内存中存储的是最新的元信息。并创建一个新的edits文件，用于记录的操作，名字是 edit_inprogress_xxxx。
（2）client 对namenode发起增删改请求
（3）namenode响应请求
（4）namenode记录增删改操作时，会先将操作写入到edits文件中，当成功写入之后，才会修改内存中存储的元数据。这种方式是为了保证最新的操作一定持续化存储在磁盘这种永久性存储中，避免意外导致操作记录丢失。

2、SNN工作阶段

（1）SNN根据设置的检查checkpoint的时间间隔，询问namenode是否需要执行checkpoint。namenode响应SNN结果。
（2）如果结果为是，则SNN请求namenode执行checkpoint操作
（3）namenode开始执行checkpoint操作，首先滚动目前正使用的edits文件，将滚动后的edits文件命名为 edits_txid1-txid2的形式，并创建新的edits文件，名字为 edits_inprogess_txid2+1。滚动edits目的主要是为了防止合并操作影响namenode对外提供服务，滚动之后，操作记录可以正常写入到新的edits文件中。
（4）将最新的fsimage(看文件后面的txid，最大的就是最新的)，以及由此到最新的txid的edits文件拷贝到SNN。注意看fsimage文件名的txid以及edits文件名后面的txid，小于fsimage后面的txid的edits文件不需要拷贝。
（5）SNN读取拷贝过来的fsiamge和edits文件到内存中进行合并
（6）合并后生成新的fsimage文件，名字为 fsimage.chkpoint
（7）拷贝fsimage.chkpoint到namenode
（8）namenode收到fsimage.chkpoint之后，重名为 fsimage_txid 的形式，后面txid表示此fsimage文件记录的最新的操作的txid。

3、checkpoint检查参数配置

hdfs-default.xml

---------------checkpoint实际间隔------------------------  dfs.namenode.checkpoint.period  3600---------------操作次数------------------------  dfs.namenode.checkpoint.txns  1000000操作动作次数  dfs.namenode.checkpoint.check.period  60