Flink 2.0 从 flink-conf.yaml 到 config.yaml 的正确打开方式（含迁移与最佳实践）

1. Flink 配置加载机制：你改了文件但没生效？很可能就卡在这里

Flink 会在 Flink 进程启动时解析配置（JobManager / TaskManager / HistoryServer 等进程启动时加载）。所以：

改 config.yaml 之后必须重启相关进程才会生效
仅靠"刷新 Web UI / 重提作业"通常不会重新加载 conf 里的配置

还有几个常见入口：

默认读取 $FLINK_HOME/conf/config.yaml
可以用环境变量指定配置目录：FLINK_CONF_DIR=/path/to/conf
Docker 部署可以用 FLINK_PROPERTIES 注入配置（注意不是所有部署模式都支持"复制 conf 目录做 per-job 配置"）

2. config.yaml 写法：嵌套（推荐） vs 扁平（兼容）

2.1 嵌套写法（更像"配置树"）

yaml 复制代码

restart-strategy:
  type: failure-rate
  failure-rate:
    delay: 1 s
    failure-rate-interval: 1 min
    max-failures-per-interval: 1

2.2 扁平写法（老习惯也能用）

yaml 复制代码

restart-strategy.type: failure-rate
restart-strategy.failure-rate.delay: 1 s
restart-strategy.failure-rate.failure-rate-interval: 1 min
restart-strategy.failure-rate.max-failures-per-interval: 1

两者等价，但注意一个非常关键的点：

某些配置（例如 env.java.home）要求必须是扁平格式（one-line key-value），否则可能不按预期生效

3. YAML 值类型：别再把一切都当字符串了

config.yaml 支持 YAML 1.2 的核心类型，最常用的你可以按下面记：

Boolean：true/false（大小写都行）
Integer/Long/Float/Double：正常数字写法
MemorySize：1536m、2g、100 mb
Duration：10 s、1 min、1 h
List：[a, b, c] 或 - a
Map：{k1: v1, k2: v2} 或缩进形式

字符串遇到特殊字符（比如 :、#、{}、[]、; 等）时，优先加引号，这是迁移后最常见的坑之一。

4. 从 flink-conf.yaml 迁移到 config.yaml：变化点与坑位清单

4.1 行为变化（非常要命）

重复 key 不允许

flink-conf.yaml：允许重复，取最后一个
config.yaml：直接报错，进程启动失败

无效配置不再被"悄悄忽略"

flink-conf.yaml：解析不了就当没看见
config.yaml：报错并终止加载

注释规则更严格

flink-conf.yaml：一行里第一个 # 后面全算注释
config.yaml：只有 # 前面是空格或行首时才算注释（否则 # 可能被当成字符串的一部分）

null 的表达更丰富

可以留空，也可以写 null/Null/NULL/~

4.2 官方迁移脚本（推荐走这条）

流程是：

把旧文件 flink-conf.yaml 放到 conf/ 目录
在 $FLINK_HOME/ 下执行：

bash 复制代码

bin/migrate-config-file.sh

它会生成新的 conf/config.yaml

注意：因为旧解析器把所有值都当字符串，迁移出来的很多值会带引号。但 Flink 后续会按 ConfigOption 的类型再做转换，通常没问题。

5. "基础必配"清单：Standalone / Session 集群最常改的几类

5.1 Host & Port

rest.address / rest.port：客户端/Web UI 连接 JobManager 用
jobmanager.rpc.address / jobmanager.rpc.port：TaskManager 找 JobManager 用（非 HA 场景更关键）
各种 *.bind-host、*.bind-port：你要绑定到 0.0.0.0 还是内网网卡，就靠它

5.2 内存（真正的性能开关）

入门建议先记住两条"总量"配置：

jobmanager.memory.process.size
taskmanager.memory.process.size

它们是"进程总内存"，Flink 会在里面再切分 heap、off-heap、network、managed 等。复杂作业默认值往往偏小，容易：

吞吐上不去
RocksDB 状态膨胀导致反复 GC/抖动
checkpoint 慢、背压严重

5.3 并行度与 Slots

taskmanager.numberOfTaskSlots：每个 TM 提供多少 slot
parallelism.default：没显式指定并行度时的默认值

经验上：

想要隔离好：多起 TM、每个 TM 少 slot
想要资源利用率高：少起 TM、每个 TM 多 slot（但 JVM 内会更"热闹"，互相影响更大）

