讲讲 ResourceManager（RM）的主要职责以及它内部的核心组件

知识点图片

在 Apache Hadoop YARN 架构中，ResourceManager (RM) 是整个集群的“大脑”和最高权力中心。它是全局的资源管理器，负责整个系统的资源分配和应用程序管理。

下面我将详细讲解 ResourceManager 的主要职责以及它内部的核心组件。

一、 ResourceManager 的主要职责

ResourceManager 的核心职责可以概括为以下四个方面：

全局资源管理与调度 (Resource Management & Scheduling)
- 掌握全局资源： RM 知道整个集群有多少计算资源（内存、CPU等），并时刻跟踪这些资源的使用情况和空闲情况。
- 资源分配： 根据各种调度策略（如容量调度 Capacity Scheduler、公平调度 Fair Scheduler），将资源以 Container（容器） 的形式分配给各个应用程序。
- 解决竞争： 当多个应用程序同时申请资源时，RM 负责仲裁和分配优先级，确保资源被合理利用，防止某些队列被饿死。
应用程序生命周期管理 (Application Management)
- 接收作业提交： 接收客户端提交的各类计算任务（如 MapReduce、Spark、Flink 等）。
- 启动与监控 AM： 为每个提交的应用程序在集群中挑选一个节点，分配第一个 Container，并在这个 Container 中启动该应用的 ApplicationMaster (AM)。
- 故障恢复： 持续监控 AM 的健康状态。如果 AM 崩溃或所在节点宕机，RM 负责在其他节点上重新启动一个新的 AM。
节点管理 (Node Management)
- 处理 NM 心跳： 接收集群中所有 NodeManager (NM) 发来的心跳信息。心跳信息包含了节点的健康状况、可用资源、以及正在运行的 Container 状态。
- 节点黑名单/白名单： 识别出故障节点或资源耗尽的节点，将其标记为不可用，不再向其分配新任务。
安全与权限控制 (Security & ACLs)
- 验证用户提交应用程序、杀死应用程序等操作的权限。
- 管理集群中的各种安全令牌（Tokens），确保组件之间（如 RM 与 NM、RM 与 AM）的安全通信。

二、 ResourceManager 的内部核心组件

为了实现上述复杂的职责，ResourceManager 内部被划分为多个高内聚的组件。最核心的两个组件是 ApplicationsManager (ASM) 和 ResourceScheduler。

以下是详细的内部组件拆解：

1. 核心调度与管理模块

ApplicationsManager (ASM - 应用程序管理器)
- 职责： 专门负责管理所有应用程序的生命周期。
- 工作内容： 接收客户端的提交请求；与调度器协商获取第一个 Container 来启动 ApplicationMaster；监控 AM 的运行状态（通过 AMLivelinessMonitor）；在 AM 失败时对其进行重启。
- 注意区分：ASM 是 RM 内部的组件，而 AM 是运行在工作节点上的应用管理者。
ResourceScheduler (资源调度器)
- 职责： 纯粹的资源分配器。
- 工作内容： 根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。它不负责监控应用程序的状态，也不负责重启失败的任务。
- 可插拔性： 它是可插拔的，Hadoop 提供了三种经典实现：FIFO Scheduler（先进先出调度器）、Capacity Scheduler（容量调度器，YARN 默认）、Fair Scheduler（公平调度器）。

2. RPC 服务交互模块 (处理不同角色的通信)

ClientRMService (客户端交互服务)
- 处理来自普通客户端的 RPC 请求，例如：提交应用程序、终止应用程序、查询应用程序的状态、查询集群资源信息等。
AdminService (管理员交互服务)
- 专门处理管理员的 RPC 请求，属于高权限接口。例如：刷新队列配置（Refresh Queues）、刷新节点列表（加入/移除节点）、更新 ACL（访问控制列表）等。
ResourceTrackerService (节点交互服务)
- 专门处理来自 NodeManager 的 RPC 请求。
- 处理 NM 的注册，以及接收 NM 每秒发来的心跳汇报（包含节点存活状态、Container 运行状态）。
ApplicationMasterService (AM交互服务)
- 处理来自各个 ApplicationMaster 的 RPC 请求。
- AM 通过这个组件向 RM 注册自己、周期性地申请资源（资源请求列表）、汇报任务运行进度，并在应用结束时进行注销。

3. 状态监控与容错模块

NMLivelinessMonitor (节点存活监控器)
- 周期性检查 NodeManager 是否还活着。如果某个 NM 长时间（默认10分钟）没有发送心跳，它会将其标记为 DEAD，并通知调度器回收该节点上的所有资源。
AMLivelinessMonitor (AM存活监控器)
- 周期性检查 ApplicationMaster 的心跳。如果 AM 超时未汇报，RM 会认为该 AM 宕机，并触发重启流程。
RMStateStore (RM状态存储器)
- 职责： 负责 RM 的高可用（HA）和故障恢复。
- 工作内容： 它将 RM 的核心内部状态（如应用程序信息、凭证、队列信息）持久化存储到外部系统（如 ZooKeeper、HDFS 或 LevelDB）。当 Active RM 宕机，Standby RM 接管时，可以通过 RMStateStore 恢复之前的状态，做到对用户透明。

4. 安全模块 (Secret Managers)

RM 内部包含多个密钥管理器（如 RMDelegationTokenSecretManager, AMRMTokenSecretManager, NMTokenSecretManager）。它们负责生成、验证和管理各种 Token，确保 Hadoop 集群在开启 Kerberos 或安全模式下，各组件调用的合法性。

总结：组件如何协同工作？（以提交流程为例）

通过一个简单的作业提交流程，可以把这些组件串联起来：

客户端通过 ClientRMService 提交一个 Job。
ApplicationsManager (ASM) 接收该 Job，并向 ResourceScheduler 申请一个 Container 用来运行该 Job 的 ApplicationMaster。
ResourceScheduler 根据 NM 通过 ResourceTrackerService 汇报的资源情况，分配一个 Container。
ASM 找到对应的 NM 启动 ApplicationMaster。
AM 启动后，通过 ApplicationMasterService 向 RM 注册，并继续申请运行具体任务（如 Map/Reduce task）的资源。
整个过程中，AMLivelinessMonitor 和 NMLivelinessMonitor 在后台持续监控节点和 AM 的健康。

播面