Flink 任务失败恢复机制Restart Strategy 和 Failover Strategy 怎么配才“又稳又不炸”
1. Restart Strategy：失败后怎么重启
1.1 默认行为到底是什么
- 没开 checkpoint：默认就是不重启（disable / none） (nightlies.apache.org)
- 开了 checkpoint 且你没显式配置：默认使用exponential-delay（指数退避），并采用它相关参数的默认值 (nightlies.apache.org)
这个“默认指数退避”非常关键，因为它本质是在帮你避免外部系统故障时的“雪崩式重启风暴”（比如 Kafka 挂了，上百个 Flink 作业同时 1 秒一次狂重启，把 Kafka 彻底打穿）。官方也明确强调指数退避 + jitter（抖动）能让多个作业错峰重启，降低雪崩风险。 (nightlies.apache.org)
1.2 四类常用策略怎么选
A. fixed-delay（固定间隔重启）
适合：明确知道外部系统需要“冷却时间”（例如下游连接要等超时释放、事务要等回滚完成），希望每次都固定等一段时间再起。 (nightlies.apache.org)
典型配置（集群默认，flink-conf.yaml）：
restart-strategy.type:fixed-delayrestart-strategy.fixed-delay.attempts:3restart-strategy.fixed-delay.delay:10 s含义：最多 3 次，每次失败后等 10 秒再起。 (nightlies.apache.org)
B. failure-rate（失败率控制）
适合：你允许偶发失败快速恢复，但如果“单位时间内失败太多”，就直接让作业失败（避免无限重启掩盖真实问题）。 (nightlies.apache.org)
典型配置：
restart-strategy.type:failure-raterestart-strategy.failure-rate.max-failures-per-interval:3restart-strategy.failure-rate.failure-rate-interval:5 minrestart-strategy.failure-rate.delay:10 sC. exponential-delay（指数退避，生产强推）
适合：绝大多数流式作业的默认选择。偶发故障时能很快恢复；连续故障时逐步拉长间隔，避免压垮外部系统；还能用 jitter 做错峰。 (nightlies.apache.org)
关键参数（你最常会调的）：
initial-backoff：第一次重启等待多久backoff-multiplier：每次失败等待时间按倍率增长max-backoff：最大等待上限reset-backoff-threshold：作业稳定运行多久后，把退避重置回初始值jitter-factor：抖动比例（强烈建议别设 0） (nightlies.apache.org)
示例（比较“通用”的生产口味）：
restart-strategy.type:exponential-delayrestart-strategy.exponential-delay.initial-backoff:10 srestart-strategy.exponential-delay.max-backoff:2 minrestart-strategy.exponential-delay.backoff-multiplier:1.4restart-strategy.exponential-delay.reset-backoff-threshold:10 minrestart-strategy.exponential-delay.jitter-factor:0.1restart-strategy.exponential-delay.attempts-before-reset-backoff:10(nightlies.apache.org)
D. none/disable（不重启）
适合：确定是“逻辑 bug / 配置错误 / 数据不可恢复坏数据”，重启也只会反复失败，干脆失败后报警，避免消耗资源与污染外部系统。 (nightlies.apache.org)
1.3 集群默认 vs 作业级覆盖（推荐做法）
- 集群层面：给一个“不会雪崩”的默认（通常 exponential-delay）
- 作业层面：对少数特殊作业（强依赖外部事务、非常敏感的 SLA 作业）单独覆盖策略
作业级（Java）示例，固定延迟：
Configurationconfig=newConfiguration();config.set(RestartStrategyOptions.RESTART_STRATEGY,"fixed-delay");config.set(RestartStrategyOptions.RESTART_STRATEGY_FIXED_DELAY_ATTEMPTS,3);config.set(RestartStrategyOptions.RESTART_STRATEGY_FIXED_DELAY_DELAY,Duration.ofSeconds(10));StreamExecutionEnvironmentenv=StreamExecutionEnvironment.getExecutionEnvironment(config);(nightlies.apache.org)
2. Failover Strategy：这次失败要重启哪些 task
Restart Strategy 决定“怎么重启”，Failover Strategy 决定“重启范围”。
Flink 支持两种 failover 策略，通过jobmanager.execution.failover-strategy配置： (nightlies.apache.org)
full：重启整个作业所有 taskregion：重启pipelined region（最小必要重启集合） (nightlies.apache.org)
2.1 full：简单粗暴，代价大
优点：逻辑简单，恢复路径最“直觉”。
缺点：哪怕只是一个小算子失败，也可能把全图都拉起来重启，恢复冲击更大。 (nightlies.apache.org)
2.2 region：只重启必要的那一片（生产常用）
region 策略会把作业图划分为多个“互不重叠的 region”。当某个 task 失败时，它会计算最小需要重启的 region 集合来保证一致性，通常能比 full 少重启很多 task。 (nightlies.apache.org)
region 的边界定义很关键：
- region 是一组通过pipelined 数据交换通信的 tasks
- batch 数据交换会成为 region 的边界 (nightlies.apache.org)
并且 DataStream/Table/SQL 的交换方式与ExecutionMode有关：Streaming 模式下是 pipelined，Batch 模式默认是 batched。 (nightlies.apache.org)
region 策略的“重启扩散规则”是：
- 必重启：失败 task 所在 region
- 如果某个 region 需要的结果分区不可用，则把生产该分区的 region 也重启
- 只要某个 region 要重启，它的所有 consumer regions 也要重启，以保证一致性（尤其是非确定性处理/分区可能导致分区结果变化） (nightlies.apache.org)
3. 一套拿来就能用的生产配置模板
3.1 flink-conf.yaml（集群默认）
适用于大多数流作业：
restart-strategy.type:exponential-delayrestart-strategy.exponential-delay.initial-backoff:5 srestart-strategy.exponential-delay.max-backoff:2 minrestart-strategy.exponential-delay.backoff-multiplier:1.5restart-strategy.exponential-delay.reset-backoff-threshold:10 minrestart-strategy.exponential-delay.jitter-factor:0.1jobmanager.execution.failover-strategy:region指数退避避免雪崩，region 减少重启范围，是非常稳的一组默认组合。 (nightlies.apache.org)
3.2 什么时候别用“无限重启”
如果是确定性的逻辑错误、配置错误、或坏数据必炸，建议：
- 用
failure-rate限制单位时间重启次数，或者 - 直接
none失败报警
防止“作业看起来一直在跑，但其实在循环重启”。 (nightlies.apache.org)
4. 排障小抄：看到这些现象该往哪查
- 短时间大量作业一起重启：优先检查是否外部依赖故障（Kafka/HDFS/DB），并确认指数退避 + jitter 是否启用、参数是否过激（initial 太小、jitter=0）。 (nightlies.apache.org)
- 单个算子失败导致全图反复重启：确认 failover 是否还是
full，能否切到region降低冲击。 (nightlies.apache.org) - 恢复后数据一致性问题：关注 region 重启的 consumer 扩散逻辑与作业里是否存在非确定性处理/分区（region 策略会主动扩大重启范围就是为了这个）。 (nightlies.apache.org)