核心是验证业务在dfs故障转移中是否丢数据、读错文件、卡请求或触发熔断；需聚焦客户端请求流，模拟真实负载，监控三层指标，并重点检验正在写入文件的一致性。
测试 dfs 故障转移时的业务连续性，核心不是“看切换是否成功”，而是验证“业务在切换过程中有没有丢数据、读错文件、卡住请求、或触发上游熔断”。真实生产环境里，一次 2.3 秒的 namenode 切换，可能让上游 spark 任务因 rpc 超时而重试三次，最终失败——这不是 ha 架构的问题，是业务与 dfs 之间的超时、重试、缓存策略没对齐。
明确故障转移边界：先知道“切的是什么”
DFS 的故障转移不是整套系统重启，而是特定角色的状态迁移。以 HDFS HA 为例：
- Active NameNode 宕机 → Standby 升为 Active，接管 RPC 请求入口
- JournalNode 集群保持运行，EditLog 持续写入，不参与切换
- DataNode 不感知切换，只按新 Active 的指令上报块报告、执行复制
- ZKFC 在 ZooKeeper 中释放旧 Active 的临时节点，并帮新节点注册为 Active
所以测试必须聚焦在“客户端请求流”上：从 FileSystem API 发起读写，到收到响应或异常，全程链路不能断、不能错、不能显著延迟。
设计贴近真实的业务压测场景
避免用 hdfs dfs -ls 这类低频命令测试。应模拟实际负载特征：
- 小文件高频写入（如日志归集）：每秒 5k+ create/write/close，观察文件是否重复创建、校验码是否一致、fsync 是否阻塞
- 大文件顺序读（如训练数据加载）：10GB+ 文件持续 read()，切换瞬间检查是否出现 EOFException 或跳字节读错
- 元数据密集操作（如 Hive 表分区刷新）：并发 listStatus + exists + getFileInfo，验证路径是否存在、修改时间是否回滚、权限是否丢失
关键点：所有操作必须带唯一 trace ID 或文件名标记，切换后逐条比对结果，而不是只看“没报错”。
监控与断言要覆盖三个层面
光看 WebUI 或日志“Failover completed”远远不够。需同步采集并交叉验证：
- 客户端层：记录每次调用耗时、返回码、异常堆栈；统计切换窗口内失败率、重试次数、平均延迟毛刺
- NameNode 层：抓取 Active/Standby 的 RPC 队列堆积深度、EditLog apply lag（ms）、ZKFC 的 healthCheck 成功率
- DataNode 层：确认块报告（block report）是否在切换后 30s 内完成全量上报；检查是否有 transient replica mismatch 告警
例如：若客户端 98% 请求在 200ms 内返回，但切换期间突增到 3.2s 且重试率达 17%，就说明 RPC 超时设置（如 dfs.client.failover.sleep.base.millis）与实际切换耗时不匹配。
验证一致性边界：重点查“正在写的文件”
最易出问题的是故障发生时正处于写入中间状态的文件。测试中必须构造这类 case：
- 启动一个流式写入（FSDataOutputStream），写入 200MB 后，在 flush() 后、close() 前强制 kill Active NameNode
- 等待 Standby 切换完成，立刻用另一个客户端 open() 该文件并 seek(0) 读前 64KB
- 比对内容哈希：应与写入端本地缓存一致；若读出乱码或提前 EOF，说明 edit log 截断或租约恢复异常
这个测试直击 DFS 元数据状态机的核心——租约（lease）是否在切换中被正确继承和续期，而不是靠“事后修复”。
