企业官网建设流程全解析

最近有个做实时数仓的朋友问我一个问题：他们的Flink作业经常跑着跑着就卡住不动了，数据延迟越飙越高，点开Web UI一看，Job状态显示RUNNING，但作业就是不再调度新任务。他怀疑是Source的问题，排查了半天也没结果，最后才发现问题出在JobManager身上——它的堆内存一直在Full GC，整个集群的“大脑”几乎处于半瘫痪状态。这个经历很典型，说明很多人对Flink的学习还停留在“会写Flink SQL、会调API”的层面，真正遇到集群层面的问题时，对JobManager的理解就成了有没有能力排查下去的分水岭。

这篇文章我想把JobManager这个组件彻底讲透。从它在集群里到底承担哪些职责，到一个作业从提交到运行它悄悄做了哪些事，再到调度算法、高可用设计、内存配置、故障恢复机制，最后用几个我实际踩过的生产案例收尾。无论你是刚接触Flink的基础学习者，还是在公司维护Flink集群的同学，这篇都能当一份偏底层的排查手册来用。

1. 先搞清楚一件事：JobManager究竟在管什么

1.1 从一段真实的生产事故说起

上面提到的朋友那个case，我帮他二分排查了很久。当时的现象是：两个TaskManager节点都活着，CPU和内存指标正常，日志里也没有Exception，但作业的消费位点完全不前进。后来打开JobManager的GC日志，发现老年代使用率已经到95%以上，一次Full GC要停顿好几秒。因为JobManager是单点节点，它一停顿，和TaskManager之间的心跳就超时，TaskManager会被判定失联，然后触发重新调度。一重新调度，又要创建一堆新的ExecutionVertex，堆内存压力更大，于是进入一个“Full GC → 心跳超时 → 重调度 → 更多对象 → 再次Full GC”的恶性循环。

这个问题要是对JobManager的职责范围没有概念，很容易在TaskManager、网络、Source端绕圈子。它揭示的第一件事是：JobManager不是一个可有可无的角色，而是整个集群的中央控制节点，所有和“管理”相关的事情几乎都要经过它。

1.2 JobManager的四大核心职责

把JobManager的职责拆开，核心就是四件事：

• 作业调度：接收客户端提交的JobGraph，把它转换成可执行的ExecutionGraph，然后决定每个并行子任务具体放到哪个TaskManager的哪个Slot上执行。这部分是它作为“大脑”最核心的功能。
• 资源分配：和ResourceManager协作，为作业申请Slot资源。JobManager自身不直接管理物理资源，但它决定“哪些任务需要多少资源”以及“这些资源从哪里来”。
• Checkpoint协调：Flink的容错机制依赖于Checkpoint，而CheckpointCoordinator这个组件就跑在JobManager内部。它负责生成Barrier、触发快照、收集各Task的状态确认、最终把状态持久化到外部存储。
• 故障恢复：当Task执行失败、TaskManager失联或JobManager自身发生主备切换时，负责按照配置的重启策略进行恢复操作。

除此之外，它还给Web UI提供集群和作业的运行指标，这也是我们平时看Flink UI的数据来源。

1.3 容易混淆的边界：JobManager不是ResourceManager也不是ApplicationMaster

刚开始接触Flink的人，很容易把JobManager和另外几个角色搞混。在YARN部署模式下，Flink的ApplicationMaster是负责和YARN ResourceManager交互、申请容器的角色，而JobManager是负责作业调度的角色。在Session模式下，ApplicationMaster可能和JobManager在同一进程里，但它们仍然是不同的职责边界。在Standalone模式下，没有YARN那套东西，JobManager里会有一个ResourceManager组件专门负责管理TaskManager注册和Slot资源，但“分配哪个任务到哪个Slot”这层决策仍然是JobManager的调度器在做。

