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-delay
restart-strategy.fixed-delay.attempts: 3
restart-strategy.fixed-delay.delay: 10 s

含义：最多 3 次，每次失败后等 10 秒再起。 (nightlies.apache.org)

B. failure-rate（失败率控制）

适合：你允许偶发失败快速恢复，但如果“单位时间内失败太多”，就直接让作业失败（避免无限重启掩盖真实问题）。 (nightlies.apache.org)

典型配置：

restart-strategy.type: failure-rate
restart-strategy.failure-rate.max-failures-per-interval: 3
restart-strategy.failure-rate.failure-rate-interval: 5 min
restart-strategy.failure-rate.delay: 10 s

C. 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-delay
restart-strategy.exponential-delay.initial-backoff: 10 s
restart-strategy.exponential-delay.max-backoff: 2 min
restart-strategy.exponential-delay.backoff-multiplier: 1.4
restart-strategy.exponential-delay.reset-backoff-threshold: 10 min
restart-strategy.exponential-delay.jitter-factor: 0.1
restart-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）示例，固定延迟：

Configuration config = new Configuration();
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));
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(config);

(nightlies.apache.org)

2. Failover Strategy：这次失败要重启哪些 task

Restart Strategy 决定“怎么重启”，Failover Strategy 决定“重启范围”。

Flink 支持两种 failover 策略，通过 jobmanager.execution.failover-strategy 配置： (nightlies.apache.org)

• full：重启整个作业所有 task
• region：重启 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 策略的“重启扩散规则”是：

1. 必重启：失败 task 所在 region
2. 如果某个 region 需要的结果分区不可用，则把生产该分区的 region 也重启
3. 只要某个 region 要重启，它的所有 consumer regions 也要重启，以保证一致性（尤其是非确定性处理/分区可能导致分区结果变化） (nightlies.apache.org)

3. 一套拿来就能用的生产配置模板

3.1 flink-conf.yaml（集群默认）

适用于大多数流作业：

restart-strategy.type: exponential-delay
restart-strategy.exponential-delay.initial-backoff: 5 s
restart-strategy.exponential-delay.max-backoff: 2 min
restart-strategy.exponential-delay.backoff-multiplier: 1.5
restart-strategy.exponential-delay.reset-backoff-threshold: 10 min
restart-strategy.exponential-delay.jitter-factor: 0.1

jobmanager.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)