3. Flink运行时架构与部署模式
在金融实时计算面试中，运行时架构与部署模式是区分“会用Flink”和“懂Flink”的分水岭。面试官问“Flink集群里有哪些角色”，如果你只答“JobManager和TaskManager”，大概率会被追问到Slot共享、线程模型、甚至Session模式与Application模式的资源隔离差异。本章帮你把这条链路讲透，并给出可直接复用的回答框架。
一、核心原理：四大角色与资源模型
Flink运行时是一个典型的主从架构。JobManager是“大脑”，负责作业调度、Checkpoint协调、故障恢复；TaskManager是“四肢”，负责实际执行Task并管理内存、网络、磁盘资源。两者之间通过Actor系统通信，JobMaster负责单个作业的调度，ResourceManager负责Slot资源申请与释放，Dispatcher负责接收客户端提交并启动JobMaster。
Slot是Flink最核心的资源抽象。一个TaskManager拥有若干Slot，每个Slot代表一份固定的资源子集（CPU、内存、网络缓冲）。默认情况下，Slot数量等于TaskManager的CPU核数。但Slot不等于线程——一个Slot可以运行多个Task，这些Task以线程方式并发执行，通过“算子链”机制合并成一个Task，减少线程切换和序列化开销。
二、方法流程：从提交到执行的完整链路
面试中常问“一个Flink作业提交后发生了什么”。你可以按以下流程回答：
- 客户端将作业Jar和配置提交给Dispatcher或直接提交给JobManager。
- Dispatcher启动JobMaster，JobMaster将JobGraph转换为ExecutionGraph。
- JobMaster向ResourceManager申请Slot，ResourceManager向TaskManager发起资源分配。
- TaskManager提供Slot后，JobMaster将Task部署到对应Slot中执行。
- Task以线程方式运行，算子链内的多个算子合并为一个Task，减少数据交换。
- Checkpoint由JobManager触发，TaskManager执行快照并上报状态。
在金融实时风控场景中，这条链路直接决定了故障恢复速度。如果Slot不足，作业会一直等待资源；如果Slot共享过度，一个Task的背压可能影响同Slot内其他Task。因此，生产环境通常按业务线划分TaskManager，并设置合理的Slot数量。
三、部署模式对比：Session、Per-Job、Application
三种部署模式是面试高频考点，核心差异在于资源隔离、生命周期和适用场景。下表给出清晰对比：
| 维度 | Session模式 | Per-Job模式 | Application模式 |
|---|---|---|---|
| 集群生命周期 | 长期运行，多作业共享 | 每个作业独立集群 | 每个应用独立集群 |
| 资源隔离 | 弱，作业间相互影响 | 强，作业级隔离 | 强，应用级隔离 |
| 资源利用率 | 高，但可能争抢 | 较低，资源独占 | 较高，main()在集群执行 |
| 适用场景 | 小作业、快速验证 | 长周期、高隔离要求 | 生产环境、多作业编排 |
| 金融场景建议 | 不推荐核心链路 | 推荐核心风控作业 | 推荐实时数仓整体部署 |
四、案例与场景：线程模型与Slot共享的实战影响
假设一个实时反欺诈作业，包含Kafka Source、Map、KeyBy、Window、Sink五个算子。默认开启算子链后，Source和Map可能合并为一个Task，KeyBy和Window合并为另一个Task。每个Task在一个Slot内以线程运行。如果某个Window算子出现数据倾斜，该线程会持续占用CPU，但不会影响同Slot内其他Task的线程调度——因为线程是独立调度的。
但Slot共享会带来资源竞争：如果多个Task共享同一个Slot，它们共享内存和网络缓冲。当某个Task发生背压时，可能拖慢同Slot内其他Task。因此，在金融场景中，我们通常对关键算子设置slotSharingGroup，将高吞吐算子与低延迟算子隔离到不同Slot组。
// 设置Slot共享组，隔离关键算子
stream
.map(new FraudCheckMap())
.slotSharingGroup("fraud-check")
.keyBy(r -> r.getUserId())
.window(TumblingEventTimeWindows.of(Time.seconds(10)))
.slotSharingGroup("window-group")
.aggregate(new FraudAggregate());五、误区与复盘：面试中容易踩的坑
- 误区一：Slot等于CPU核数。Slot是逻辑资源单位，可以大于或小于CPU核数，取决于配置和Slot共享策略。
- 误区二：TaskManager越多越好。过多TaskManager会增加网络通信和协调开销，金融场景更关注单节点资源利用率和稳定性。
- 误区三：Session模式适合所有场景。Session模式适合快速验证，但生产环境尤其是金融核心链路，应优先选择Per-Job或Application模式。
- 误区四：算子链越长越好。算子链可以减少序列化，但过长会导致Task粒度太粗，故障恢复时重跑代价大。金融场景建议按业务逻辑合理拆分。