一、概述用户使用 HDFS 的时候，会将每个 DataNode 数据目录所在的本地目录挂载到某块独立的盘上，以此来完全利用节点的存储空间。所以如果某块盘突然发生了硬件故障导致写文件失败，这块盘将会被 HDFS 检测出来，并加入到坏盘列表，其上的数据也将被完全拷贝一份。也就是说，DataNode从此刻开始就完全不会用这块盘了。由此可见，HDFS对于坏盘的检测还是非常看重的，毕竟谁也不想把数据放在坏了的磁盘上吧。DiskChecker服务并不是一个周期性的定时任务，它只会在可能有坏盘出现的场景中被启动，然后执行。在这点上，如果你没有仔细研究过它的原理，可能会很容易被它的名称所误解。 二、架构设计HDFS 为了保证 DataNode 上数据的完整性与一致性，在 DataNode 上启动了三大磁盘目录扫描服务 DiskChecker、DirectoryScanner 和VolumeScanner。 2.1. DiskChecker: 坏盘检测检测的级别是每个磁盘，检测的对象是 FsVolume，FsVolume 对应一个存储数据的磁盘。通过检测文件目录的访问权限以及目录是否可创建来判断目录 ...

一、概述二、架构设计2.1. BlockPoolManager在 HDFS Federation 部署中，一个 HDFS 集群可以配置多个命名空间，每个 Datanode 都会存储多个块池的数据块。在 Datanode 实现中，定义了 BlockPoolManager 类来管理 Datanode 上的所有块池，Datanode 的其他模块对块池的操作都必须通过 BlockPoolManager 执行，每个 Datanode 都有一个 BlockPoolManager 的实例。 BlockPoolManager 逻辑结构图如图 4-29 所示。由于在 HDFS Federation 部署中，一个Datanode 会保存多个块池的数据块，所以 BlockPoolManager 会拥有多个 BPOfferService 对象，每个 BPOfferService 对象都封装了对单个块池操作的 API。同时，由于在 HDFS HA 部署中，每个命名空间又会同时拥有两个 Namenode，一个作为活动的(Active) Namenode，另一个作为热备的 （Standby) Namenode， ...

Namenode 会定期将内存中的命名空间（文件目录树、文件目录元信息)保存到 Fsimage 文件中，以防止 Namenode 掉电或者进程崩溃。如果 Namenode 实时地将内存中的元数据同步到 fsimage 文件中，会非常消耗资源且造成 Namenode 运行缓慢。所以 Namenode 会先将命名空间的修改操作保存在 editlog 文件中，然后定期合并 Fsimage 和 editlog 文件。 Namenode 启动时，首先会将 fsimage 文件中记录的命名空间加载到 Namenode 内存中，然后再一条一条地将 editlog 文件中记录的更新操作加载并合并到命名空间中。接下来 Namenode 会等待各个 Datanode 向自己汇报数据块信息来组装 blockMap,从而离开安全模式。Namenode 每次启动时都会调用 FSImage.loadFsImage() 方法执行加载 fsimage 和 editlog 文件的操作。 一个正常大小的 editlog 文件往往在几十到几百个字节之间，但在某些极端的情况下，editlog 文件会变得非常大，甚至将磁盘 ...

HDFS 会定时将 editlog 文件与 fsimage 文件合并以产生新的 fsimage 文件。Namenode 可以直接从 fsimage 加载元数据，而不用读取与合并 editlog 中的记录了。Namenode 命名空间的重建效率会大大提高，同时 Namenode 的启动时间也会相应减少。但是合并 fsimage 与editlog 以产生新的fsimage 文件是一项非常消耗 I/O 和 CPU 资源的操作。在执行检查点操作期间，Namenode 还需要限制其他用户对 HDFS 的访问和操作。为了预防这种情况的发生，HDFS 将检查点操作从Active Namenode 移动到 StandbyNamenode Editlog 文件会变得非常大，甚至将磁盘空间写满。在 Namenode启动过程中一个很重要的部分就是逐条读取editlog文件中的记录，之后与 Namenode 命名空间合并。巨大的 editlog 文件会导致 Namenode 的启动时间过长，为了解决这个问题，HDFS引入了检查点机制 一、概述 变量初始化 tailerThread 实例化 EditLo ...

一、概述FSImage 类最重要的功能之一就是将当前时刻 Namenode 的命名空间保存到 fsimage 文件中。 二、实现FSNameSystem 会调用 FSImage.saveNamespace() 方法触发命名空间的保存操作。 2.1. saveFSImagelnAllDirs()Namenode 可以定义多个存储路径来保存 fsimage 文件，对于每一个存储路径，saveFSImagelnAllDirs() 方法都会启动一个线程负责在这个路径上保存 fsimage 文件。同时，为了防止保存过程中出现错误，命名空间信息首先会被保存在一个 fsimage.ckpt 文件中，当保存操作全部完成之后，才会将 fsimage.ckpt 重命名为 fsimage 文件。之后 saveFSImagelnAllDirs()方法会清理 Namenode 元数据存储文件夹中过期的 editlog 文件和 fsimage 文件。 命名空间具体的保存操作是由 FSImageSaver 类负责，FSImageSaver 是 FSImage 中的内部类，也是一个线程类，它的 run() 方 ...

