Flink架构全景：JobManager、TaskManager到底在干嘛

📋 面试题

请简单介绍一下Flink的架构，JobManager和TaskManager分别负责什么？

💡 先想30秒，再往下看答案

两个核心角色

Flink集群就两种进程：JobManager（管事的）和TaskManager（干活的）。

组件	角色	核心职责
JobManager	管理者	接收作业、生成执行图、协调Checkpoint、故障恢复
TaskManager	执行者	运行Task、管理内存和网络Buffer、汇报心跳

类比：JobManager就像项目经理，负责拆任务和协调；TaskManager就像一线开发，负责执行具体计算。

JobManager三大子组件

JobManager
├── Dispatcher     — 接收作业提交，为每个作业启动JobMaster
├── JobMaster      — 管理单个作业的执行（调度、Checkpoint、故障恢复）
└── ResourceManager — 管理TaskManager的Slot资源

面试重点：JobMaster和ResourceManager是分开的。JobMaster负责作业逻辑，ResourceManager负责资源。这样一个JM可以同时管理多个作业。

TaskManager与Slot

TaskManager的计算资源被划分为Task Slot。每个Slot是一份固定的内存资源，但共享CPU。

TaskManager (4GB内存, 2 Slots)
├── Slot 1 (2GB) — 运行Source → Map
└── Slot 2 (2GB) — 运行KeyBy → Sink

我在元宇宙社交公司配置Flink集群时，每个TaskManager配了4个Slot，8GB内存。一开始Slot配太多（8个），导致每个Slot只有1GB内存，State大的任务直接OOM。后来调整为4个Slot，单Slot 2GB，才稳定下来。

💡 Slot数量不是越多越好。Slot多=单Slot内存少。要根据任务的State大小来定。

部署模式

模式	特点	适用场景
Standalone	自己管资源，最简单	开发测试
YARN Session	先启动集群，多个作业共享	作业多、资源紧张
YARN Per-Job	每个作业独立集群，隔离好	生产环境主流
K8s Native	Flink直接和K8s交互申请资源	云原生环境

我们生产环境用的YARN Per-Job模式。好处是作业之间完全隔离，一个作业挂了不影响其他的。缺点是每次提交都要申请资源，启动慢几十秒。

任务提交到执行的完整流程

用户提交作业（JAR/SQL）
    ↓
Dispatcher 接收 → 启动 JobMaster
    ↓
JobMaster 把代码转成执行图：
  StreamGraph → JobGraph → ExecutionGraph
    ↓
ResourceManager 分配 Slot
    ↓
Task 部署到 TaskManager 的 Slot 中
    ↓
Task 开始执行，数据在算子间流动

面试要能说清楚这个流程，特别是三层图的转换：StreamGraph（逻辑图）→ JobGraph（优化图，合并算子链）→ ExecutionGraph（物理执行图，考虑并行度）。

面试加分提示

💡 高分回答模板：

「Flink架构是主从结构。JobManager负责作业管理和协调，内部有Dispatcher、JobMaster和ResourceManager三个组件。TaskManager负责实际执行，资源以Slot为单位划分。

作业提交后经过StreamGraph→JobGraph→ExecutionGraph三层转换，最终部署到TaskManager的Slot上执行。

我们生产环境用YARN Per-Job模式，每个作业独立集群，互不影响。」

📌 总结

记忆点	内容
两大角色	JobManager（管事）+ TaskManager（干活）
JM三组件	Dispatcher + JobMaster + ResourceManager
Slot	TM的资源单位，固定内存，共享CPU
三层图	StreamGraph → JobGraph → ExecutionGraph
生产部署	YARN Per-Job 或 K8s Native

▶ 下一篇预告：DAY 2 时间语义与Watermark

Wood聊大数据 | 9年大数据老兵，聊技术、聊职场、聊成长