YARN 命令行是 Web UI 的重要补充，也是日常排查里更稳定的入口。Web 页面适合看整体状态，命令行更适合做三件事：第一，快速确认应用、队列、节点和日志的真实状态；第二，把一次排查过程沉淀成可以复用的脚本；第三，在页面打不开、代理跳

YARN 最容易被误解的地方，是把它当成某一种计算框架的附属品。早期使用 Hadoop 的时候，MapReduce 和集群资源管理绑得太紧，用户提交作业、调度资源、启动任务、查看历史，几乎都围绕 MapReduce 展开。YARN 把这个关

Distributed-Shell 是理解 YARN 应用模型的一个好工具。它本身不复杂：用户提交一个 shell 命令，ApplicationMaster 通过 ResourceManager 申请若干 Container，真正执行命令的

YARN Client 把应用提交给 ResourceManager 以后，真正决定应用如何运行的是 ApplicationMaster。Client 提交的是 ApplicationSubmissionContext，其中包含 AM Co

理解 YARN 应用，第一步不是写 ApplicationMaster，而是先理解客户端到底提交了什么。很多人把 yarn jar 或 hadoop jar 看成一个普通命令：命令发出去，集群就开始跑任务。这个理解太粗。YARN Clien

MapReduce 运行在 YARN 上以后，最容易产生的误解是：YARN 只是把原来的 MapReduce 作业搬到另一套资源管理器上运行。这个理解只对了一半。真正重要的变化，是 MapReduce 不再独占集群调度模型。它退回成 YAR

YARN 的架构把资源管理和应用框架拆开以后，ResourceManager 的核心职责之一就变成了：资源到底应该分给谁。一个共享集群里可能同时有离线 ETL、临时查询、报表任务、算法任务和测试任务。如果所有应用都直接抢同一池资源，先提交的

理解 YARN 架构，不能仅用 ResourceManager、NodeManager、ApplicationMaster、Container 四个组件框图来理解。更有效的理解方式，是分析一个应用从提交到结束的生命周期：客户端把应用交给 R

YARN 管理不只是查看 Web UI 状态。真正的管理对象是 Application 生命周期链路：ResourceManager 接收应用，Scheduler 分配资源，NodeManager 管理 Container 生命周期，App

安装 YARN 不能只理解成“把 ResourceManager 和 NodeManager 启起来”。YARN 仍然依赖 HDFS 提供存储入口，依赖 MapReduce 配置验证计算链路，依赖 JobHistoryServer 和日志聚

1. 为什么要看底层结构Redis 对外暴露的是 String、Hash、List、Set、ZSet 这些数据类型，但底层编码会根据数据规模和内容变化。 比如同样是 String，底层可能是 int、embstr、raw。同样是 Hash，

1. 为什么要讲 Redisson上一篇手写了 Redis 分布式锁，但生产项目里不建议每个团队都维护一套锁实现。分布式锁实现涉及多种工程边界问题，关键复杂度来自锁语义与异常边界处理，比如可重入、续期、释放校验、异常恢复、等待队列、主从切换