大数据：HDFS 读写流程与 NameNode HA 高可用机制详解

一、引言：为什么把读写流程和 HA 放在一起讲

很多 HDFS 教程把“读写流程”和“NameNode HA”分成两章讲，读者学完能背出“客户端先问 NameNode 要 Block 位置”，也能背出“Active/Standby 靠 JournalNode 同步”，但一旦线上出现“写入卡在最后 1%”“切换后新写入的数据丢了”这类问题，两套知识就对不上号了。原因在于，这两件事本来就咬合在一起：写流程的每一步都在修改 NameNode 的内存元数据，而 HA 要保证的正是这份元数据在主备之间不丢、不乱、不双写。

笔者在多个 PB 级集群的运维与调优实践中反复验证过一个判断：HDFS 的绝大多数“疑难杂症”，最终都能归约到“状态一致性”这一个词上。写 Pipeline 的 ACK 队列是状态，租约（Lease）是状态，EditLog 的 txid 是状态，ZKFC 持有的 znode 也是状态。把这些状态的生命周期画在一张图上，读写流程与 HA 就不再是两块知识，而是同一条链上的不同环节。本文就按这条主线组织内容。

本文评述：把“一致性”作为分析主线并非笔者独创，分布式系统领域早有共识（如 Lamport 的逻辑时钟、Raft 的日志复制）。但把它具体落到 HDFS 的读写与 HA 上，能解释不少“文档没写、面试常问、线上常踩”的细节，比如为什么 close 之后还要等一次 complete、为什么切换后要等 Standby 追上 txid 才能继续。

二、HDFS 架构再认识：一条主线与三个角色

2.1 三个角色，各管一段状态

HDFS 的角色划分在官方文档（Hadoop 3.3.x 文档《HDFS Architecture》）里写得很清楚：NameNode 管命名空间与块映射，DataNode 存实际数据块并周期性发送块报告，Client 发起读写。但从“状态”视角看，三者的分工更值得玩味：

角色	持有的关键状态	状态易失性	恢复手段
NameNode	命名空间树、块映射、租约、txid	内存态，重启即失	FsImage + EditLog 回放
DataNode	本地块文件、块校验和、块报告	持久化，但可能损坏	副本重建、块扫描
Client	Pipeline 成员、ACK 队列、租约续约	进程态，崩溃即断	租约超时回收、Pipeline 重建

这张表其实已经暗示了 HA 的设计难点：NameNode 的状态是内存态且高频变化，而 DataNode 的状态是持久化但可重建的。所以 HA 的重点必然落在 NameNode 上，DataNode 的高可用更多靠副本机制而非主备切换。

2.2 一条主线：txid 是全局的“时间刻度”

HDFS 里有一个不起眼但极其关键的整数：transaction id（txid）。每一次命名空间修改（创建文件、追加块、重命名、删除）都会让 txid 自增。EditLog 里的每条记录都带着 txid，JournalNode 上的日志按 txid 排序，Standby 追赶 Active 时比较的也是 txid。笔者习惯把它类比成数据库的 LSN（Log Sequence Number）——只要 txid 对齐了，主备状态就对齐了；txid 对不齐，任何“看起来正常”的切换都是危险的。

理解了这一点，后面 QJM 的“多数派写入”、ZKFC 的“先 fencing 再切换”、Observer 的“只读追赶”就都能顺理成章地推导出来，而不需要死记硬背。

三、写流程全链路拆解：从 create 到 close

3.1 第一步：create 请求与租约授予

客户端调用 FileSystem.create() 时，RPC 到达 Active NameNode。NameNode 做三件事：检查路径是否存在、检查父目录权限、在命名空间树里插入一个 INodeFile 并标记为“正在写入”（under construction）。同时，NameNode 给这个客户端发放一个租约（Lease），租约里记录了 holder（客户端标识）和 lastUpdate 时间戳。

租约机制常被误解为“锁”，其实它更像“心跳凭证”。租约不阻止别人读，只阻止别人对同一文件做写操作，并且靠客户端定期 renew 来证明自己还活着。如果客户端崩溃，NameNode 在租约软超时（默认 60 秒，由 dfs.namenode.lease-recheck-interval 等参数控制）后回收租约，并触发文件恢复（Lease Recovery），把最后一个块补齐或截断。