5.4 Checkpointing 默认值（不给代码配也能兜底）

你可以在集群配置里给"默认 checkpoint 行为"：

state.backend.type：hashmap / rocksdb / forst
execution.checkpointing.interval：>0 才启用
execution.checkpointing.dir：checkpoint 目录（s3/hdfs/本地 fs URI）
execution.checkpointing.savepoint-dir：savepoint 默认目录

这套做法适合"平台化"：业务方写作业时不一定每个都手动配置 checkpoint，集群侧先兜住。

5.5 Web UI 行为

web.submit.enable：是否允许 UI 上传 jar 提交作业
web.cancel.enable：是否允许 UI cancel 作业
web.upload.dir：上传 jar 存储目录

企业环境经常把 web.submit.enable 关掉，只留 REST/CI 提交流程。

5.6 io.tmp.dirs：别用系统临时目录糊弄

io.tmp.dirs 影响非常多本地落盘内容：

RocksDB 文件
batch spill
缓存 jar

如果你用的是会被系统清理的临时目录，可能导致一次"删缓存"引发一次"重恢复"，性能直接跳水。建议显式指到稳定磁盘目录，并确保空间和 IO。

6. 容错重启策略：别让作业一挂就"瞬间去世"

Flink 的重启策略由 restart-strategy.type 控制，常用三种：

fixed-delay：固定间隔重试
failure-rate：单位时间内失败次数限制
exponential-delay：指数退避（checkpoint 开启时默认更倾向它）

一个偏稳健的示例（failure-rate）：

yaml 复制代码

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

核心思路：外部系统抖一下（Kafka、ES、DB）别把你作业直接判死刑，但也别无限重启打爆依赖。

7. 最容易踩爆集群的 8 个坑（强烈建议收藏）

config.yaml 出现重复 key：直接启动失败
YAML 字符串包含特殊字符没加引号：解析失败或值被截断
env.java.home 用了嵌套写法：可能不生效（它要求扁平 key-value）
rest.address 没配但你又不是 HA：外部根本连不上 UI/REST
taskmanager.memory.process.size 太小：吞吐、checkpoint、RocksDB 全面受害
taskmanager.numberOfTaskSlots 乱配：要么资源浪费，要么 JVM 互相干扰严重
checkpoint 目录不可达/权限不足：作业跑着跑着突然 checkpoint 连续失败触发 failover
io.tmp.dirs 放在会被清理的目录：一次清理=一次重灾难恢复

8. 一份"能直接用"的 config.yaml 模板（偏通用）

你可以拿这个做基线，再按你环境改路径与内存：

yaml 复制代码

# 基础连通
rest.address: flink-jm-host
rest.port: 8081
jobmanager.rpc.address: flink-jm-host
jobmanager.rpc.port: 6123

# 资源与并行
taskmanager.numberOfTaskSlots: 4
parallelism.default: 4

# 进程内存（示例，按机器改）
jobmanager.memory.process.size: 2g
taskmanager.memory.process.size: 8g

# 临时目录（强烈建议显式设置）
io.tmp.dirs: /data/flink/tmp

# 状态与 checkpoint（示例：filesystem + rocksdb）
state.backend.type: rocksdb
execution.checkpointing.storage: filesystem
execution.checkpointing.dir: "hdfs://namenode:8020/flink/checkpoints"
execution.checkpointing.savepoint-dir: "hdfs://namenode:8020/flink/savepoints"
execution.checkpointing.interval: 30 s
execution.checkpointing.timeout: 10 min
execution.checkpointing.num-retained: 3

# 重启策略
restart-strategy:
  type: exponential-delay
  exponential-delay:
    initial-backoff: 5 s
    max-backoff: 5 min
    backoff-multiplier: 1.5
    jitter-factor: 0.1

9. 你接下来怎么用这份内容写"更强的生产配置"？

如果你的作业属于以下类型，我建议你在这份基线之上继续加：

大状态（RocksDB/ForSt）：关注 managed memory、RocksDB 内存管理、localdir、IO 目录
背压明显：考虑 unaligned checkpoint（前提：Exactly Once + 并发 checkpoint=1）
多租户/平台化：规范 per-job 配置方式（FLINK_CONF_DIR / Docker 的 FLINK_PROPERTIES），并把"危险参数"收口