分布式存储引擎：HDFS架构与读写流程

可视化演示

查看NameNode与DataNode分离架构，观察写入流水线五阶段与副本放置，以及读取流程与短路读优化。

架构总览——图书管理员与巨型书架

想象你管理着一座大型图书馆：书太多，必须分散到不同房间的书架上；但你不会亲自搬书，而是手里攥着一本总目录，记录每本书被拆成了哪几册、分别放在哪个房间的哪个书架。读者来借书时，报出书名，你查目录告诉他位置，然后他自己直奔书架取书。HDFS 的设计与之如出一辙：NameNode 是你的总目录，DataNode 是书架，客户端是读者。

HDFS 采用典型的主从（Master/Slave）架构。NameNode 负责管理元数据——文件目录树、文件与数据块的映射、数据块与 DataNode 的对应关系；DataNode 负责实际的数据存储与读写，定期向 NameNode 报告自己的状态。二者分工明确：管理员不摸书，书架不记目录。客户端读写文件时，先与 NameNode 通信拿到元数据，然后直接与 DataNode 传输数据，这让 NameNode 不必成为每条数据流的搬运工。

数据以“数据块”（Block）为单位存储，默认每个块 128MB。一个大文件会被切成多个块，分布在不同 DataNode 上。为什么块要设得这么大？因为元数据全部保存在 NameNode 内存中，块的数量越少、元数据开销越小；而块太小又会导致块数量过多、内存吃紧。128MB 是工程实践中的平衡点。一个文件被切成的块数可以精确计算：

所以管理员的总目录上只写“某书分几册、分别在哪”，从不抄录书的内容；NameNode 管“在哪里”，DataNode 管“内容是什么”。这一层“元数据与数据分离”的架构，正是 HDFS 能支撑 PB 级文件存储的第一块基石。

元数据管理——目录册与便签本

图书馆管理员随身的工具很讲究：一本厚厚的总目录册（FsImage），记录某个时刻所有书的摆放快照；一叠便签本（EditLog），记录此后每一次新书入库、移位、注销操作。他不会每动一本书就重抄一遍目录册——那太慢了，他只在便签上写一行“某某书放到 X 房间 Y 书架”，等便签攒厚了再合并进目录册并清空旧便签。

FsImage 就是 NameNode 的元数据快照文件，包含整个文件系统的目录树、文件与块的映射；EditLog 则是所有写操作的追加日志。NameNode 启动时，先把 FsImage 从磁盘加载进内存，再按顺序重放 EditLog 中的每一条操作，从而重建出最新的元数据视图。这个过程可以概括为：

随着系统运行，EditLog 会无限膨胀。HDFS 引入 SecondaryNameNode（辅助管理节点）定期执行“检查点合并”：它从 NameNode 拉取最新的 FsImage 和 EditLog，在本地合并出新的 FsImage，再传回 NameNode。触发条件通常是 EditLog 达到 1GB 阈值，或距离上次合并超过 1 小时。注意，SecondaryNameNode 并不是热备节点，不会自动接管故障，它只是“帮管理员整理目录册的助手”。

这就像管理员每隔一小时坐下整理一次便签，誊进目录册后再把旧便签撕掉。这样一来，即使目录册意外损坏，他也能靠“最近一次快照 + 之后的便签”重新恢复全部记录——只要合并机制保持及时，便签永远不可能堆到天荒地老。

副本机架感知——多备份与不同房间

图书馆有一本绝版手稿，你担心某个房间漏水或失火，于是决定抄写备份。怎么放最稳妥？你的选择是：抄三份，两份放在同一个房间的不同书架上，方便助手之间快速互相校对补抄；第三份放到另一个房间，防止整个房间遭遇火灾时所有副本同归于尽。HDFS 的三副本放置策略正是这个思路的工程化表达。

HDFS 默认副本因子（dfs.replication）为 3。机架感知（rack-aware）策略规定：第一个副本放在与客户端同机架的某个 DataNode 上；第二个副本放在同一机架但不同的 DataNode 上；第三个副本放在不同机架的 DataNode 上。这样既保证了单个机架整体断电时仍有副本存活，又利用了同机架内的高带宽加速复制。

