Flink JobManager
Flink JobManager 是集群的控制核心，其内部由多个专业化组件协同工作，每个组件承担特定职责，共同完成作业的提交、调度、监控和容错。深入理解这些组件的功能和交互逻辑，是掌握 Flink 作业运行机制的关键。
一、JobManager 核心组件及功能
JobManager 的内部组件按职责可分为 “接收与分发”“资源管理”“作业专属管理” 三大类，具体如下：
1. Dispatcher（分发器）
核心定位：JobManager 的“门户”，负责接收作业提交、提供 Web 交互入口，并协调作业的初始化。
核心功能：
- 接收作业提交：通过 REST API 接收 Client 提交的作业信息，包括 JobGraph（优化后的逻辑执行图）、依赖的 JAR 包、配置参数（如并行度、Checkpoint 策略）等。
- 验证与预处理：检查作业配置的合法性（如并行度是否超过集群最大资源、依赖资源是否存在），避免无效作业进入集群。
- 启动 JobMaster：为每个合法的作业启动一个专属的 JobMaster 实例（轻量级线程或进程），并将作业元数据（JobGraph、配置）传递给 JobMaster。
- 提供 Web UI：内置 Web 服务器（默认端口 8081），展示集群状态、作业列表、任务进度等信息，方便用户监控和调试。
- 作业状态跟踪：记录所有作业的生命周期状态（已提交、运行中、成功、失败），并向 Client 反馈作业状态。
工作机制：
Dispatcher 是无状态的（或状态持久化到外部存储），即使自身重启，也可通过外部存储（如 ZooKeeper）恢复作业提交记录。在高可用（HA）模式下，Dispatcher 通常部署多个实例，通过 ZooKeeper 选举主节点，避免单点故障。
2. ResourceManager（资源管理器）
核心定位：集群资源的“调度中心”，负责管理 TaskManager 的资源槽（Slot），为作业分配计算资源。
核心功能：
- Slot 管理：维护集群中所有 TaskManager 的 Slot 状态（空闲、已分配、故障），跟踪每个 Slot 的资源（内存、CPU）使用情况。
- 资源申请与分配：接收 JobMaster 的 Slot 申请，根据“本地性优先”“负载均衡”原则，从空闲 TaskManager 中选择合适的 Slot 分配给作业。
- TaskManager 监控：通过心跳机制（默认 5 秒）监控 TaskManager 的存活状态，若 TaskManager 崩溃，立即回收其所有 Slot 并标记为“可用”，供新作业申请。
- 动态资源调整：支持 TaskManager 的动态扩缩容（如 YARN/K8s 模式下自动增删节点），当集群资源不足时，可向底层资源管理器（如 YARN ResourceManager、K8s API）申请新的 TaskManager 节点。
部署模式差异：
- Standalone 模式：ResourceManager 是 JobManager 的内置组件，直接管理 TaskManager 资源。
- YARN 模式：Flink 的 ResourceManager 功能被 YARN 自带的 ResourceManager 替代，仅保留少量逻辑用于与 YARN 交互。
- K8s 模式：ResourceManager 与 K8s API 交互，通过创建/删除 Pod 管理 TaskManager 资源。
3. JobMaster（作业主节点）
核心定位：单个作业的“专属管家”，负责该作业从初始化到完成的全生命周期管理，与作业一一绑定（一个作业对应一个 JobMaster）。
核心功能：
-
生成物理执行计划：
将 Client 提交的 JobGraph（逻辑计划）转换为可执行的 ExecutionGraph（物理计划）：- 按并行度拆分算子链（JobVertex）为多个并行实例（ExecutionVertex）；
- 明确实例间的数据依赖关系（如 Shuffle 连接、广播连接）；
- 绑定状态后端配置（如 RocksDB 路径、Checkpoint 策略）。
-
任务调度与部署：
根据 ExecutionGraph 向 ResourceManager 申请 Slot，获取资源后：- 按“本地性优先”原则（如数据所在节点优先）将 ExecutionVertex 映射到具体的 TaskManager Slot；
- 将序列化的任务代码（算子逻辑）、状态数据、配置参数发送到目标 TaskManager，触发任务启动。
-
Checkpoint 协调：
作为 Checkpoint 的“协调者”，确保状态一致性：- 按配置间隔（如 5 秒）向所有有状态算子发送 Checkpoint 触发指令；
- 收集各算子的 Checkpoint 完成状态（如状态是否成功写入 StateBackend），只有全部完成才标记该 Checkpoint 成功；
- 维护 Checkpoint 元数据（如路径、时间戳），供故障恢复使用。
-
故障恢复：
当 TaskManager 或任务失败时：- 检测到任务心跳超时后，标记任务为“失败”；
- 向 ResourceManager 申请新的 Slot（若原 Slot 不可用）；
- 从最近成功的 Checkpoint 中恢复状态数据，重新调度任务到新 Slot，确保作业继续运行（支持 Exactly-Once 语义）。
-
任务监控与指标收集：
实时跟踪每个任务的状态（运行中、已完成、失败、重启中），收集关键指标（如处理延迟、吞吐量、Checkpoint 耗时），并通过 Dispatcher 同步到 Web UI。
生命周期：
JobMaster 随作业创建而启动，随作业完成（成功/失败）而销毁，仅占用少量资源（内存通常在 MB 级），因此集群可同时运行多个 JobMaster（对应多个作业）。
二、组件协同流程（以作业提交为例）
各组件的协作关系可通过“作业从提交到执行”的流程直观体现：
- 提交阶段：Client 通过 REST API 将 JobGraph 提交给 Dispatcher；
- 初始化阶段：Dispatcher 验证作业合法性，启动 JobMaster 并传递 JobGraph；
- 资源申请阶段：JobMaster 解析 JobGraph 生成 ExecutionGraph，计算所需 Slot 数量，向 ResourceManager 提交申请；
- 资源分配阶段：ResourceManager 从 TaskManager 中筛选空闲 Slot，分配给 JobMaster；
- 任务部署阶段：JobMaster 将任务分发到指定 Slot，TaskManager 启动任务并开始处理数据；
- 运行监控阶段：JobMaster 协调 Checkpoint、监控任务状态，ResourceManager 维护 Slot 状态，Dispatcher 同步作业状态到 Web UI。
三、关键特性：组件隔离与扩展性
- 隔离性：JobMaster 与作业一一绑定，不同作业的 JobMaster 相互隔离，避免一个作业故障影响其他作业；
- 扩展性：Dispatcher 和 ResourceManager 可独立扩展（如多实例部署），支持集群处理更多作业；
- 适配性：组件设计兼容多种部署模式（Standalone/YARN/K8s），通过轻微调整即可适应不同底层环境。
总结
JobManager 的内部组件通过专业化分工形成高效协作体系：
- Dispatcher 负责“接收与分发”，是作业进入集群的入口；
- ResourceManager 负责“资源调度”，是集群资源的管理者；
- JobMaster 负责“作业专属管理”，是单个作业的全生命周期管家。