这块边界不弄清楚，排查问题的时候就容易找错对象。例如看到“ResourceManager not responding”的报错，有人以为是yarn的问题，实际上可能是JobManager进程本身已经假死。在Flink的架构里，ResourceManager只是JobManager内部的一个组件，不是独立角色。这一点和Spark的Master/Driver模式有相似之处，但细节上差别很大，建议初学者先在心里画清楚这条线。

2. 作业从提交到运行，JobManager在背后做了什么

2.1 三层图结构的演进：StreamGraph、JobGraph与ExecutionGraph

一个Flink作业从用户的main方法开始执行，到最终在TaskManager上跑起来，会经历三张图：StreamGraph、JobGraph、ExecutionGraph。它们之间的转换，是理解JobManager工作最关键的线索。

StreamGraph是在Client端生成的。用户代码里的DataStream API或者SQL，会被翻译成由节点和边组成的最原始的执行逻辑图，一个算子对应一个节点。但StreamGraph是不能直接提交给JobManager的，它的并行度信息、算子链结构都还没优化。

JobGraph是在Client端经过优化后的图。优化的关键动作是Operator Chain，也就是把上下游能够合并的算子串成一条链（Chain），减少网络传输和序列化开销。JobGraph里会包含JobVertex、IntermediateDataSet等结构。我们通过flink run提交给JobManager的就是JobGraph。

ExecutionGraph是JobManager收到JobGraph之后生成的并行化版本。每个JobVertex会被展开成多个并行子任务ExecutionVertex，比如某个算子的并行度是4，那么它对应的JobVertex就会有4个ExecutionVertex。ExecutionGraph才是真正参与调度的图对象，它包含了每个子任务的状态、依赖关系、共享Slot策略等信息。

很多人看Flink Web UI的时候，看到作业被拆成一个个可展开的任务，看到“Task”层面的信息，其实看到的就是ExecutionGraph。

2.2 Slot分配与任务部署的完整链路

当一个JobGraph被提交到JobManager后，调度的起点是Scheduler。流程大致是这样的：

1. JobManager将JobGraph转换为ExecutionGraph。
2. 调度器为每个ExecutionVertex寻找合适的Slot。Slot来源是TaskManager向JobManager注册时上报的空闲Slot信息，JobManager统一记录在SlotPool里。
3. 对于一个并行度为N的作业，调度器会尝试在Slot中部署对应的Task，并通过RPC向TaskManager发送DeployTask请求。
4. TaskManager接收到请求后，在本地启动Task线程，并通过TaskExecutorGateway向JobManager汇报任务状态。
5. 当Task状态变为RUNNING，调度器会继续调度依赖关系中的下一个ExecutionVertex，直到整个ExecutionGraph全部处于运行状态。

这个过程中，Slot的选择不是随便来的。默认情况下Flink启用Slot共享机制，这意味着同一个作业的不同算子（Source、FlatMap、Sink）可以共享同一个Slot，这样能显著降低资源碎片化。但有些情况需要打破共享，比如状态很大的算子需要独占资源，或者不同算子之间需要物理隔离，这时可以用slotSharingGroup来控制。

2.3 调度模式的选择：按运行类型决定

Flink 1.12版本之后，调度器支持不同运行模式下的调度策略选择。批作业和流作业的核心差异之一，在于对待“资源不足”和“任务失败”的态度。

流作业在调度时通常是Pipelined模式，也就是上游的Task一旦起来，下游就需要跟着起来，数据可以立刻开始流动。如果某个Task因为资源不足一直调度不上去，整个作业就卡在“部分运行”的状态。

批作业则可以使用Batch模式，调度器可以按照Stage分批调度，上游Stage跑完一批数据后，下游Stage才开始，资源可以更灵活地释放和复用，也会自动处理一些中间结果的落盘策略。

这个差异导致生产环境的排查思路很不一样：流作业卡调度，大概率是Slot不够；批作业卡调度，还要额外考虑中间结果Shuffle的阻塞问题。2.0以后Flink还在推进自适应批处理调度，核心思想是让调度器根据数据量动态调整并行度，但底层的调度骨架仍然是上面那套逻辑。

3. 调度算法与Slot共享的底层逻辑

