在 Hadoop YARN 架构中，ApplicationMaster（AM）负责单个应用程序的资源申请、任务调度和状态监控。如果 ApplicationMaster 发生宕机，YARN 提供了一套完善的容错机制来确保作业能够恢复并继续执行。

整个容错和恢复过程可以分为以下几个关键步骤：

1. 故障检测 (心跳机制)

• 心跳维持：在正常运行期间，AM 会周期性地向 ResourceManager (RM) 发送心跳信息（汇报进度、申请资源等）。
• 超时判定：RM 内部有一个 AM Liveness Monitor（AM 活跃度监控器）。如果 RM 在规定的超时时间内（由参数 yarn.am.liveness-monitor.expiry-interval-ms 控制，默认通常为 10 分钟）没有收到 AM 的心跳，就会判定该 AM 已经宕机。

2. 状态清理与旧容器销毁

• 一旦确认 AM 宕机，RM 会将该 AM 标记为失败状态。
• RM 会通知运行该 AM 的 NodeManager (NM) 清理掉这个失败的 AM 容器（Container），释放其占用的资源。

3. AM 的重新启动

• 重试次数限制：RM 不会无限次地重启 AM。YARN 允许配置 AM 的最大重试次数（参数 yarn.resourcemanager.am.max-attempts，默认值通常为 2）。只有当重试次数未达到上限时，RM 才会尝试重启它。如果超过最大次数限制，整个应用程序将被标记为失败（FAILED）。
• 重新分配资源：RM 的调度器会像最初启动该应用一样，重新在集群中寻找一台合适的 NodeManager，分配一个新的 Container，并在其中启动一个全新的 ApplicationMaster 实例。

4. 任务（Container）状态的恢复 (核心机制)

这里有一个非常重要的演进过程：

• 旧版本（Hadoop 2.4 之前）：如果 AM 宕机，它所管理的所有正在运行的任务（Containers）也会被强行杀死。新的 AM 启动后，必须从头开始重新运行所有任务。这对于长时间运行的作业（如大型 MapReduce 或流处理）来说代价极其高昂。
• 新版本（Hadoop 2.4 及以后）—— AM Work-Preserving Restart（保持工作的 AM 重启）：
  • YARN 引入了 keep-containers-across-application-attempts 机制。
  • 当 AM 宕机时，NodeManager 不会立刻杀死该 AM 申请的、正在执行具体任务的 Worker 容器。
  • 当新的 AM 启动并向 RM 注册时，RM 会把当前属于该应用程序且正在运行的 Container 列表以及它们的节点信息发送给新的 AM。
  • 新的 AM 获取这些信息后，会重新与这些 NodeManager 建立联系，无缝接管这些正在运行的任务，从而避免了重复计算。

5. 应用程序业务状态的恢复（依赖于计算框架）

YARN 作为资源管理系统，只负责资源和容器层面的恢复。至于应用程序内部的计算逻辑进度（哪些任务做完了，哪些没做完），需要由具体的计算框架（如 MapReduce、Spark、Flink）自己来实现：

• MapReduce (MRAppMaster)：MR 的 AM 会将作业的运行状态和历史记录持久化写入到 HDFS 中（JobHistory）。当新的 MRAppMaster 启动后，它会去 HDFS 读取这些日志，恢复作业的内部状态。已经成功完成的 Map/Reduce 任务不需要重跑，只需接管正在运行的任务和分配未完成的任务。
• Apache Spark：如果 Spark 运行在 YARN Cluster 模式下，Driver 就是 AM。Driver 宕机重启后，如果没有开启特定的 Checkpoint 机制，通常会导致作业状态丢失，RDD 需要重新计算。对于 Spark Streaming/Structured Streaming，可以通过配合 HDFS Checkpoint 或 Write-Ahead Logs (WAL) 来恢复进度。
• Apache Flink：Flink 的 JobManager 作为 AM 运行。如果 JobManager 宕机，新的 JobManager 启动后，会依赖 ZooKeeper/ETCD 选主，并从 HDFS 中读取最新的 Checkpoint/Savepoint 状态文件，从而恢复 Flink 任务的精确状态（Exactly-Once），并通知 TaskManager 恢复执行。

总结

当 YARN 中的 ApplicationMaster 宕机时，YARN 会通过心跳超时发现故障，检查重试次数，在另一台节点重启一个新的 AM，并通过 Work-Preserving 机制把仍在运行的底层任务移交给新 AM。而作业进度的断点续传，则依赖于具体计算框架的状态持久化机制（如写 HDFS）。