1. 从一次线上告警说起为什么要啃透Flink运行时调度凌晨两点值班手机响了——某条实时计算链路的端到端延迟突然从200毫秒飙到8秒反压指标全线飘红。登录集群一看TaskManager的槽位空着好几个但作业的并行子任务就是分配不上去。那一刻我才真正意识到Flink的运行时调度过程不是面试八股而是决定作业能不能稳、能不能快、出问题能不能快速定位的命根子。很多人学Flink把时间花在算子API、窗口语义、状态后端上这些当然重要。但真正让一个作业从“能跑”到“跑得稳”的分水岭往往在于你是否理解JobManager内部那套调度逻辑一个JobGraph是怎么变成ExecutionGraph的Slot是怎么被申请的并行子任务是怎么被分配到具体TaskManager上的失败之后又是怎么重新调度的。这些环节里任何一环卡住表现出来就是延迟、反压、甚至作业反复重启。这篇内容适合三类人一是刚接触Flink、想搞明白“作业提交后到底发生了什么”的初学者二是正在排查资源分配、反压、重启问题的运维和开发三是准备深入Flink内核、想从调度视角理解流计算运行机制的技术人。我会用图解式的思路把运行时调度的完整链路拆开讲透包括核心概念、关键数据结构、调度流程、失败恢复以及我在实际排查中踩过的坑和总结的排查技巧。全程不堆砌源码但关键机制一定讲清楚“为什么这么设计”。2. 调度全景先建立一张心智地图2.1 四个核心角色与它们的关系Flink运行时调度涉及四个关键角色理解它们的分工是理解整个调度过程的前提。JobManager是集群的大脑负责接收作业、生成执行图、申请资源、协调Checkpoint、处理故障恢复。它内部又分为几个组件Dispatcher负责接收客户端提交的作业并启动JobMasterResourceManager负责管理TaskManager的槽位资源JobMaster则是单个作业的“项目经理”负责这个作业从调度到完成的全生命周期。TaskManager是真正干活的节点每个TaskManager是一个JVM进程内部管理着若干TaskSlot。Slot是Flink资源调度的最小单位一个Slot可以运行一个或多个并行子任务取决于是否开启Slot共享。ResourceManager注意Flink自己也有一个ResourceManager和YARN的ResourceManager不是一回事负责向底层资源框架如YARN、Kubernetes或Standalone申请和释放TaskManager。Dispatcher提供REST接口接收作业提交并为每个作业启动一个JobMaster。这四者的关系可以这样理解Dispatcher是前台负责接待客户作业ResourceManager是后勤负责搞到工位SlotJobMaster是项目经理负责把活拆好、安排到工位上TaskManager就是工位所在的办公楼Slot就是具体工位。2.2 从JobGraph到ExecutionGraph的两次“翻译”作业提交后图结构会经历两次关键转换这是调度过程的起点。第一次转换发生在客户端用户写的DataStream API代码经过算子链优化后生成JobGraph。JobGraph的节点是JobVertex每个JobVertex代表一个算子链多个算子合并在一起以减少网络开销。此时还没有并行度的概念一个JobVertex只是一个逻辑上的操作单元。第二次转换发生在JobMasterJobGraph被转换成ExecutionGraph。这一步是调度的核心——每个JobVertex会根据并行度展开成多个ExecutionVertex每个ExecutionVertex对应一个并行子任务。同时ExecutionGraph还会为每个ExecutionVertex创建多个Execution对应不同的执行尝试比如第一次执行、失败后重试。用一个类比JobGraph是“设计图纸”上面写着“这里要装一个厨房”ExecutionGraph是“施工排班表”写着“厨房要装3个灶台每个灶台安排一个工人如果工人请假就换人重来”。2.3 调度状态的流转一个子任务的一生每个ExecutionVertex在调度过程中会经历一系列状态变化理解这些状态是排查问题的关键。创建后处于CREATED状态当所有前置条件满足比如上游数据准备好、Slot申请到后进入SCHEDULED被分配到具体Slot后进入DEPLOYINGTaskManager收到部署请求并启动任务后进入RUNNING任务正常结束进入FINISHED如果失败则进入FAILED然后根据重启策略可能回到CREATED重新调度。实际排查中如果看到大量子任务卡在SCHEDULED状态通常意味着Slot资源不足如果卡在DEPLOYING可能是TaskManager负载过高或网络问题如果频繁在RUNNING和FAILED之间跳转就要看具体异常栈了。提示在Flink Web UI的Job Detail页面可以直观看到每个子任务的状态和所在TaskManager这是排查调度问题的第一入口。3. 调度核心机制拆解Slot、共享与资源申请3.1 Slot的本质不只是“工位”那么简单Slot常被简单理解为“工位”但它承载的信息比想象中多。一个TaskManager有多少Slot是在启动时通过taskmanager.numberOfTaskSlots配置的。这个数字通常建议等于该节点的CPU核数因为每个Slot最终会以一个或多个线程的形式消耗CPU。但Slot不等于线程。一个Slot可以运行多个并行子任务前提是这些子任务来自同一个Slot共享组Slot Sharing Group。默认情况下所有算子都在同一个共享组“default”里这意味着一个Slot里可能同时跑着map、filter、sink等多个子任务。为什么要做Slot共享核心目的是提高资源利用率。一个典型的流作业source和sink往往是资源消耗大户而中间的map/filter很轻量。如果不共享每个子任务独占一个Slot就会出现“有的Slot忙死、有的Slot闲死”的情况。共享之后一个Slot里的多个子任务可以错峰使用CPU整体吞吐更高。但共享也有代价如果共享组里某个子任务出现反压或GC停顿会影响同Slot里的其他子任务。所以对于延迟敏感或资源消耗差异大的算子可以通过slotSharingGroup手动隔离。3.2 Slot Pool与资源申请流程JobMaster内部维护着一个SlotPool它记录了当前作业可用的所有Slot。当ExecutionGraph需要调度时会向SlotPool请求Slot。如果SlotPool里有足够的空闲Slot直接分配如果没有SlotPool会向ResourceManager发起资源申请。ResourceManager再根据部署模式决定如何获取新资源在Standalone模式下它只能等待已有TaskManager注册在YARN或Kubernetes模式下它可以主动申请新的容器来启动TaskManager。这里有一个容易混淆的点SlotPool申请的是“Slot”而不是“TaskManager”。ResourceManager收到请求后会尝试凑齐所需数量的Slot。如果现有TaskManager的Slot不够才会申请新的TaskManager。新TaskManager启动后会向ResourceManager注册自己的SlotResourceManager再把这些Slot提供给SlotPool。整个链路是ExecutionGraph → SlotPool → ResourceManager → 底层资源框架 → 新TaskManager → 注册Slot → 回传给SlotPool → 分配给ExecutionVertex。3.3 资源申请中的“批量”与“超时”策略Flink在申请资源时不是“要一个给一个”而是有一定的批量策略。当有多个ExecutionVertex同时需要Slot时SlotPool会尽量一次性申请足够数量的Slot减少与ResourceManager的交互次数。但批量申请也带来一个问题如果资源紧张可能长时间申请不到。Flink为此设置了资源申请超时slot.request.timeout默认5分钟。超时后作业会失败并根据重启策略决定是否重新尝试。实际运维中如果看到作业频繁因为“Could not allocate all requested slots”失败通常有两个原因一是集群资源确实不足需要扩容二是资源申请配置不合理比如并行度设置过高超过了集群总Slot数。注意在Kubernetes等弹性环境中资源申请超时时间可以适当调大因为新Pod启动需要时间。但也不能无限大否则作业会长时间卡在等待状态而不报错。4. 调度流程逐步图解从提交到运行4.1 作业提交与JobMaster启动用户通过flink run提交作业后客户端会先做一轮优化合并算子链、生成JobGraph然后把JobGraph和依赖的JAR包一起提交给Dispatcher。Dispatcher收到后为这个作业启动一个JobMaster。JobMaster首先将JobGraph转换成ExecutionGraph然后开始调度。这一步的关键是JobMaster是每个作业独立的。一个集群里可以有多个JobMaster每个负责一个作业。这样作业之间互不影响但也意味着每个JobMaster都会独立向ResourceManager申请资源。4.2 调度触发从“源”到“汇”的拓扑遍历ExecutionGraph的调度不是一次性全部展开而是按照拓扑顺序逐步进行。Flink采用了一种自顶向下的调度策略先调度没有上游依赖的节点通常是Source再调度下游节点。具体来说JobMaster会遍历ExecutionGraph找到所有处于CREATED状态且前置依赖已满足的ExecutionVertex将它们标记为SCHEDULED并开始为它们申请Slot。这里有一个细节并非所有节点同时调度。Flink支持惰性调度Lazy Scheduling即下游节点在上游节点开始产出数据后才调度。这可以减少资源占用时间但也可能导致启动延迟。默认情况下Flink会尽量并行调度以加快作业启动速度。4.3 Slot分配与任务部署当SlotPool拿到可用Slot后会将Slot分配给具体的ExecutionVertex。分配时会考虑位置偏好如果ExecutionVertex有输入通道来自某个TaskManagerFlink会优先将任务分配到同一节点减少网络传输。分配完成后JobMaster会向对应的TaskManager发送TaskDeploymentDescriptor里面包含了任务的所有信息算子代码、输入输出通道、状态后端配置等。TaskManager收到后启动一个Task线程来执行。任务启动后会向JobMaster汇报状态变为RUNNING。至此一个子任务的调度完成。4.4 数据交换与反压传导任务运行起来后上游和下游之间通过InputChannel和ResultPartition进行数据交换。如果下游处理速度跟不上上游的ResultPartition会积压进而导致上游任务阻塞——这就是反压。反压是调度过程中最常遇到的问题之一。从调度视角看反压本身不是调度失败但它会导致任务处理变慢进而影响Checkpoint、延迟等指标。如果反压严重到一定程度可能触发TaskManager的心跳超时最终导致任务失败和重新调度。排查反压时Web UI的BackPressure标签页可以直观看到每个算子的反压程度。如果某个算子持续显示HIGH就要检查它的下游是否有性能瓶颈。5. 故障恢复与重新调度作业失败后发生了什么5.1 失败检测心跳与异常上报TaskManager会定期向JobMaster发送心跳。如果JobMaster在一定时间内heartbeat.timeout默认50秒没有收到心跳就认为该TaskManager失联其上的所有任务标记为失败。除了心跳超时任务本身抛出的异常也会被TaskManager捕获并上报给JobMaster。JobMaster收到失败通知后会根据重启策略决定下一步动作。5.2 重启策略全量重启还是局部重启Flink支持多种重启策略固定延迟重启、失败率重启、无重启等。默认情况下如果未配置Checkpoint作业失败后不会自动重启如果配置了Checkpoint默认使用固定延迟重启次数为Integer.MAX_VALUE。重启时Flink会取消所有正在运行的任务然后从最近一次成功的Checkpoint恢复状态重新调度所有ExecutionVertex。这就是所谓的全量重启。全量重启的代价很大所有任务都要重新部署状态要重新加载作业会中断一段时间。为了减少影响Flink后来引入了局部重启Region Failover只重启受影响的区域。但局部重启需要满足一定条件比如失败区域的上游有可用的缓存数据。5.3 重新调度的关键状态恢复与Slot重新分配重新调度时JobMaster会重置ExecutionGraph中失败部分的ExecutionVertex状态然后重新走一遍调度流程申请Slot、分配、部署。这里有一个关键点状态恢复。如果作业开启了Checkpoint每个任务在恢复时会从Checkpoint中读取自己的状态。如果状态很大恢复时间会很长这段时间作业是不可用的。实际运维中如果作业频繁重启首先要看失败原因。如果是资源不足导致的扩容如果是代码异常修代码如果是数据倾斜导致的OOM调整并行度或keyBy策略。盲目调大重启次数只会掩盖问题。提示在Flink配置中restart-strategy和restart-strategy.fixed-delay.attempts是关键参数。生产环境建议设置合理的重启次数和延迟避免无限重启导致集群雪崩。6. 实操排查调度问题的常见症状与解决思路6.1 症状一作业卡在SCHEDULED状态这是最常见的调度问题。表现是Web UI上大量子任务显示SCHEDULED但迟迟不变成RUNNING。排查思路先看集群总Slot数和已用Slot数。如果已用Slot等于总Slot说明资源不足需要扩容或降低并行度。如果Slot有空闲但任务还是卡着检查SlotPool的日志看是否有资源申请超时或ResourceManager通信异常。还有一种可能是Slot共享组配置不当。如果某个算子的Slot共享组被单独设置而该组没有可用Slot就会卡住。检查代码中是否有slotSharingGroup的调用。6.2 症状二任务频繁重启任务频繁在RUNNING和FAILED之间跳转通常伴随异常日志。排查思路先看JobManager日志中的异常栈定位是哪种失败。常见原因包括内存不足导致OOM、Checkpoint超时、网络分区导致心跳丢失、数据倾斜导致某个子任务过载。如果是OOM检查TaskManager的内存配置和状态后端类型。如果是Checkpoint超时检查状态大小和Checkpoint间隔。如果是数据倾斜考虑调整keyBy策略或增加并行度。6.3 症状三反压导致延迟飙升反压本身不是错误但持续反压会导致延迟增加、Checkpoint失败。排查思路用Web UI的BackPressure页面定位反压源头。通常反压会从下游向上游传导所以要从最下游的算子开始查。常见原因包括下游算子处理逻辑复杂、外部存储写入慢、数据倾斜导致个别子任务过载。解决反压的手段包括增加并行度、优化算子逻辑、异步IO、调整缓冲区大小等。但根本还是要找到瓶颈点对症下药。6.4 常见问题速查表症状可能原因排查入口解决方向卡在SCHEDULEDSlot不足、共享组配置错误SlotPool日志、Web UI扩容、调整并行度、检查共享组频繁重启OOM、Checkpoint超时、心跳丢失JobManager日志调内存、调Checkpoint、查网络持续反压下游瓶颈、数据倾斜BackPressure页面增并行度、异步IO、调keyBy启动慢状态大、资源申请慢Checkpoint恢复日志增资源、调超时、优化状态任务分布不均位置偏好、Slot分配策略Web UI任务分布调并行度、检查数据分布7. 几个容易被忽略的调度细节与个人经验7.1 Slot共享的“隐性成本”Slot共享提高了资源利用率但也带来一个隐性成本故障传播。如果共享组里一个子任务失败整个Slot里的所有子任务都会被取消并重新调度。这意味着一个轻量算子的失败可能拖累同Slot里的重量级算子。我的经验是对于核心链路可以把Source、Sink和关键计算算子放在不同的共享组里牺牲一点资源利用率换取故障隔离。具体做法是在代码中调用.slotSharingGroup(group-name)然后通过taskmanager.numberOfTaskSlots和并行度配合确保每个组有足够的Slot。7.2 资源申请超时不是“调大就好”很多人遇到资源申请超时就调大slot.request.timeout但这只是把问题延后。如果集群资源确实不足调大超时只会让作业卡更久才报错。正确的做法是先确认集群总资源是否满足作业需求。计算方式是作业所需Slot数 max(每个Slot共享组的并行度)。如果这个数字大于集群总Slot数就必须扩容或降低并行度。只有在弹性环境下如Kubernetes新节点启动需要时间才适合适当调大超时。7.3 Checkpoint与调度的相互影响Checkpoint和调度是相互影响的。一方面Checkpoint需要所有任务都到达屏障Barrier才能完成如果某个任务因为反压或GC停顿迟迟不到达Checkpoint就会超时。另一方面Checkpoint超时会导致作业失败并触发重新调度而重新调度又需要从上一个Checkpoint恢复形成恶性循环。我的经验是Checkpoint间隔不要设置得太短给任务留出足够的处理时间。同时开启非对齐CheckpointUnaligned Checkpoint可以在反压场景下显著减少Checkpoint时间代价是状态会变大。7.4 位置偏好与数据本地性Flink在分配Slot时会尽量考虑数据本地性把任务分配到离数据近的节点。但在流计算中数据是流动的本地性更多体现在上游和下游在同一节点减少网络传输。如果发现任务分布不均匀可以检查是否开启了位置偏好。在某些情况下关闭位置偏好通过配置反而能让Slot分配更均匀避免热点。8. 从调度视角看作业优化几个可落地的建议8.1 并行度设置不是越大越好并行度决定了ExecutionVertex的数量也决定了需要多少Slot。并行度设置过高会导致资源申请困难、任务调度开销大、Checkpoint协调成本高。设置过低则无法充分利用集群资源。我的建议是并行度先设置为集群总Slot数的70%左右留出余量给其他作业和故障恢复。然后根据实际吞吐和延迟逐步调整。对于Source和Sink可以单独设置并行度与中间算子解耦。8.2 Slot数配置与CPU核数匹配taskmanager.numberOfTaskSlots建议设置为该节点的CPU核数。设得太小资源利用率低设得太大多个Slot争抢CPU导致频繁上下文切换和GC。在容器化环境中还要考虑容器的CPU限制。如果容器只分配了4核Slot数设为8就会导致严重的CPU争抢。8.3 重启策略生产环境必须配置生产环境一定要配置重启策略。推荐使用失败率重启在指定时间窗口内允许一定次数的失败超过则作业彻底失败。这样既能应对偶发故障又能避免无限重启。配置示例在flink-conf.yaml中restart-strategy: failure-rate restart-strategy.failure-rate.max-failures-per-interval: 3 restart-strategy.failure-rate.failure-rate-interval: 10 min restart-strategy.failure-rate.delay: 10 s这段配置的意思是10分钟内最多失败3次每次重启延迟10秒。超过3次则作业失败不再自动重启。8.4 监控指标调度相关的关键指标调度相关的监控指标包括numRunningJobs、numRegisteredTaskManagers、taskSlotsTotal、taskSlotsAvailable、numTaskManagersConnected等。这些指标可以反映集群资源和作业调度的健康度。建议对taskSlotsAvailable设置告警如果持续为0说明资源紧张需要扩容。对numRunningJobs设置告警如果作业数突增可能是异常提交。9. 写在最后调度是理解Flink的钥匙我刚开始学Flink的时候总觉得调度是“底层细节”先把API用熟再说。直到有一次作业卡在SCHEDULED状态整整两个小时排查了半天才发现是Slot共享组配置冲突从那以后我才真正重视调度这块。调度过程串联了Flink的几乎所有核心概念JobGraph、ExecutionGraph、Slot、Checkpoint、重启策略、反压。理解调度就相当于拿到了理解Flink运行时的钥匙。遇到问题时你能从“作业为什么跑不起来”一路追到“Slot为什么分配不出去”而不是盲目重启或调参。最后分享一个我常用的排查套路遇到调度问题先看Web UI的Job Detail页面确认卡在哪个状态再看JobManager日志找异常最后看TaskManager日志确认资源情况。三步下来大部分问题都能定位。如果还不行就把ExecutionGraph的状态流转打印出来对照本文的状态机一步步排查。这个套路帮我省下了无数个加班的夜晚希望对你也有用。
1. 从一次线上告警说起为什么要啃透Flink运行时调度凌晨两点值班手机响了——某条实时计算链路的端到端延迟突然从200毫秒飙到8秒反压指标全线飘红。登录集群一看TaskManager的槽位空着好几个但作业的并行子任务就是分配不上去。那一刻我才真正意识到Flink的运行时调度过程不是面试八股而是决定作业能不能稳、能不能快、出问题能不能快速定位的命根子。很多人学Flink把时间花在算子API、窗口语义、状态后端上这些当然重要。但真正让一个作业从“能跑”到“跑得稳”的分水岭往往在于你是否理解JobManager内部那套调度逻辑一个JobGraph是怎么变成ExecutionGraph的Slot是怎么被申请的并行子任务是怎么被分配到具体TaskManager上的失败之后又是怎么重新调度的。这些环节里任何一环卡住表现出来就是延迟、反压、甚至作业反复重启。这篇内容适合三类人一是刚接触Flink、想搞明白“作业提交后到底发生了什么”的初学者二是正在排查资源分配、反压、重启问题的运维和开发三是准备深入Flink内核、想从调度视角理解流计算运行机制的技术人。我会用图解式的思路把运行时调度的完整链路拆开讲透包括核心概念、关键数据结构、调度流程、失败恢复以及我在实际排查中踩过的坑和总结的排查技巧。全程不堆砌源码但关键机制一定讲清楚“为什么这么设计”。2. 调度全景先建立一张心智地图2.1 四个核心角色与它们的关系Flink运行时调度涉及四个关键角色理解它们的分工是理解整个调度过程的前提。JobManager是集群的大脑负责接收作业、生成执行图、申请资源、协调Checkpoint、处理故障恢复。它内部又分为几个组件Dispatcher负责接收客户端提交的作业并启动JobMasterResourceManager负责管理TaskManager的槽位资源JobMaster则是单个作业的“项目经理”负责这个作业从调度到完成的全生命周期。TaskManager是真正干活的节点每个TaskManager是一个JVM进程内部管理着若干TaskSlot。Slot是Flink资源调度的最小单位一个Slot可以运行一个或多个并行子任务取决于是否开启Slot共享。ResourceManager注意Flink自己也有一个ResourceManager和YARN的ResourceManager不是一回事负责向底层资源框架如YARN、Kubernetes或Standalone申请和释放TaskManager。Dispatcher提供REST接口接收作业提交并为每个作业启动一个JobMaster。这四者的关系可以这样理解Dispatcher是前台负责接待客户作业ResourceManager是后勤负责搞到工位SlotJobMaster是项目经理负责把活拆好、安排到工位上TaskManager就是工位所在的办公楼Slot就是具体工位。2.2 从JobGraph到ExecutionGraph的两次“翻译”作业提交后图结构会经历两次关键转换这是调度过程的起点。第一次转换发生在客户端用户写的DataStream API代码经过算子链优化后生成JobGraph。JobGraph的节点是JobVertex每个JobVertex代表一个算子链多个算子合并在一起以减少网络开销。此时还没有并行度的概念一个JobVertex只是一个逻辑上的操作单元。第二次转换发生在JobMasterJobGraph被转换成ExecutionGraph。这一步是调度的核心——每个JobVertex会根据并行度展开成多个ExecutionVertex每个ExecutionVertex对应一个并行子任务。同时ExecutionGraph还会为每个ExecutionVertex创建多个Execution对应不同的执行尝试比如第一次执行、失败后重试。用一个类比JobGraph是“设计图纸”上面写着“这里要装一个厨房”ExecutionGraph是“施工排班表”写着“厨房要装3个灶台每个灶台安排一个工人如果工人请假就换人重来”。2.3 调度状态的流转一个子任务的一生每个ExecutionVertex在调度过程中会经历一系列状态变化理解这些状态是排查问题的关键。创建后处于CREATED状态当所有前置条件满足比如上游数据准备好、Slot申请到后进入SCHEDULED被分配到具体Slot后进入DEPLOYINGTaskManager收到部署请求并启动任务后进入RUNNING任务正常结束进入FINISHED如果失败则进入FAILED然后根据重启策略可能回到CREATED重新调度。实际排查中如果看到大量子任务卡在SCHEDULED状态通常意味着Slot资源不足如果卡在DEPLOYING可能是TaskManager负载过高或网络问题如果频繁在RUNNING和FAILED之间跳转就要看具体异常栈了。提示在Flink Web UI的Job Detail页面可以直观看到每个子任务的状态和所在TaskManager这是排查调度问题的第一入口。3. 调度核心机制拆解Slot、共享与资源申请3.1 Slot的本质不只是“工位”那么简单Slot常被简单理解为“工位”但它承载的信息比想象中多。一个TaskManager有多少Slot是在启动时通过taskmanager.numberOfTaskSlots配置的。这个数字通常建议等于该节点的CPU核数因为每个Slot最终会以一个或多个线程的形式消耗CPU。但Slot不等于线程。一个Slot可以运行多个并行子任务前提是这些子任务来自同一个Slot共享组Slot Sharing Group。默认情况下所有算子都在同一个共享组“default”里这意味着一个Slot里可能同时跑着map、filter、sink等多个子任务。为什么要做Slot共享核心目的是提高资源利用率。一个典型的流作业source和sink往往是资源消耗大户而中间的map/filter很轻量。如果不共享每个子任务独占一个Slot就会出现“有的Slot忙死、有的Slot闲死”的情况。共享之后一个Slot里的多个子任务可以错峰使用CPU整体吞吐更高。但共享也有代价如果共享组里某个子任务出现反压或GC停顿会影响同Slot里的其他子任务。所以对于延迟敏感或资源消耗差异大的算子可以通过slotSharingGroup手动隔离。3.2 Slot Pool与资源申请流程JobMaster内部维护着一个SlotPool它记录了当前作业可用的所有Slot。当ExecutionGraph需要调度时会向SlotPool请求Slot。如果SlotPool里有足够的空闲Slot直接分配如果没有SlotPool会向ResourceManager发起资源申请。ResourceManager再根据部署模式决定如何获取新资源在Standalone模式下它只能等待已有TaskManager注册在YARN或Kubernetes模式下它可以主动申请新的容器来启动TaskManager。这里有一个容易混淆的点SlotPool申请的是“Slot”而不是“TaskManager”。ResourceManager收到请求后会尝试凑齐所需数量的Slot。如果现有TaskManager的Slot不够才会申请新的TaskManager。新TaskManager启动后会向ResourceManager注册自己的SlotResourceManager再把这些Slot提供给SlotPool。整个链路是ExecutionGraph → SlotPool → ResourceManager → 底层资源框架 → 新TaskManager → 注册Slot → 回传给SlotPool → 分配给ExecutionVertex。3.3 资源申请中的“批量”与“超时”策略Flink在申请资源时不是“要一个给一个”而是有一定的批量策略。当有多个ExecutionVertex同时需要Slot时SlotPool会尽量一次性申请足够数量的Slot减少与ResourceManager的交互次数。但批量申请也带来一个问题如果资源紧张可能长时间申请不到。Flink为此设置了资源申请超时slot.request.timeout默认5分钟。超时后作业会失败并根据重启策略决定是否重新尝试。实际运维中如果看到作业频繁因为“Could not allocate all requested slots”失败通常有两个原因一是集群资源确实不足需要扩容二是资源申请配置不合理比如并行度设置过高超过了集群总Slot数。注意在Kubernetes等弹性环境中资源申请超时时间可以适当调大因为新Pod启动需要时间。但也不能无限大否则作业会长时间卡在等待状态而不报错。4. 调度流程逐步图解从提交到运行4.1 作业提交与JobMaster启动用户通过flink run提交作业后客户端会先做一轮优化合并算子链、生成JobGraph然后把JobGraph和依赖的JAR包一起提交给Dispatcher。Dispatcher收到后为这个作业启动一个JobMaster。JobMaster首先将JobGraph转换成ExecutionGraph然后开始调度。这一步的关键是JobMaster是每个作业独立的。一个集群里可以有多个JobMaster每个负责一个作业。这样作业之间互不影响但也意味着每个JobMaster都会独立向ResourceManager申请资源。4.2 调度触发从“源”到“汇”的拓扑遍历ExecutionGraph的调度不是一次性全部展开而是按照拓扑顺序逐步进行。Flink采用了一种自顶向下的调度策略先调度没有上游依赖的节点通常是Source再调度下游节点。具体来说JobMaster会遍历ExecutionGraph找到所有处于CREATED状态且前置依赖已满足的ExecutionVertex将它们标记为SCHEDULED并开始为它们申请Slot。这里有一个细节并非所有节点同时调度。Flink支持惰性调度Lazy Scheduling即下游节点在上游节点开始产出数据后才调度。这可以减少资源占用时间但也可能导致启动延迟。默认情况下Flink会尽量并行调度以加快作业启动速度。4.3 Slot分配与任务部署当SlotPool拿到可用Slot后会将Slot分配给具体的ExecutionVertex。分配时会考虑位置偏好如果ExecutionVertex有输入通道来自某个TaskManagerFlink会优先将任务分配到同一节点减少网络传输。分配完成后JobMaster会向对应的TaskManager发送TaskDeploymentDescriptor里面包含了任务的所有信息算子代码、输入输出通道、状态后端配置等。TaskManager收到后启动一个Task线程来执行。任务启动后会向JobMaster汇报状态变为RUNNING。至此一个子任务的调度完成。4.4 数据交换与反压传导任务运行起来后上游和下游之间通过InputChannel和ResultPartition进行数据交换。如果下游处理速度跟不上上游的ResultPartition会积压进而导致上游任务阻塞——这就是反压。反压是调度过程中最常遇到的问题之一。从调度视角看反压本身不是调度失败但它会导致任务处理变慢进而影响Checkpoint、延迟等指标。如果反压严重到一定程度可能触发TaskManager的心跳超时最终导致任务失败和重新调度。排查反压时Web UI的BackPressure标签页可以直观看到每个算子的反压程度。如果某个算子持续显示HIGH就要检查它的下游是否有性能瓶颈。5. 故障恢复与重新调度作业失败后发生了什么5.1 失败检测心跳与异常上报TaskManager会定期向JobMaster发送心跳。如果JobMaster在一定时间内heartbeat.timeout默认50秒没有收到心跳就认为该TaskManager失联其上的所有任务标记为失败。除了心跳超时任务本身抛出的异常也会被TaskManager捕获并上报给JobMaster。JobMaster收到失败通知后会根据重启策略决定下一步动作。5.2 重启策略全量重启还是局部重启Flink支持多种重启策略固定延迟重启、失败率重启、无重启等。默认情况下如果未配置Checkpoint作业失败后不会自动重启如果配置了Checkpoint默认使用固定延迟重启次数为Integer.MAX_VALUE。重启时Flink会取消所有正在运行的任务然后从最近一次成功的Checkpoint恢复状态重新调度所有ExecutionVertex。这就是所谓的全量重启。全量重启的代价很大所有任务都要重新部署状态要重新加载作业会中断一段时间。为了减少影响Flink后来引入了局部重启Region Failover只重启受影响的区域。但局部重启需要满足一定条件比如失败区域的上游有可用的缓存数据。5.3 重新调度的关键状态恢复与Slot重新分配重新调度时JobMaster会重置ExecutionGraph中失败部分的ExecutionVertex状态然后重新走一遍调度流程申请Slot、分配、部署。这里有一个关键点状态恢复。如果作业开启了Checkpoint每个任务在恢复时会从Checkpoint中读取自己的状态。如果状态很大恢复时间会很长这段时间作业是不可用的。实际运维中如果作业频繁重启首先要看失败原因。如果是资源不足导致的扩容如果是代码异常修代码如果是数据倾斜导致的OOM调整并行度或keyBy策略。盲目调大重启次数只会掩盖问题。提示在Flink配置中restart-strategy和restart-strategy.fixed-delay.attempts是关键参数。生产环境建议设置合理的重启次数和延迟避免无限重启导致集群雪崩。6. 实操排查调度问题的常见症状与解决思路6.1 症状一作业卡在SCHEDULED状态这是最常见的调度问题。表现是Web UI上大量子任务显示SCHEDULED但迟迟不变成RUNNING。排查思路先看集群总Slot数和已用Slot数。如果已用Slot等于总Slot说明资源不足需要扩容或降低并行度。如果Slot有空闲但任务还是卡着检查SlotPool的日志看是否有资源申请超时或ResourceManager通信异常。还有一种可能是Slot共享组配置不当。如果某个算子的Slot共享组被单独设置而该组没有可用Slot就会卡住。检查代码中是否有slotSharingGroup的调用。6.2 症状二任务频繁重启任务频繁在RUNNING和FAILED之间跳转通常伴随异常日志。排查思路先看JobManager日志中的异常栈定位是哪种失败。常见原因包括内存不足导致OOM、Checkpoint超时、网络分区导致心跳丢失、数据倾斜导致某个子任务过载。如果是OOM检查TaskManager的内存配置和状态后端类型。如果是Checkpoint超时检查状态大小和Checkpoint间隔。如果是数据倾斜考虑调整keyBy策略或增加并行度。6.3 症状三反压导致延迟飙升反压本身不是错误但持续反压会导致延迟增加、Checkpoint失败。排查思路用Web UI的BackPressure页面定位反压源头。通常反压会从下游向上游传导所以要从最下游的算子开始查。常见原因包括下游算子处理逻辑复杂、外部存储写入慢、数据倾斜导致个别子任务过载。解决反压的手段包括增加并行度、优化算子逻辑、异步IO、调整缓冲区大小等。但根本还是要找到瓶颈点对症下药。6.4 常见问题速查表症状可能原因排查入口解决方向卡在SCHEDULEDSlot不足、共享组配置错误SlotPool日志、Web UI扩容、调整并行度、检查共享组频繁重启OOM、Checkpoint超时、心跳丢失JobManager日志调内存、调Checkpoint、查网络持续反压下游瓶颈、数据倾斜BackPressure页面增并行度、异步IO、调keyBy启动慢状态大、资源申请慢Checkpoint恢复日志增资源、调超时、优化状态任务分布不均位置偏好、Slot分配策略Web UI任务分布调并行度、检查数据分布7. 几个容易被忽略的调度细节与个人经验7.1 Slot共享的“隐性成本”Slot共享提高了资源利用率但也带来一个隐性成本故障传播。如果共享组里一个子任务失败整个Slot里的所有子任务都会被取消并重新调度。这意味着一个轻量算子的失败可能拖累同Slot里的重量级算子。我的经验是对于核心链路可以把Source、Sink和关键计算算子放在不同的共享组里牺牲一点资源利用率换取故障隔离。具体做法是在代码中调用.slotSharingGroup(group-name)然后通过taskmanager.numberOfTaskSlots和并行度配合确保每个组有足够的Slot。7.2 资源申请超时不是“调大就好”很多人遇到资源申请超时就调大slot.request.timeout但这只是把问题延后。如果集群资源确实不足调大超时只会让作业卡更久才报错。正确的做法是先确认集群总资源是否满足作业需求。计算方式是作业所需Slot数 max(每个Slot共享组的并行度)。如果这个数字大于集群总Slot数就必须扩容或降低并行度。只有在弹性环境下如Kubernetes新节点启动需要时间才适合适当调大超时。7.3 Checkpoint与调度的相互影响Checkpoint和调度是相互影响的。一方面Checkpoint需要所有任务都到达屏障Barrier才能完成如果某个任务因为反压或GC停顿迟迟不到达Checkpoint就会超时。另一方面Checkpoint超时会导致作业失败并触发重新调度而重新调度又需要从上一个Checkpoint恢复形成恶性循环。我的经验是Checkpoint间隔不要设置得太短给任务留出足够的处理时间。同时开启非对齐CheckpointUnaligned Checkpoint可以在反压场景下显著减少Checkpoint时间代价是状态会变大。7.4 位置偏好与数据本地性Flink在分配Slot时会尽量考虑数据本地性把任务分配到离数据近的节点。但在流计算中数据是流动的本地性更多体现在上游和下游在同一节点减少网络传输。如果发现任务分布不均匀可以检查是否开启了位置偏好。在某些情况下关闭位置偏好通过配置反而能让Slot分配更均匀避免热点。8. 从调度视角看作业优化几个可落地的建议8.1 并行度设置不是越大越好并行度决定了ExecutionVertex的数量也决定了需要多少Slot。并行度设置过高会导致资源申请困难、任务调度开销大、Checkpoint协调成本高。设置过低则无法充分利用集群资源。我的建议是并行度先设置为集群总Slot数的70%左右留出余量给其他作业和故障恢复。然后根据实际吞吐和延迟逐步调整。对于Source和Sink可以单独设置并行度与中间算子解耦。8.2 Slot数配置与CPU核数匹配taskmanager.numberOfTaskSlots建议设置为该节点的CPU核数。设得太小资源利用率低设得太大多个Slot争抢CPU导致频繁上下文切换和GC。在容器化环境中还要考虑容器的CPU限制。如果容器只分配了4核Slot数设为8就会导致严重的CPU争抢。8.3 重启策略生产环境必须配置生产环境一定要配置重启策略。推荐使用失败率重启在指定时间窗口内允许一定次数的失败超过则作业彻底失败。这样既能应对偶发故障又能避免无限重启。配置示例在flink-conf.yaml中restart-strategy: failure-rate restart-strategy.failure-rate.max-failures-per-interval: 3 restart-strategy.failure-rate.failure-rate-interval: 10 min restart-strategy.failure-rate.delay: 10 s这段配置的意思是10分钟内最多失败3次每次重启延迟10秒。超过3次则作业失败不再自动重启。8.4 监控指标调度相关的关键指标调度相关的监控指标包括numRunningJobs、numRegisteredTaskManagers、taskSlotsTotal、taskSlotsAvailable、numTaskManagersConnected等。这些指标可以反映集群资源和作业调度的健康度。建议对taskSlotsAvailable设置告警如果持续为0说明资源紧张需要扩容。对numRunningJobs设置告警如果作业数突增可能是异常提交。9. 写在最后调度是理解Flink的钥匙我刚开始学Flink的时候总觉得调度是“底层细节”先把API用熟再说。直到有一次作业卡在SCHEDULED状态整整两个小时排查了半天才发现是Slot共享组配置冲突从那以后我才真正重视调度这块。调度过程串联了Flink的几乎所有核心概念JobGraph、ExecutionGraph、Slot、Checkpoint、重启策略、反压。理解调度就相当于拿到了理解Flink运行时的钥匙。遇到问题时你能从“作业为什么跑不起来”一路追到“Slot为什么分配不出去”而不是盲目重启或调参。最后分享一个我常用的排查套路遇到调度问题先看Web UI的Job Detail页面确认卡在哪个状态再看JobManager日志找异常最后看TaskManager日志确认资源情况。三步下来大部分问题都能定位。如果还不行就把ExecutionGraph的状态流转打印出来对照本文的状态机一步步排查。这个套路帮我省下了无数个加班的夜晚希望对你也有用。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