3.1 Slot是怎么来的，又为什么能共享

TaskManager启动时，会向JobManager注册，同时上报自己有多少个Slot。每个Slot代表TaskManager内部的一块资源配额，主要包括一个固定大小的内存区块和一个线程执行能力，可以通过taskmanager.numberOfTaskSlots配置。一个TaskManager的Slot数量，决定了这个节点最多能同时运行多少个Task线程。

Slot共享机制是Flink性能优化里非常关键的一环。假设一个作业有三个算子，每个并行度都是2，如果不共享Slot，一共需要6个Slot；但如果开了Slot共享，TaskManager上只需要2个Slot就能跑完整个作业，每个Slot里同时运行来自不同算子的Task。这样既减少了资源占用，又让多个子任务通过线程间通信完成数据传递，避免了不必要的网络开销。

共享的前提是这组算子属于同一个SlotSharingGroup。默认情况下，所有算子都在同一个名为“default”的SlotSharingGroup里，所以才会产生“一个Slot能装下上下游一串任务”的效果。

3.2 调度器演进：从FIFO到FSA

调度策略直接影响作业对集群资源的利用效率。早期Flink主要是FIFO（先进先出）调度：每次只运行一个作业，这个作业全部完成后再运行下一个。这种方式实现简单，恢复也快，但资源利用率很低，适合批处理场景。LIFO后来又被引入，本质上也是为批作业准备的“后进先出”策略，让新提交的小作业能插队跑完。

Flink 1.5版本引入统一的SchedulerBase之后，开始支持多作业并发调度。真正重要的是FSA（Fine-Grained Slot Sharing，细粒度Slot共享），从1.12版本开始成为默认行为。FSA的核心思路是：不再以TaskManager的物理Slot作为唯一的资源分配单元，而是基于Slot共享组的粒度进行计算。调度器会按作业需要的内存、CPU规格去“拼接”资源，让有状态的算子和无状态的算子可以更灵活地共享Slot。

简单理解：旧调度策略像“一个房间住一整户人”，FSA像“按床位分配宿舍”，谁需要多大空间、谁能和谁挤一挤，都由调度器算清楚。

3.3 调度时的判定条件与限制

调度器决定一个ExecutionVertex能否被部署，至少要满足这几个条件：

• Slot资源足够：目标Slot要有足够的空闲内存和线程容纳新任务。
• 依赖关系满足：ExecutionGraph中，上游必须满足调度条件（比如依赖的中间结果已经可用或可以同步等待）。
• SlotSharingGroup约束：共享组相同的任务尽量放到同一个Slot，共享组不同的任务必须分开。
• 局部性偏好：如果任务需要读取本地状态，优先选择状态所在的TaskManager节点。

这些条件单独看都不复杂，但组合起来就可能导致复杂的调度行为。我见过一个很典型的坑：某个作业的部分算子指定了slotSharingGroup("high-mem")，但这个组的Slot总数很少，结果整个作业一直卡在SCHEDULED状态，状态就是不起来。这种问题从Web UI上看往往只是“任务没启动”，原因必须结合调度日志才能找到。

4. JobManager的高可用设计：单点故障怎么挡

4.1 为什么生产集群必须配HA

JobManager作为集群的中央控制节点，天然是单点。一旦它挂了，整个集群等于失去了“大脑”——所有正在运行的作业都会因为心跳丢失而逐步失败。所以在生产集群里，JobManager的高可用设计几乎是必选项，而不是可选项。

HA的核心理念很简单：部署多个JobManager进程，通过Leader选举机制保证同一时刻只有一个Active JobManager在对外提供调度能力，其他进程处于Standby状态。当Active节点故障后，Standby节点接管，从持久化存储恢复作业的元数据，继续调度。

4.2 基于ZooKeeper的经典HA方案

经典的HA方案依赖ZooKeeper。配置大致如下：