本文评述：很多资料把租约说成“写锁”，这在工程上会误导排障。笔者见过有团队因为误解，在客户端长时间 GC 卡顿时误以为是“锁没释放”，实际上只是租约没续上。正确的理解是：租约是“活性证明”，超时回收是设计内的正常路径，不是异常。

3.2 第二步：addBlock 与 Pipeline 组建

第一个块写满（默认 128MB，由 dfs.blocksize 控制）或客户端 flush 时，客户端向 NameNode 请求 addBlock。NameNode 依据机架感知（rack awareness）策略选择一组 DataNode，返回一个 LocatedBlock，包含块 ID、副本位置列表和版本号。

机架感知的默认实现是 ScriptBasedMapping 或 TableMapping，策略是：第一副本放本地（若客户端在集群内），第二副本放另一机架，第三副本放第二副本同机架的另一节点。这个策略在《HDFS Architecture》中有描述，Hadoop 3.x 未做本质改动。

Pipeline 组建是逐级建立的：Client 连 DN1，DN1 连 DN2，DN2 连 DN3。每一级都通过 DataTransferProtocol 的 writeBlock 指令完成，携带 pipeline 成员列表和下游地址。建立完成后，ACK 沿反方向逐级回传。

3.3 第三步：数据包传输与 ACK 队列

客户端把数据切成 packet（默认 64KB，含数据与校验和），放入发送队列。每个 packet 有一个 seqno，DN 收到后写入本地磁盘并转发下游，下游 ACK 回传后 DN 再把 ACK 往上游传。客户端维护一个未确认队列（ackQueue），只有收到 ACK 的 packet 才从队列移除。

这里有个容易被忽略的细节：HDFS 的写入不是“写完即成功”，而是“ACK 回来才算成功”。所以当客户端看到“写入卡在 99%”时，往往是最后一个 packet 的 ACK 没回来，问题可能出在任意一个 DN 的磁盘 IO 或网络。排查时应该看 DN 的 DataXceiver 线程栈和 dfs.datanode.slow.io.warning.threshold.ms 相关日志，而不是只盯着 NameNode。

3.4 第四步：Pipeline 故障恢复

如果某个 DN 故障，客户端会收到 PipelineAck 中的错误标记，触发 updatePipeline：从 pipeline 中剔除故障节点，用剩余节点重建 pipeline，并把故障节点上未确认的 packet 重新发送。同时通知 NameNode 做块副本的重新复制。

这个过程在 Hadoop 3.x 中有优化：dfs.client.block.write.replace-datanode-on-failure.policy 参数控制是否补充新节点，默认 DEFAULT 策略会在副本数低于阈值时补充。笔者建议在跨机架部署时显式设置为 ALWAYS，代价是切换时多一次 RPC，收益是机架级容错更稳。

3.5 第五步：close 与 complete

数据写完后，客户端调用 close()，向 NameNode 发送 complete 请求。NameNode 检查该文件所有块是否都达到最小副本数（默认 1，由 dfs.namenode.replication.min 控制），满足则把 INode 标记为 closed，释放租约。

如果此时副本数不足，complete 会返回 false，客户端需要重试。这就是“写完文件但读不到”的常见原因之一：文件在命名空间里存在，但处于 under construction 状态，其他客户端读到的可能是空文件或部分数据。生产上建议在 close 后做一次 fsck 校验，尤其是跨机房写入场景。

四、读流程全链路拆解：从 open 到短路读

4.1 open 与块位置获取

客户端调用 open() 时，NameNode 返回该文件所有块的 LocatedBlock 列表，按块偏移排序。客户端并不一次性拉取全部块位置，而是按需分批获取（默认每次 10 个块，由 dfs.client.read.prefetch.size 控制），这对大文件读取很关键。

节点选择遵循“就近原则”：优先本地 DN，其次同机架，最后跨机架。如果读取失败，客户端会标记该 DN 为 dead，换下一个副本，并在一定次数后重新向 NameNode 请求最新位置。

4.2 短路读（Short-Circuit Read）

当客户端与目标 DN 在同一节点时，HDFS 支持短路读：客户端通过 DomainSocket 直接读取本地块文件，绕过 TCP 栈。这需要 dfs.client.read.shortcircuit 开启，并配置 dfs.domain.socket.path。

短路读在 Spark、HBase 这类计算与存储混部的场景收益明显。根据 Hadoop 官方文档的说明，短路读可减少一次数据拷贝，但需要客户端与 DN 同用户或配置 dfs.client.read.shortcircuit.skip.checksum 等权限细节。笔者认为，短路读的收益在 SSD 集群上不如 HDD 集群明显，因为瓶颈从网络转移到了磁盘本身，部署前应做基准测试而非盲目开启。

