核心内容摘要
Python requests 完整使用教程（从入门到企业级用法）
弹性伸缩到底解决什么问题核心问题不是“能不能调并发”而是“资源经常不稳定”提交时集群 slot 不够以前要么卡住、要么失败、要么你手动降并发重提运行中 TaskManager 掉线默认调度器可能触发失败/重启策略而自适应调度器可以先自动缩容保证作业继续跑负载变化输入速率变高/变低理想情况是作业能自动吃满资源或释放资源而不用你做编排
Adaptive SchedulerStreaming怎么工作Adaptive Scheduler 的核心能力根据可用 slots 动态调整作业并发度。
1 基本行为如果 slot 不够跑满你配置的并发它会自动降低并发让作业先跑起来运行中新增 slot它会自动提升并发直到达到你配置的并发上限对 TaskManager 丢失更“抗打”掉了就缩容继续跑不是硬等资源或频繁失败
2 背后的关键声明式资源管理Declarative Resource Management传统模式是“我要 N 个 slot”。
自适应调度器更像“我希望拿到这些资源上限/边界”由 ResourceManager 尽力满足。
更进一步当 JobMaster 在运行时拿到更多资源会自动用最近可用的状态点最新 savepoint/最新 checkpoint 语义上取决于模式触发 rescale减少外部编排依赖。
Reactive Mode让作业永远“吃满整个集群”Reactive Mode 是 Adaptive Scheduler 的一个特殊模式假设单集群单作业通常用 Application Mode 强制。
1 Reactive Mode 的特点忽略你提交时配置的 parallelism把它当成“无穷大”作业永远使用集群当前所有可用资源加 TaskManager ⇒ 自动扩容减 TaskManager ⇒ 自动缩容
2 为什么它特别适合做自动扩缩Reactive Mode 的 rescale 事件会重启作业并从最新完成的 checkpoint恢复不需要额外触发 savepoint省掉人工 rescale 的典型步骤rescale 后会重放多少数据取决于 checkpoint 间隔恢复耗时和状态大小强相关因此最常见的“自动扩缩”组合是外部系统只管增减 TaskManagerK8S 副本数、云上 ASG 等Flink 自己负责把并发调到“当前资源下能跑到的最大值”并保证状态恢复
Externalized Declarative Resource Management给运行中作业“重新声明资源需求”Flink
18从 Flink
1.
x 开始如果你希望 Adaptive Scheduler 能响应“输入速率变化/工作负载变化”而做更智能的 rescale仅靠 slot 变化可能不够需要用外部化声明式资源管理在运行时重新声明资源边界。
这是一个 MVP 特性社区希望用户反馈。
它提供了一个 REST API可以对运行中的 job 做“按 vertex 维度”的并发上下界声明效果上很像“在线 rescale 控制面”。
1 REST API 示例接口PUT /jobs/job-id/resource-requirements请求体按 vertex id 设置并发上下界{first-vertex-id:{parallelism:{lowerBound:3,upperBound:5}},second-vertex-id:{parallelism:{lowerBound:2,upperBound:3}}}你可以用 curl 这样调用示例curl-X PUThttp://jm-host:8081/jobs/job-id/resource-requirements\-HContent-Type: application/json\-d{ vertex-1: {parallelism: {lowerBound: 4, upperBound: 16}}, vertex-2: {parallelism: {lowerBound: 2, upperBound: 8}} }实际体验上它也被 UI 暗示成“缩放按钮”你在 Flink Web UI 的 Job Overview 里可以尝试 up-scale/down-scale。
2 两个典型使用场景Session Cluster多作业抢资源需要更细粒度地控制每个作业拿到多少Application Cluster Active Resource Manager例如某些场景下依赖 Flink 去“贪婪拉起 TaskManager”你仍然希望拥有类似 Reactive Mode 的 rescale 能力如果你希望一站式自动伸缩体验文档也提到可结合 Apache Flink Kubernetes Operator 来做。
如何启用 Adaptive Scheduler在集群级别切换调度器替代默认 schedulerjobmanager.scheduler:adaptiveAdaptive Scheduler 的相关参数都以jobmanager.adaptive-scheduler.*为前缀。
重要提醒Adaptive Scheduler 仅适用于 Streaming 作业提交 Batch 作业时Flink 会走 Batch 的默认调度器通常是 Adaptive Batch Scheduler
Reactive Mode 快速上手本机单机演示下面是文档里的演示流程Application Mode1把示例作业放进 libcp./examples/streaming/TopSpeedWindowing.jar lib/2以 Reactive Mode 启动 standalone application并设置 checkpoint./bin/standalone-job.sh start\-Dscheduler-modereactive\-Dexecution.checkpointing.interval10s\-j org.apache.flink.streaming.examples.windowing.TopSpeedWindowing3启动第一个 TaskManager./bin/taskmanager.sh start扩容再启动一个 TaskManager./bin/taskmanager.sh start缩容停止一个 TaskManager./bin/taskmanager.sh stop你会看到作业随着 TaskManager 数量变化发生 rescale触发重启并从最新 checkpoint 恢复。
关键配置与生产建议
1 必须配置 checkpoint尤其有状态作业Reactive Mode 的 rescale 是从最新完成 checkpoint 恢复不开 checkpoint状态丢失风险很高checkpoint 也决定重启策略如果没配置重启策略Reactive Mode 可能直接 fail 而不是“缩放继续跑”
2 资源等待与稳定窗口避免频繁重启Reactive Mode 下默认行为很“激进”jobmanager.adaptive-scheduler.resource-wait-timeout默认 -1永远等资源jobmanager.adaptive-scheduler.resource-stabilization-timeout默认 0资源一到就立刻调度问题TaskManager 如果是一个个慢慢连进来就会导致“每来一个 TM 就重启一次”。
对策增大resource-stabilization-timeout等资源稳定后再跑配置jobmanager.adaptive-scheduler.min-parallelism-increase只有并发提升达到一定幅度才触发扩容重启用jobmanager.adaptive-scheduler.scaling-interval.min控制两次缩放的最小间隔默认 30s必要时用jobmanager.adaptive-scheduler.scaling-interval.max强制在一定时间后触发一次缩放默认关闭
3 下缩可能“卡 50 秒”心跳超时导致的等待如果缩容时 TaskManager 被不优雅杀掉SIGKILL 而不是 SIGTERMFlink 需要等心跳超时才确认它离线常见会卡一段时间文档提到大约 50 秒。
可以调低heartbeat.timeout但要谨慎心跳 timeout 太低在网络抖动或长 GC 时可能误判 TM 失联导致不必要的重启同时确保heartbeat.interval heartbeat.timeout
4 并发影响方式只能用 maxParallelism 施加上限Reactive Mode 下你显式 set 的 parallelism 会被忽略。
你能影响的主要是作业/算子maxParallelism上限 2^15 32768但 maxParallelism 设得太高会增加内部结构维护成本性能可能变差。
建议按业务可接受的扩展上限设置不要无脑拉满。