high-availability: zookeeper high-availability.zookeeper.quorum: zk1:2181,zk2:2181,zk3:2181 high-availability.zookeeper.path.root: /flink-ha high-availability.storageDir: hdfs://namenode/flink/ha/

使用ZooKeeper时，多个JobManager进程会在ZooKeeper上竞争创建同一个临时节点，创建成功的成为Leader，其他节点监听这个节点。一旦Leader进程退出或失联，临时节点消失，剩下的Standby节点会收到通知并触发新一轮选举。存储目录用于保存JobManager的元数据，包括作业的ExecutionGraph信息、Checkpoint的元数据、Job状态等。这样新Leader起来之后，能直接从外部存储中恢复集群状态。

这个方案的缺点是运维上多维护一套ZooKeeper，并且ZooKeeper本身的下半区问题也可能影响Flink集群的可用性。我在一些中小型公司见到过为了省事不配HA的Standalone集群，一次机器重启导致几十个作业全部重新跑一遍，这种代价比维护ZooKeeper的成本高太多了。

4.3 基于Kubernetes的原生HA与故障切换过程

如果Flink跑在Kubernetes上，可以采用kubernetes作为HA后端，利用Kubernetes原生的ConfigMap和Lease机制来实现选主。配置类似：

high-availability: kubernetes high-availability.storageDir: s3://flink/ha/ kubernetes.leader-election.lease-duration: 15s

Kubernetes HA方案的好处是减少了对ZooKeeper的依赖，并且在云原生环境下部署更自然。故障切换的流程大致是：Active JobManager失去心跳 → Lease过期 → Standby JobManager通过竞争Lease成为新Leader → 新Leader从外部存储加载元数据 → 重新建立与TaskManager的连接、恢复调度。

切换过程中会有一个短暂的“大脑空白期”，期间的流作业通常会出现一段时间的Checkpoint超时或数据延迟，但只要恢复成功，作业会从最近一次成功的Checkpoint继续跑，不会从头读取数据。这个能力是Flink容错机制里最有价值的部分之一，也是我在生产环境反复验证过的。

5. JobManager内存模型与生产配置

5.1 统一内存模型下的JobManager内存组成

从Flink 1.10版本开始，Flink引入了统一内存模型，JobManager的内存被划分成几个明确的部分。理解它们，是正确配置JobManager堆大小的前提。

• JVM Heap（堆内存）：JobManager主要的对象存放区域。ExecutionGraph、调度状态、Checkpoint元数据、心跳信息等都在这里。配置项是jobmanager.memory.heap.size。
• JVM Direct Memory / Native Memory（堆外内存）：用于部分网络通信和底层I/O操作。
• JVM Metaspace（元空间）：存放类的元数据。
• JVM Overhead（JVM开销）：用于JVM自身运行所需的线程栈、代码缓存、GC相关空间等。

对JobManager来说，堆内存是最核心的配置项。它的默认大小是128MB，对于一个小规模的测试集群够用，但在生产环境至少要配到1GB以上，具体取决于集群里的作业数量、作业的算子数量、状态大小等。

JobManager的堆外内存和Metaspace通常不需要调太大，但也不能忽略。我见过把jobmanager.memory.heap.size配得很高，却没有调整Metaspace上限，结果因为加载的作业元数据太多把Metaspace撑爆的情况。

5.2 一份可以直接抄的flink-conf.yaml配置

基于我在生产环境常用的配置，这里给出一份基础模板，供你根据自己的集群规模调整：

# JobManager内存配置 jobmanager.memory.heap.size: 2048m jobmanager.memory.jvm-overhead.min: 256m jobmanager.memory.jvm-overhead.max: 512m jobmanager.memory.jvm-metaspace.size: 256m jobmanager.memory.jvm-metaspace.max: 512m # TaskManager内存配置 taskmanager.memory.process.size: 4096m taskmanager.memory.managed.size: 2048m taskmanager.numberOfTaskSlots: 4 # 调度与恢复配置 restart-strategy: fixed-delay restart-strategy.fixed-delay.attempts: 3 restart-strategy.fixed-delay.delay: 10 s # Checkpoint相关 state.backend: rocksdb state.checkpoints.dir: hdfs://namenode/flink/checkpoints/ execution.checkpointing.interval: 60s