一、概述客户端通过调用 ClientProtocol.create() 方法创建一个新的文件，这个调用由 NamenodeRpcServer.create()方法响应，create(）方法会调用 FSNamesystem.startFileInt(), startFileInt() 方法会级联调用FSNamesystem.startFileInternal() 来创建一个新的文件。 二、实现2.1. 前置准备 获取发起请求客户端地址 检查路径深度 RetryCache 机制 1234CacheEntryWithPayload cacheEntry = RetryCache.waitForCompletion(retryCache, null);if (cacheEntry != null && cacheEntry.isSuccess()) { return (HdfsFileStatus) cacheEntry.getPayload();} https://blog.csdn.net/androidlushangderen/articl ...

一、概述二、实现一直点点点～～～，最终代码定位到 NameNodeRpcServer#mkdirs() 12// 此处调用服务端 RPCboolean mkdirs = namenode.mkdirs(src, absPermission, createParent); 检查 NameNode 是否启动 1checkNNStartup(); namesystem.mkdirs 1return namesystem.mkdirs(src, new PermissionStatus(getRemoteUser().getShortUserName(), null, masked), createParent); 检查权限 1checkOperation(OperationCategory.WRITE); 检查是否是安全模式 判断是否是安全模式，如果是安全模式是不可以写入数据的 1checkNameNodeSafeMode("Cannot create directory " + src); 创建文件夹 1auditStat = FSDirMkdirOp.mk ...

一、概述目前 Namenode 可以在多种类型的异构存储上保存 editlog 文件，例如普通文件系统、共享 NFS、 Bookkeeper 以及 Quorum 集群等，所以 EditLogOutputStream 定义了多个子类来向不同存储系统上的 editlog 文件中写入数据。 EditLogFileOutputStream 抽象了本地文件系统上 editlog 文件的输出流，BookKeeperEditLogOutputStream 抽象了 BookKeeper 系统上 editlog 文件的输出流，QuorumOutputStream 抽象了 Quorum 集群上 editlog 文件的输出流。 同时由于 Namenode 可以同时向多个不同的存储上写入 editlog 文件，所以 EditLogOutputStream 还定义了子类 JournalSetOutputStream 执行聚合的写入操作。 二、实现JournalSetOutputStream 类是 EditLogOutputStream 的子类，在 JournalSetOutputStream 对象上调用的 ...

数据在写入 editlog 文件前，会首先被写入到输出流的缓冲区中。EditLogFileOutputStream 的缓冲区用到了一个比较特殊的数据结构—Edits Double Buffer，这儿我们涉及到了一点源码修改哦～ 一、概述一块内存不能同时并发读写一块内存数据, 因此 HDFS 引入的双缓冲机制，把一块内存划分为两个部分, 将缓冲区分为 2 份，1份为当前缓冲区 buf current，另外 1 份为预写入分区 buf ready，两个缓冲区空间大小一致。current 区负责当前的写操作存放，当我们达到缓冲处罚条件时，执行一次双缓冲的调换操作。然后由另外的程序执行 ready 区的 flush 操作。被交换变为空缓冲区的 current 区重新用于这的数据写入。‌‌‌以上的执行模式有以下2大优势: ‌程序无需反复进行创建新缓冲的操作 程序的写请求不会被阻塞住，除非current缓冲区已经满了同时ready缓冲区数据还没有全部flush出去 二、源码2.1. EditLogEditLog 类 是对 EditLog 日志的一个封装，属性 txid 和 conte ...

看源码啦～～～😊 一、概述目前 Namenode 的实现是将命名空间信息记录在 fsimage(命名空间镜像）的二进制文件中，fsimage 将文件系统目录树中的每个文件或者目录的信息保存为一条记录，每条记录中包括了该文件（或目录）的名称、大小、用户、用户组、修改时间、创建时间等信息。Namenode 重启时，会读取这个 fsimage 文件来重构命名空间。 为了避免 Namenode 两次持久化之间数据丢失的问题，又设计了 Edits log 编辑日志文件，HDFS 将新 fsimage 文件和上一个 fsimage 文件中进行的 Namenode 操作记录在 editlog (编辑日志) 文件中，editlog 是一个日志文件，文件中记录的是 HDFS 所有更改操作（文件创建，删除或修改）的日志，文件系统客户端执行的更改操作首先会被记录到 edits 文件中。 对于修改元数据的动作，比如申请上传一个文件，需要在内存文件目录树中加入一个文件，都要写一个 edits log，写 edits log 的两个步骤 写入本地磁盘 通过网络传输给 JournalNodes 集群 通 ...