4.3 零拷贝与 sendfile

DN 向客户端发送数据时，Hadoop 3.x 支持 transferTo（基于 sendfile 系统调用）实现零拷贝，减少用户态与内核态之间的数据搬运。相关配置为 dfs.datanode.transfer.socket.send.buffer.size 与 dfs.client.use.datanode.hostname。

需要提醒的是，零拷贝对校验和验证有影响：开启后校验和仍在 DN 侧计算，但客户端不再重复校验。这在可信内网是合理的取舍，在跨信任域场景应谨慎。

五、NameNode HA 的核心问题：状态如何复制

5.1 为什么不能简单“主从同步内存”

最朴素的想法是：Active 每次改内存，就同步一份给 Standby。但 HDFS 的命名空间可能有数亿个 INode，全量同步不现实；增量同步又面临“同步到一半 Active 挂了怎么办”的问题。更麻烦的是，内存同步无法保证 Standby 在切换后能独立恢复——它需要一份可持久化、可回放的日志。

所以 HDFS 选择了“日志复制”路线：Active 把每次修改写成 EditLog，Standby 拉取并回放。这与数据库的 WAL（Write-Ahead Log）思路一致，本质是用“顺序日志”换“随机状态”的可复制性。

5.2 从 SecondaryNameNode 到 QJM 的演进

Hadoop 1.x 时代的 SecondaryNameNode 并不是热备，它只负责定期合并 FsImage 与 EditLog（checkpoint），不能接管服务。Hadoop 2.x 引入 QJM（Quorum Journal Manager）后，才有了真正的 Active/Standby 双机热备。

机制	引入版本	是否支持热备	主要局限
SecondaryNameNode	Hadoop 1.x	否	仅 checkpoint，不能接管
NFS-based HA	Hadoop 2.0	是	依赖 NFS，单点风险
QJM	Hadoop 2.0+	是	需奇数个 JournalNode

本文评述：NFS-based HA 在部分老资料里仍被提及，但笔者认为它在生产上已不具竞争力——NFS 本身是单点，且性能受网络存储限制。QJM 用“多数派日志”换掉了“共享存储单点”，是更符合分布式系统设计原则的方案。

六、QJM 共享编辑日志机制详解

6.1 架构：Active、Standby 与 JournalNode 集群

QJM 的核心是一个由奇数个（通常 3 或 5 个）JournalNode 组成的集群。Active NameNode 写 EditLog 时，不是写本地，而是并行写到多个 JournalNode；只要多数派（quorum）确认，写入即成功。Standby 则从 JournalNode 拉取日志并回放。

这里的关键设计是“多数派”而非“全部”：3 个 JN 允许 1 个故障，5 个允许 2 个故障，这与 Raft 的 quorum 思想一致。但 HDFS 并未直接采用 Raft 的选举机制，而是把“谁是 Active”交给 ZKFC 决定，QJM 只负责日志的多数派写入与读取。

6.2 Epoch 与 fencing：防止“双主写日志”

QJM 里有一个叫 epoch 的整数。每次 Active 切换，新的 Active 会向 JournalNode 申请一个更大的 epoch。JournalNode 只接受 epoch 不小于当前值的写入请求。这相当于给每次“任期”打上编号，旧 Active 即使还活着，它的写入也会因为 epoch 落后而被拒绝。

这个机制在 Hadoop 官方文档《HDFS High Availability Using the Quorum Journal Manager》中有描述。笔者认为，epoch 机制是 QJM 最精妙的设计之一：它把“防双写”从“依赖网络分区检测”降级为“依赖单调递增的编号”，大大降低了误判概率。

6.3 日志同步的三种状态

Standby 与 Active 之间的同步有三种状态：

• 同步中（in-sync）：Standby 的 txid 与 Active 差距在阈值内，可随时切换。
• 滞后（lagging）：差距超过阈值，切换前需要等待追赶，否则可能丢数据。
• 失联（disconnected）：Standby 无法拉取日志，通常意味着 JN 集群或网络有问题。

运维上应重点关注 JournalNode 的 JournalNodeRpcServer 日志和 NameNode 的 EditLogTailer 线程状态。如果 Standby 长期 lagging，切换时会出现“切换成功但数据回退”的假象。

七、ZKFC、fencing 与脑裂防护