需要特别提醒一句：jobmanager.memory.heap.size如果没配，Flink会按JVM默认策略自动分配；但如果你同时设置了jobmanager.memory.process.size，它会覆盖heap.size的优先级。在Flink 1.15之后的版本里，更推荐直接设置总进程内存，让Flink自己计算各部分内存。

5.3 内存配置不当引发的两起典型故障

第一起是前文提到的Full GC问题。当时集群里同时跑了十几个流作业，JobManager堆只给了1GB，作业调度对象和Checkpoint元数据把堆撑到接近100%，导致GC停顿时间过长、心跳超时。最后把堆调整到4GB，并给JVM加了-XX:+UseG1GC参数，问题立刻缓解。

第二起是Metaspace溢出。Flink作业的JAR包反复提交、卸载，如果Metaspace上限设置过小，会出现java.lang.OutOfMemoryError: Metaspace。这类问题在长时间运行的Session集群上更容易出现，因为JobManager进程会不断加载新的作业类。建议对长时间运行的JobManager进程专门设置Metaspace上限，并配合GC日志监控。

6. 故障恢复机制：作业挂了之后谁在中间“抢救”

6.1 重启策略的四种模式与适用场景

Flink提供几种重启策略，JobManager会按照配置自动执行恢复动作：

• 固定延迟重启（fixed-delay）：失败后等待固定延迟再重启，最多尝试N次。这是最常用的一种，适合多数流作业。
• 失败率重启（failure-rate）：在指定时间窗口内允许失败N次，超过之后不再重启。适合对稳定性要求高、不想无限重试的作业。
• 指数延迟重启（exponential-delay）：每次重启延迟递增，避免失败时对集群造成反复冲击，适合容易因为外部依赖抖动而导致失败的作业。
• 不重启（none）：失败后直接退出，适合批处理作业或希望失败必现的场景。

我曾经遇到过把restart-strategy.fixed-delay.delay设置成1秒的情况，结果下游Kafka集群抖动时，作业反复重启，每次都把线上Kafka Consumer Group搞一遍重平衡，问题被无限放大，最后下游直接瘫痪。重启策略的延迟要明显大于下游依赖恢复的时间，这是一个很重要的经验。

6.2 Checkpoint协调机制的原理

Checkpoint是Flink容错的地基。它的协调者CheckpointCoordinator就跑在JobManager上，负责定期向所有Source任务发送Barrier。Barrier在数据流中传播时，每个算子会把自身状态快照下来，最终所有快照都成功，就形成一个完整的Checkpoint。

整个过程中，JobManager扮演的是“总导演”角色：它发起快照、收集各Task的快照完成消息、把元数据写入持久化存储、清理过期的Checkpoint。如果某个Task快照超时，JobManager会宣布本次Checkpoint失败，并在策略允许的情况下重试。这也是为什么当JobManager本身出现GC或CPU问题时，Checkpoint往往会频繁失败——不是算子代码的问题，而是“总导演”自己卡住了。

6.3 一次完整恢复过程的六个阶段

当某个Task失败后，JobManager会按照这个链路执行恢复：

1. 感知失败：通过TaskExecutor的心跳上报或者RPC回调，JobManager得知Task进入FAILED状态。
2. 扩散失败：将这个Task标记为失败，然后向其他相关Task下发取消或失败指令，让整条作业链路停止继续消费数据。
3. 调用重启策略：根据配置判断是否可以重启、延迟多久。
4. 重新创建执行图：在内存中重建ExecutionGraph，重新调度所有ExecutionVertex。
5. 从最近Checkpoint恢复：各Task在与JobManager确认位置后，从最近一次成功的Checkpoint状态中恢复自己的状态和消费位点。
6. 重新开始消费：作业进入RUNNING状态，数据从恢复位置继续处理。