为什么要“两近一远”而不是“三个都远”？因为机架内网络带宽远高于跨机架带宽。同机架放两个副本，能让副本复制主要发生在高速的机架内网络；跨机架放一个副本，则是为“整个机架故障”这种极端情况上保险。这一策略可以简洁地表达为：

这就是“鸡蛋不放一个篮子”的系统化版本。管理员不会把三本手稿都锁进同一个房间——一个插座起火就能烧掉全部家底；但全放不同房间也不现实——助手抄书时跨房间跑腿太慢。两个近的保效率，一个远的保安全，恰好平衡。

写入流水线——接力抄写与签名确认

作家交来一章新书手稿。管理员叫来三名助手排成一列：助手 A 拿到原稿后抄写一份，随即递给身后的 B；B 抄好后递给 C；C 抄完放上书架。每人都抄完后，从后往前把“已完成”的签名（ACK）传回给管理员。整个流程像一条流水线：上游刚抄完、下游马上接棒，谁也不用等全部抄完再开工。

HDFS 写入过程正是如此。客户端先向 NameNode 请求创建文件，NameNode 在目录树中登记并返回目标 DataNode 列表（按 rack-aware 策略选出的 3 个节点）。随后客户端把数据流切成 64KB 的 packet 包，以流水线方式发送：client → DN0 → DN1 → DN2。每个 DataNode 收到 packet 后先落盘，再继续转发给下游，同时向上游回传 ACK，最终全部确认后才算写入成功。

这个设计的精妙之处在于：向 3 个副本写数据并不需要客户端广播三份，而是让同一份数据沿着链路“借道”传播。总写入时间也不是“三份副本各自传一遍”的开销，而是“一份数据串行经过三个节点”的流水线延迟：

就像三名助手站在传送带旁接力抄写，而不是三个人各拿一份原稿分头抄写。表面看是“排队”，实则一道工序同时推进三份副本，把网络与磁盘的利用率都压满了。

读取流程——就近取书与快速通道

读者来借一本分三册的书。管理员翻开目录册，报出位置：“上册在第 2 房间第 1 书架，中册在第 5 房间，下册在第 2 房间第 3 书架。”读者听完后自然不会绕远路，而是先去最近的房间把书拿到手。如果这位读者本身就是图书管理员助理，他甚至可以直接打开书架侧面的夹层取书，连填单、递书的流程都省了——这就是“就近读取”与“短路读”。

HDFS 读取同样分两步：客户端先向 NameNode 请求文件各数据块的副本位置，NameNode 返回按客户端距离排序的 DataNode 列表，距离按“本地 > 同机架 > 跨机架”排序；客户端选择排在最前面的节点直接读取数据。整个过程不经过 NameNode 转发数据，NameNode 只负责“指路”。

短路读（Short-Circuit Read）是进一步优化：当客户端与 DataNode 在同一台物理机上时，客户端可以通过 Unix 域套接字直接打开数据文件，绕过 DataNode 的网络协议栈和 RPC 层，避免一次内存拷贝和网络协议开销。与之配合的是数据本地性（Data Locality）：MapReduce、Spark 等计算框架会尽量把计算任务调度到数据所在的 DataNode 上，让“数据不动、计算动”，从而大幅减少跨机网络传输。一次读取的开销可以拆解为：

图书馆的“数据本地性”就是管理员把热门书搬进自习室，让同学们不出屋就能拿到书；“短路读”则是管理员打开书柜夹层直接递给读者，省去了填单、跑路、递书整套流程。知道书在哪只是第一步，走最短的路拿到书才是读得快的关键。

容错与恢复——巡查、报备与安全演练

图书馆的安全制度一丝不苟：每个房间的书架每 3 秒朝管理员挥一次手（心跳）；每小时提交一份清单，写明书架上每本书的具体位置（块报告）。一旦某个房间超过 10 分钟没挥手，管理员立刻判定它失联，并安排其他房间根据已有副本重新抄写丢失的分册。开馆前还有“安全演练”：管理员只收清单不开放借阅，等确认每本书的副本都够数后才正式开门。

DataNode 通过心跳（Heartbeat）向 NameNode 报告存活状态，默认间隔 3 秒；NameNode 若超过 10 分钟（默认超时参数）没收到某节点心跳，就把它标记为死亡节点。与此同时，每个 DataNode 周期性发送块报告（Block Report），NameNode 将块报告与自己的块映射表对比，一旦发现某个块的当前副本数低于目标副本因子，就会把复制任务加入调度队列，在其他健康节点上补副本：

