解读

1. 场景定位：国内 Hadoop 集群规模普遍在 2000–5000 节点，日均 RPC 调用量 30–50 万/小时，10 秒排队意味着 P99 突然劣化，已触发 SLA 红线（通常 P99<1 s）。
2. 面试官想听的不仅是“用哪个工具”，而是“如何闭环”：复现→分层拆解→数据自证→给出优化方案→验证有效。
3. 区分“handler 线程不够”与“锁竞争”是高频考点，因为二者优化方向相反：前者横向扩容即可，后者必须纵向改代码或拆锁。

知识点

1. Hadoop RPC 线程模型
   • Reader→CallQueue→Handler（默认 10 线程）→FSNamesystem 锁（全局写锁 + 分段读锁）。
2. 排队指标
   • rpc.queue.time：CallQueue 停留时间。
   • rpc.processing.time：Handler 纯 CPU 时间。
   • rpc.lock.wait.time：FSNamesystem 锁等待（Hadoop 3.x 后内置）。
3. 诊断工具
   • jstack 连续 3 次 5 s 间隔，统计 BLOCKED 状态栈比例。
   • perf + FlameGraph 看用户态锁热点。
   • Arthas：thread –state BLOCKED、trace FSNamesystem.writeLock。
   • bcc/eBPF：offcputime 统计阻塞时间。
4. 国内可落地的“灰度”手段
   • 在 NameNode 启动参数注入 -Dhadoop.rpc.handler.count=20 做 5 min 热实验，对比 queue.time 是否线性下降。
   • 用 Hadoop 提供的 Metrics2 + Prometheus + Grafana，把 rpc.queue.time 与 rpc.lock.wait.time 做双轴图，一眼看出谁占大头。
5. 锁优化常见套路
   • 拆锁：把 FSEditLog 锁拆到独立线程（HDFS-9712）。
   • 无锁化：getFileInfo 走 ReentrantReadWriteLock 读锁，避免阻塞写。
   • 批量合并：把 1000 个 mkdir 合成一次 edit log 提交。

答案

回答采用“四步法”，总时长控制在 3 分钟，既体现深度又方便面试官插话追问。

第一步：秒级确认现象
在 Grafana 中打开 NameNode RPC Dashboard，发现 rpc.queue.time 中位数从 50 ms 跳涨到 10 s，而 rpc.processing.time 仍保持 80 ms，说明“排队在前，处理在后”，先把矛头指向 Handler 或 CallQueue。

第二步：30 秒内做热实验
通过 Ansible 推送滚动重启脚本，把其中一台 NameNode 的 hadoop.rpc.handler.count 从 10 提到 30，同时保持客户端流量不变。

• 若 queue.time 立刻降到 200 ms，说明瓶颈是 Handler 数量，结论：线程池饥饿。
• 若 queue.time 几乎不变，继续第三步。

第三步：2 分钟内锁竞争定位

1. 在故障节点连续执行
   jstack -l <pid> > (hostname)_(date +%s).txt
   三次采样后，用自建脚本统计 BLOCKED 状态线程占比，若 >40% 线程卡在
   FSNamesystem.writeLock.lock()
   即可初步判定为锁竞争。
2. 用 Arthas 进一步量化
   trace -j org.apache.hadoop.hdfs.server.namenode.FSNamesystem writeLock
   拿到“锁等待总耗时 / 调用次数”，若平均等待 8 s，与排队 10 s 基本吻合，证据链闭环。
3. 若环境允许，用 eBPF 工具 offcputime 把阻塞栈做成火焰图，向面试官展示“锁热点占 75% 宽度”，可视化最有说服力。

第四步：给出可落地的优化方案

1. 短期：把写锁耗时最高的 listStatus + getFileInfo 改为读写锁；对 mkdir、delete 做批量合并，减少锁抢占次数。
2. 中期：升级 HDFS 3.3.4，打开 hdfs-site.xml 中的 dfs.namenode.fslock.fair=false，减少线程唤醒开销。
3. 长期：推动业务改造，把 1 k 并发的小文件 create 改为 SequenceFile 一次性写，降低 70% 写锁压力。
4. 回归：在 nightly 性能基线里增加“锁等待 / RPC 排队”双指标，一旦比例 >0.6 自动告警，防止回退。

拓展思考

1. 如果热实验后 Handler 线程数已翻倍，但 CPU sys 利用率仍 <30%，queue.time 不降，即可排除 CPU 饱和，进一步排除“Handler 忙”而实锤“锁”。
2. 国内金融公司常把 NameNode 放在 KVM 虚拟机，vCPU 抢占也会导致排队，需把 steal time 指标一并拉通，避免误判成锁竞争。
3. 对读多写少场景，可引入 Observer NameNode（3.x 正式版），把读 RPC 分流到 Observer，写锁竞争自然下降，面试中抛出“读写分离”体现架构视野。