这6步里，最容易出问题的其实是第4和第5步：ExecutionGraph重建需要足够的内存，状态恢复需要访问外部存储（比如RocksDB的本地目录或HDFS上的Checkpoint文件），任何一个环节变慢，都会表现为“作业恢复时间过长”或者“反复恢复失败”。

7. 生产环境排查JobManager问题的三个真实案例

7.1 Full GC导致TaskManager被误判失联

现象：某个JobManager日志里频繁出现Lost connection with TaskManager，接着TaskManager被标记为失联并从SlotPool中移除。但看TaskManager本身的日志，进程一直在正常跑。

排查过程：先看JobManager的GC日志，发现老年代占满，Full GC频率高到几秒一次。再用jstat -gcutil查看堆各代使用率，确认是JobManager堆内存不足。

修复：调整jobmanager.memory.heap.size，从1GB增至4GB，同时给JobManager进程加上GC日志输出参数，方便后续观察。调整后心跳超时问题消失，作业恢复正常。

教训：JobManager的堆内存不是配置一次就一劳永逸的。集群作业数量增长、单个作业的算子链变长、Checkpoint频率提高，都会增加JobManager堆的消耗。建议把JobManager堆内存的监控和集群扩缩容、作业数量变化放在一起看。

7.2 作业提交后一直卡在SCHEDULED

现象：新提交的作业在Web UI上长时间处于SCHEDULED状态，点开任务详情，各个Task都没有被调度的迹象，作业不消费数据也不报错。

排查过程：第一反应是看TaskManager的空闲Slot数。打开UI的Task Managers页面，发现确实有足够空闲Slot，排除了物理资源不足的因素。接着看JobManager日志，没有发现异常Exception，但能看到调度器一直尝试申请特定Slot的日志。进一步排查发现，这个作业的某个算子被打上了slotSharingGroup("important")的标签，而集群里其他作业已经把这个共享组的Slot占满了，新作业的该算子永远等不到可用的Slot。

修复：调整作业的SlotSharingGroup设置，或者增加TaskManager节点。

教训：调度器是“按组找资源”的逻辑，不是简单的“哪个Slot空我就用哪个”。遇到作业卡调度，优先查SlotSharingGroup的配置。

7.3 重启策略配错，小故障演变成雪崩

现象：某个使用固定延迟重启的流作业，在依赖的MySQL服务重启期间反复失败，JobManager连续多次重启该作业，每次都是起来没几秒又失败。由于作业重启时会重新申请Slot，其他正常作业的资源被挤占，集群整体出现资源紧张。

排查过程：看JobManager日志，能清晰地看到“Restarting job”和“Job failed”交替出现。查看restart-strategy.fixed-delay.delay配置，发现只有1秒，attempts设置的是10次，也就是作业会在10秒内反复重启10次。

修复：将延迟调整为30秒，将最大尝试次数调整为3次，同时配置了指数延迟重启策略作为后续新作业的默认策略。

教训：重启策略不是“越多越好”，恢复能力要结合下游依赖的故障时长设计。与其让作业在10秒内撞墙10次，不如让它等待下游恢复后干净地重启一次。

8. 最后：给刚接触Flink的同学几句实在话

从我自己的学习路径看，Flink上手最快的方式不是先啃源码，而是“带着问题去看组件”。第一次看JobManager的时候，我也只是知道它是“集群的大脑”，直到真的遇到作业调度卡住、Checkpoint连续失败这类问题，才被迫去翻作业调度和故障恢复的实现，那一遍看下来比看十遍架构图都有效。

如果你刚开始接触这部分内容，我的建议是：搭一个双节点Standalone集群，故意把jobmanager.memory.heap.size调得很小，然后提交几个作业观察GC和调度之间的连锁反应；再试试关掉集群，观察TaskManager失联后作业的恢复过程。这些操作不需要多复杂的代码，却能让你对JobManager的行为产生很直观的体感。纸上得来终觉浅，调度这种机制，亲眼看着它“犯错”一次，比背一百个概念都管用。