4. Flink运行架构
Flink 之所以能在工业实时数据处理场景中稳定运行，核心在于它把“作业提交—任务调度—资源管理—检查点协调—容错恢复”串成了一条闭环链路。理解这条链路，才能解释为什么同一个作业在开发环境能跑、上线后却出现反压、重启甚至数据重复。本章从运行架构角度拆解 Flink 的分布式执行机制，重点说明 JobManager、TaskManager、ResourceManager、Dispatcher 与 Checkpoint Coordinator 之间的协作关系。
一、核心角色与作业提交流程
Flink 集群采用主从架构。JobManager 是控制平面，负责接收作业、生成执行图、调度任务、协调检查点；TaskManager 是工作平面，提供 Slot 并执行具体 Task。ResourceManager 负责 Slot 资源申请与释放，Dispatcher 提供 REST 接口并拉起 JobManager。一个作业从提交到运行，通常经历以下阶段：
- 客户端将用户代码与依赖打包为 JobGraph，提交给 Dispatcher。
- Dispatcher 启动 JobManager，并把 JobGraph 交给它。
- JobManager 将 JobGraph 转换为 ExecutionGraph，按并行度拆分为多个 ExecutionVertex。
- JobManager 向 ResourceManager 申请 Slot，ResourceManager 向 TaskManager 分配 Slot。
- Task 被部署到 TaskManager 的 Slot 中，开始消费数据并向下游发送。
二、任务调度与资源管理
Flink 的任务调度以 Slot 为基本单位。每个 TaskManager 可提供若干 Task Slot，Slot 之间内存隔离，但共享网络与 CPU。调度模式分为 EAGER 与 LAZY：流作业通常采用 EAGER，所有任务同时调度；批作业可采用 LAZY，按需调度。资源管理上，Flink 支持 Standalone、YARN、Kubernetes 等模式。以 Kubernetes 为例，ResourceManager 通过 K8s API 动态申请 Pod，每个 Pod 启动一个 TaskManager，实现弹性扩缩容。
调度过程中最常见的瓶颈是 Slot 不足。若作业并行度为 8，而集群只有 4 个 Slot，则 JobManager 会持续等待资源，作业处于 CREATED 或 SCHEDULED 状态。此时应检查 taskmanager.numberOfTaskSlots 与作业并行度是否匹配。
# flink-conf.yaml 关键资源配置
jobmanager.rpc.address: flink-jobmanager
taskmanager.numberOfTaskSlots: 4
parallelism.default: 4
taskmanager.memory.process.size: 4096m
state.backend: rocksdb
state.checkpoints.dir: hdfs:///flink/checkpoints三、检查点协调机制
检查点是 Flink 容错的核心。JobManager 中的 Checkpoint Coordinator 周期性向所有 Source 注入 Barrier，Barrier 随数据流向下游传递。当某个算子收到所有输入流的 Barrier 后，会先对齐 Barrier，再对本地状态做快照，最后把状态句柄上报给 Coordinator。所有算子完成快照后，本次检查点宣告成功。Barrier 对齐保证了 Exactly-Once 语义，但也会在反压时拉长对齐时间。
状态后端决定快照存储方式：MemoryStateBackend 适合本地调试；FsStateBackend 将状态存于文件系统；RocksDBStateBackend 支持超大状态并增量检查点，是工业场景的常用选择。检查点间隔、超时与最小暂停时间需要结合数据延迟与恢复目标调优。
四、容错恢复与重启策略
当 Task 失败时，JobManager 会先取消受影响的 Task，再根据重启策略决定是否重新调度。Flink 提供多种重启策略：固定延迟、失败率、无重启。恢复时，作业从最近一次成功的检查点恢复状态，并从检查点对应的数据位置重新消费。若 Source 支持偏移量回放，则可实现 Exactly-Once；若 Source 不支持，则只能保证 At-Least-Once。
| 机制 | 作用 | 关键参数 | 常见问题 |
|---|---|---|---|
| 作业提交 | JobGraph 转换为 ExecutionGraph | parallelism.default | 依赖冲突、类加载失败 |
| 任务调度 | 按 Slot 分配并部署 Task | taskmanager.numberOfTaskSlots | Slot 不足、调度延迟 |
| 资源管理 | 动态申请与释放 TaskManager | resourcemanager.taskmanager-timeout | Pod 启动慢、资源碎片 |
| 检查点协调 | Barrier 对齐与状态快照 | execution.checkpointing.interval | 对齐超时、反压导致失败 |
| 容错恢复 | 从检查点恢复并重启任务 | restart-strategy.fixed-delay.attempts | 恢复风暴、数据重复 |
五、工业场景案例与复盘
某钢铁厂实时质量监测作业，并行度为 16，使用 RocksDB 状态后端，检查点间隔 30 秒。上线后频繁出现检查点超时。排查发现：Keyed State 单键过大，Barrier 对齐时间超过 30 秒；同时 TaskManager 内存不足，频繁 Full GC。优化措施包括：将检查点间隔调整为 60 秒，开启增量检查点，增加 TaskManager 内存，并对热点键做预聚合。调整后检查点成功率从 72% 提升到 99.6%。
综上，Flink 运行架构的本质是“控制平面调度 + 数据平面执行 + 检查点协调 + 重启恢复”的协同。掌握 JobManager、TaskManager、ResourceManager 与 Checkpoint Coordinator 的职责边界，理解 Slot、Barrier、状态后端与重启策略的联动关系，才能在工业实时场景中把作业调得既稳又快。