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 嵌套写法（更像“配置树”）
restart-strategy:type:failure-ratefailure-rate:delay:1 sfailure-rate-interval:1 minmax-failures-per-interval:12.2 扁平写法（老习惯也能用）
restart-strategy.type:failure-raterestart-strategy.failure-rate.delay:1 srestart-strategy.failure-rate.failure-rate-interval:1 minrestart-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/下执行：
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.sizetaskmanager.memory.process.size
它们是“进程总内存”，Flink 会在里面再切分 heap、off-heap、network、managed 等。复杂作业默认值往往偏小，容易：
- 吞吐上不去
- RocksDB 状态膨胀导致反复 GC/抖动
- checkpoint 慢、背压严重
5.3 并行度与 Slots
taskmanager.numberOfTaskSlots：每个 TM 提供多少 slotparallelism.default：没显式指定并行度时的默认值
经验上：
- 想要隔离好：多起 TM、每个 TM 少 slot
- 想要资源利用率高：少起 TM、每个 TM 多 slot（但 JVM 内会更“热闹”，互相影响更大）
5.4 Checkpointing 默认值（不给代码配也能兜底）
你可以在集群配置里给“默认 checkpoint 行为”：
state.backend.type：hashmap / rocksdb / forstexecution.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）：
restart-strategy:type:failure-ratefailure-rate:delay:10 sfailure-rate-interval:5 minmax-failures-per-interval:3核心思路：外部系统抖一下（Kafka、ES、DB）别把你作业直接判死刑，但也别无限重启打爆依赖。
7. 最容易踩爆集群的 8 个坑（强烈建议收藏）
- config.yaml出现重复 key：直接启动失败
- YAML 字符串包含特殊字符没加引号：解析失败或值被截断
env.java.home用了嵌套写法：可能不生效（它要求扁平 key-value）rest.address没配但你又不是 HA：外部根本连不上 UI/RESTtaskmanager.memory.process.size太小：吞吐、checkpoint、RocksDB 全面受害taskmanager.numberOfTaskSlots乱配：要么资源浪费，要么 JVM 互相干扰严重- checkpoint 目录不可达/权限不足：作业跑着跑着突然 checkpoint 连续失败触发 failover
io.tmp.dirs放在会被清理的目录：一次清理=一次重灾难恢复
8. 一份“能直接用”的 config.yaml 模板（偏通用）
你可以拿这个做基线，再按你环境改路径与内存：
# 基础连通rest.address:flink-jm-hostrest.port:8081jobmanager.rpc.address:flink-jm-hostjobmanager.rpc.port:6123# 资源与并行taskmanager.numberOfTaskSlots:4parallelism.default:4# 进程内存（示例，按机器改）jobmanager.memory.process.size:2gtaskmanager.memory.process.size:8g# 临时目录（强烈建议显式设置）io.tmp.dirs:/data/flink/tmp# 状态与 checkpoint（示例：filesystem + rocksdb）state.backend.type:rocksdbexecution.checkpointing.storage:filesystemexecution.checkpointing.dir:"hdfs://namenode:8020/flink/checkpoints"execution.checkpointing.savepoint-dir:"hdfs://namenode:8020/flink/savepoints"execution.checkpointing.interval:30 sexecution.checkpointing.timeout:10 minexecution.checkpointing.num-retained:3# 重启策略restart-strategy:type:exponential-delayexponential-delay:initial-backoff:5 smax-backoff:5 minbackoff-multiplier:1.5jitter-factor:0.19. 你接下来怎么用这份内容写“更强的生产配置”？
如果你的作业属于以下类型，我建议你在这份基线之上继续加：
- 大状态（RocksDB/ForSt）：关注 managed memory、RocksDB 内存管理、localdir、IO 目录
- 背压明显：考虑 unaligned checkpoint（前提：Exactly Once + 并发 checkpoint=1）
- 多租户/平台化：规范 per-job 配置方式（
FLINK_CONF_DIR/ Docker 的FLINK_PROPERTIES），并把“危险参数”收口