7.1 ZKFC 的职责

ZKFC（ZKFailoverController）是运行在 NameNode 节点上的独立进程，它做三件事：监控本地 NameNode 健康状态、在 ZooKeeper 中竞争 Active 锁、在切换时执行 fencing。ZooKeeper 在这里扮演“仲裁者”角色，通过临时节点（ephemeral znode）实现“谁持有锁谁是 Active”。

健康检查包括：NameNode 进程是否存活、RPC 端口是否可连、是否处于安全模式等。任一检查失败，ZKFC 会主动放弃 Active 锁，触发切换。

7.2 fencing：切换前的“保险丝”

fencing 是 HA 里最容易被忽视、也最危险的环节。它的目的是：在 Standby 升主之前，确保旧 Active 已经“死透”，不会继续写日志。HDFS 支持多种 fencing 方式：

fencing 方式	原理	适用场景	风险
sshfence	SSH 到旧 Active 执行 kill	内网、SSH 可达	SSH 不通则失败
shellfence	执行自定义脚本	云环境、需调 API	脚本健壮性依赖高
QJM epoch	日志层拒绝旧 epoch 写入	默认启用	仅防写日志，不防读

笔者的经验是：sshfence 必须配置，且要配合 QJM epoch 双保险。只靠 epoch 不配 sshfence，旧 Active 仍可能对外提供读服务，造成“读旧数据”的一致性问题；只配 sshfence 不依赖 epoch，则在 SSH 抖动时切换会失败。两者叠加才是工程上稳妥的做法。

本文评述：网上不少文章把“脑裂”描述成“两个 Active 同时写”，但在 QJM 下这种情况几乎不可能发生（epoch 会拒绝）。真正需要担心的是“旧 Active 还能读、新 Active 已经写”的读写不一致，以及 fencing 失败导致的切换卡住。排障时应先看 ZKFC 日志里的 fencing 结果，而不是笼统地说“脑裂”。

八、故障切换实操：从模拟到验证

8.1 手工切换（优雅切换）

在维护窗口内，推荐使用 hdfs haadmin -failover --forcefence --forceactive nn1 nn2 做手工切换。参数含义：--forcefence 强制 fencing，--forceactive 强制目标升主。生产上建议先确认 Standby 的 txid 已追上，再执行切换。

# 查看 HA 状态
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

# 查看 Standby 是否追上（对比 txid）
hdfs dfsadmin -report | grep -i "txid\|edit"

# 优雅切换
hdfs haadmin -failover --forcefence --forceactive nn1 nn2

8.2 模拟故障切换

验证 HA 是否真正生效，最直接的方式是 kill 掉 Active 的 NameNode 进程，观察 ZKFC 是否在秒级内完成切换。建议在测试集群做以下步骤：

1. 记录当前 Active 的 txid 和若干文件的 checksum。
2. kill -9 Active NameNode 进程。
3. 观察 ZKFC 日志，确认 fencing 执行、Standby 升主。
4. 切换后重新读取文件，比对 checksum，确认无数据丢失。
5. 重启原 Active，确认它自动以 Standby 身份加入并追上 txid。

这套流程在笔者的实践中暴露过不少配置问题，比如 ha.zookeeper.quorum 写错、dfs.ha.fencing.methods 未配置导致切换卡住。建议把“模拟切换”纳入日常演练，每季度至少一次，而不是等真出事才验证。

8.3 切换后的数据一致性校验

切换完成后，建议执行 hdfs fsck / -files -blocks -locations 检查是否有块缺失或副本不足。对于关键目录，可用 hdfs dfs -checksum 比对切换前后的校验和。

九、Hadoop 3.x 的演进：纠删码、Observer 与 Federation

9.1 纠删码（Erasure Coding）对读写流程的影响

Hadoop 3.0 引入纠删码，用 EC 策略（如 RS-6-3）替代三副本，存储开销从 3x 降到 1.5x。但 EC 改变了读写流程：写时客户端要计算校验块并写入多个 DataNode，读时需要从多个节点读取数据块和校验块进行解码。

根据 Hadoop 官方文档《Erasure Coding》的说明，EC 适合冷数据、大文件，不适合小文件和高频修改场景。笔者认为，EC 的引入让“读写流程”与“HA”的耦合更紧：EC 文件的恢复依赖 NameNode 的块映射准确性，一旦 HA 切换时元数据不一致，EC 解码可能失败，影响面比三副本更大。

