![[fe889daa8be54dcaa1c7cc364c7a35f5.png]]

# 一、概述

NameNode是整个文件系统的管理节点，它主要维护着整个文件系统的文件目录树，文件/目录的信息 和 每个文件对应的数据块列表，并且还负责接收用户的操作请求

### 文件目录树
表示目录之间的层级关系，就是我们在hdfs上执行ls命令可以看到的那个目录结构信息

### 文件/目录的信息
表示文件/目录的的一些基本信息，所有者 属组 修改时间 文件大小等信息

### 数据块列表
如果一个文件太大，那么在集群中存储的时候会对文件进行切割，这个时候就类似于会给文件分成一块一块的，存储到不同机器上面。所以HDFS还要记录一下一个文件到底被分了多少块，每一块都在什么地方存储着

# 二、元数据文件
+ fsimage：元数据镜像文件，存储某一时段NameNode内存元数据信息
+ edits：操作日志文件
+ seen_txid：是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。如果根据对应的seen_txid无法加载到对应的文件，NameNode进程将不会完成启动以保护数据一致性。
+ VERSION：保存了集群的版本信息

根据hdfs-site.xml文件配置，找到dfs.namenode.name.dir属性，可以找到元数据目录$dfs.namenode.name.dir/current
![[Snipaste_2023-03-06_10-26-39 1.png]]
in_use.lock 这个只是一个普通文件，但是它其实有特殊的含义，文件名后缀值lock 表示是锁的意思，文件名是in_use 表示这个文件现在正在使用，不允许你再启动namenode。当我们启动namonde的时候 会判断这个目录下是否有in_use.lock 这个相当于一把锁，如果没有的话，才可以启动成功，启动成功之后就会加一把锁， 停止的时候会把这个锁去掉。
![[Snipaste_2023-03-06_10-26-39.png]]

## 2.1 fsimage
fsimage文件有两个文件名相同的，有一个后缀是md5，md5是一种加密算法，这个其实主要是为了做md5校验的，为了保证文件传输的过程中不出问题，相同内容的md5是一样的，所以后期如果我把这个fsimage和对应的fsimage.md5发给你 然后你根据md5对fsimage的内容进行加密，获取一个值 和fsimage.md5中的内容进行比较，如果一样，说明你接收到的文件就是完整的。

通过命令将fsimage转为xml，方便查看
```shell
hdfs oiv -p XML -i fsimage_0000000000000000056 -o fsimage56.xml
```

里面最外层是一个fsimage标签，看里面的inode标签，
这个inode表示是hdfs中的每一个目录或者文件信息
```xml
<inode>
            <id>16393</id>
            <type>FILE</type>
            <name>LICENSE.txt</name>
            <replication>2</replication>
            <mtime>1586332513657</mtime>
            <atime>1586332513485</atime>
            <preferredBlockSize>134217728</preferredBlockSize>
            <permission>root:supergroup:0644</permission>
            <blocks>
                <block>
                    <id>1073741827</id>
                    <genstamp>1003</genstamp>
                    <numBytes>150569</numBytes>
                </block>
            </blocks>
            <storagePolicyId>0</storagePolicyId>
</inode>
```

id：唯一编号
type：文件类型
name：文件名称
replication：文件的副本数量
mtime：修改时间
atime：访问时间
preferredBlockSize：推荐每一个数据块的大小
permission：权限信息
blocks：包含多少数据块【文件被切成数据块】
block：内部的id表示是块id，genstamp是一个唯一编号，numBytes表示当前数据块的实际大小，storagePolicyId表示是数据的存储策略

**这个文件中其实就维护了整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表，所以说fsimage中存放了hdfs最核心的数据。**

## 2.2 edits
当我们上传大文件的时候，一个大文件会分为多个block，那么edits文件中就会记录这些block的上传状态，只有当全部block都上传成功了以后，这个时候edits中才会记录这个文件上传成功了，那么我们执行hdfs dfs -ls 的时候就能查到这个文件了，所以当我们在hdfs中执行ls命令的时候，其实会查询fsimage和edits中的内容。

查看edits文件：
```shell
hdfs oev -i  edits_0000000000000000057-0000000000000000065  -o edits.xml
```

OP_ADD：执行上传操作
OP_ALLOCATE_BLOCK_ID：申请block块id
OP_SET_GENSTAMP_V2：设置GENSTAMP
OP_ADD_BLOCK：添加block块
OP_CLOSE：关闭上传操作

```xml
<RECORD>
    <OPCODE>OP_ADD</OPCODE>
    <DATA>
        <TXID>58</TXID>
        <LENGTH>0</LENGTH>
        <INODEID>16396</INODEID>
        <PATH>/user.txt</PATH>
        <REPLICATION>3</REPLICATION>
        <MTIME>1586349095694</MTIME>
        <ATIME>1586349095694</ATIME>
        <BLOCKSIZE>134217728</BLOCKSIZE>
        <CLIENT_NAME>DFSClient_NONMAPREDUCE_-1768454371_1</CLIENT_NAME>
        <CLIENT_MACHINE>192.168.182.1</CLIENT_MACHINE>
        <OVERWRITE>true</OVERWRITE>
        <PERMISSION_STATUS>
            <USERNAME>yehua</USERNAME>
            <GROUPNAME>supergroup</GROUPNAME>
            <MODE>420</MODE>
        </PERMISSION_STATUS>
        <ERASURE_CODING_POLICY_ID>0</ERASURE_CODING_POLICY_ID>
        <RPC_CLIENTID>1722b83a-2dc7-4c46-baa9-9fa956b755cd</RPC_CLIENTID>
        <RPC_CALLID>0</RPC_CALLID>
    </DATA>
</RECORD>
<RECORD>
    <OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
    <DATA>
        <TXID>59</TXID>
        <BLOCK_ID>1073741830</BLOCK_ID>
    </DATA>
</RECORD>
```

每一个record都有一个事务id，txid，事务id是连续的（从58到59，正常情况下有5个步骤，所以有5个连续的txid），其实一个put操作会在edits文件中产生很多的record，对应的就是很多步骤，这些步骤对我们是屏蔽的。

## 2.3 seen_txid
![[Snipaste_2023-03-06_10-26-39 3.png]]
seen_txid文件，HDFS format之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。如果根据对应的seen_txid无法加载到对应的文件，NameNode进程将不会完成启动以保护数据一致性。

## 2.4 VERSION
![[Snipaste_2023-03-06_10-26-39 2.png]]

# 三、SNN合并日志
edits隔一段时间就会对fsimage进行同步(合并)。edits在执行读写合并操作时，是被占用状态，整个namenode不能对外提供服务。用户一来会先找edits。这样不好。namenode是整个集群的管理和元数据记录。读写操作消耗很大。合并这件事可以定期发送给SecondaryNameNode来做。为了保证实时提供服务创建新的edits临时替代原来的edits对外提供服务。SecondaryNameNode的fsimage和edits合并后得到新的fsimage(SecondaryNameNode的edits被删除)传回给namenode，namenode的edits被清空。

![[5128967-24284b0c0ed22be3.png]]