安全模式（SafeMode）是 NameNode 启动或管理员手动触发的一种保护状态。此期间它只接收心跳与块报告、不对外提供写操作，直到“满足最小副本条件的副本比例”达到阈值（默认 0.999）才自动退出；也可以由管理员执行 leave 命令强制退出。这保证 NameNode 刚恢复时手里已有一份可靠的“目录底账”，避免过早开放服务导致大量读取失败。

正因为有“心跳 + 块报告 + 安全模式”这套组合拳，管理员才能在某个书架的灯突然熄灭后依然从容地告诉读者：“书不会丢，我马上安排在其他房间补抄一份。”HDFS 的高可用，从来不靠某台机器永不宕机，而靠“坏了也能快速恢复”的系统机制。

AI 应用场景

Python 演示

import math  class DataNode:    def __init__(self, node_id, rack_id):        self.node_id = node_id        self.rack_id = rack_id        self.blocks = {}     def write_block(self, block_id, data):        self.blocks[block_id] = data     def read_block(self, block_id):        return self.blocks.get(block_id)  class NameNode:    BLOCK_SIZE = 128     def __init__(self, replication=3):        self.replication = replication        self.datanodes = []        self.block_to_nodes = {}     def register_node(self, node):        self.datanodes.append(node)     def get_blocks_for_file(self, file_size):        num_blocks = math.ceil(file_size / self.BLOCK_SIZE)        return ["b%d" % i for i in range(num_blocks)]     def choose_targets(self, client_rack):        nodes = sorted(self.datanodes,                       key=lambda n: n.rack_id != client_rack)        return nodes[:self.replication]     def allocate_block(self, block_id, client_rack):        targets = self.choose_targets(client_rack)        self.block_to_nodes[block_id] = [n.node_id for n in targets]        return targets     def get_read_locations(self, block_id, client_rack):        nodes = [n for n in self.datanodes                 if n.node_id in self.block_to_nodes[block_id]]        nodes.sort(key=lambda n: n.rack_id != client_rack)        return nodes  def write_file(nn, file_size, data_blocks, client_rack="rack1"):    block_ids = nn.get_blocks_for_file(file_size)    for i, block_id in enumerate(block_ids):        targets = nn.allocate_block(block_id, client_rack)        chunk = data_blocks[i] if i < len(data_blocks) else b"x" * nn.BLOCK_SIZE        for node in targets:            node.write_block(block_id, chunk)    return block_ids  def read_file(nn, block_ids, client_rack="rack1"):    result = []    for block_id in block_ids:        nodes = nn.get_read_locations(block_id, client_rack)        if not nodes:            raise RuntimeError("block %s lost all replicas" % block_id)        best = nodes[0]        result.append(best.read_block(block_id))    return result  if __name__ == "__main__":    nn = NameNode(replication=3)    for i in range(6):        rack = "rack%d" % ((i % 2) + 1)        nn.register_node(DataNode("dn%d" % i, rack))     blocks = write_file(nn, 300, ["data-a", "data-b", "data-c"],                        client_rack="rack1")     print("block -> nodes mapping:")    for b in blocks:        print("  %s -> %s" % (b, nn.block_to_nodes[b]))     got = read_file(nn, blocks, client_rack="rack1")    print("read result:", [g.decode() for g in got])

1. num_blocks = math.ceil(file_size / self.BLOCK_SIZE)按块大小向上取整计算文件分块数，对应正文的块数公式。
2. nodes = sorted(self.datanodes, key=lambda n: n.rack_id != client_rack)模拟机架感知排序，同机架节点排在前面，优先被选为副本目标。
3. self.block_to_nodes[block_id] = [n.node_id for n in targets]记录块到副本节点的映射，模拟 NameNode 的元数据表。
4. for node in targets: node.write_block(block_id, chunk)把数据块写入所有选中目标节点，模拟流水线收尾阶段的多副本落盘。
5. nodes.sort(key=lambda n: n.rack_id != client_rack)读取时按机架距离排序，让客户端优先从同机架副本拿数据。
6. best = nodes[0]取排序后的第一个节点，体现“就近读取”策略。

常见误区

面试题