9.2 Observer NameNode：读扩展的新思路

Hadoop 2.6 引入 Observer NameNode，它像 Standby 一样拉取 EditLog，但可以对外提供读服务（不参与写）。这缓解了“单 Active 读压力大”的问题。配置上需要 dfs.ha.tail-edits.period 和 dfs.namenode.observe-only 相关参数配合。

Observer 的代价是“读可能滞后”：它拉取日志有延迟，客户端可能读到稍旧的状态。对一致性要求高的场景（如元数据强一致读），仍需走 Active。

9.3 Router-based Federation

Hadoop 3.x 的 RBF（Router-based Federation）在多个 NameNode 之上加一层 Router，客户端通过 Router 访问不同子集群。这解决了“单 NameNode 元数据容量上限”的问题，但也引入了新的状态一致性问题：Router 的挂载表（mount table）需要与各子集群同步。

笔者认为，RBF 是 HDFS 从“单集群 HA”走向“多集群联邦”的关键一步，但它并没有替代 HA，而是把 HA 的粒度从“单 NameNode”扩展到“子集群”。运维复杂度显著上升，中小规模集群不建议过早引入。

十、性能调优与常见故障排查清单

10.1 关键参数速查

参数	默认值	调优建议	影响面
dfs.blocksize	128MB	大文件可调至 256MB	读写吞吐、元数据量
dfs.namenode.handler.count	10	按并发客户端数调整	RPC 并发能力
dfs.datanode.max.transfer.threads	4096	高并发场景上调	DN 并发传输
dfs.ha.tail-edits.period	60s	缩短可降低切换延迟	Standby 追赶速度

10.2 常见故障与排查路径

• 写入卡在最后 1%：先看 DN 的 DataXceiver 线程是否阻塞，再看磁盘 IO 是否打满，最后看网络丢包。
• 切换后读不到新数据：检查 Standby 是否 lagging，切换前是否等待 txid 追上。
• ZKFC 反复切换：检查 ZooKeeper 会话超时、网络抖动、NameNode GC 停顿。
• fencing 卡住：检查 SSH 免密、脚本权限、目标进程是否真的被杀掉。

更多排查思路可参考 Apache Hadoop 官方文档的 HDFS HA with QJM 与 HDFS 设计文档。视频教程方面，可参考 YouTube 上的 Hadoop 官方频道与 Cloudera 的技术分享，以及 B 站上一些运维实战向的 HDFS 排障系列。

十一、前沿预判：从 HDFS HA 到云原生存储的一致性思路

HDFS 的 HA 设计诞生于“物理机 + 内网”的时代，它的假设是：节点会坏、网络会分区、但磁盘是可靠的。云原生时代，这些假设正在变化：对象存储（如 S3、OSS）把持久性外包给了云厂商，计算与存储分离成为主流，Kubernetes 上的 StatefulSet 让“节点身份”变得动态。

笔者认为，HDFS HA 的“日志复制 + 多数派 + fencing”三件套，在云原生存储中依然有借鉴价值，但形态会变：日志复制可能被替换为“基于对象存储的 WAL”，多数派可能被替换为“云厂商的强一致存储”，fencing 可能被替换为“K8s 的 Pod 生命周期管理”。不变的是那条主线——状态一致性必须由某种“单调递增的编号 + 多数派确认”来保证。

近三年的研究也在往这个方向走。例如 OSDI、FAST 等会议上有不少关于“分离式存储一致性”的工作，国内也有团队在对象存储网关、湖仓一体场景下讨论 HDFS 兼容层的一致性设计。这些工作尚未形成统一标准，但趋势是明确的：HA 不再是“单集群双机热备”，而是“跨层、跨域的一致性协议”。

十二、结语

回到开头那条主线：HDFS 的读写流程与 NameNode HA，本质上都在回答“状态如何被安全地修改、复制与恢复”。写流程用 Pipeline ACK 保证“数据写成功”，HA 用 QJM + ZKFC + fencing 保证“元数据不丢不乱”。把这两件事放在一张状态图上看，很多“文档没写清楚”的细节就有了合理的解释。

工程上，笔者建议把“模拟切换演练”和“txid 对齐检查”纳入日常运维，而不是等故障发生才验证。技术演进上，Hadoop 3.x 的 EC、Observer、RBF 都在扩展 HDFS 的边界，但底层的一致性思路没有变。理解了这条主线，面对新版本、新场景时，就不至于被参数和名词淹没。

主要参考文献