Flink Standalone 从 0 到可运维的 Session/HA 集群模板（附配置清单）

1. Standalone 是什么，适合什么场景

Standalone 是最“裸”的部署方式：Flink 组件（JobManager、TaskManager）在操作系统上以进程形式运行，不依赖 Kubernetes/YARN 这种资源调度平台。
它的优点是简单、透明、易调试；缺点是资源伸缩、故障重启需要你自己负责（通常交给 systemd/进程守护、或者外部运维系统）。

典型适用场景：

• 小中规模集群（几台到几十台机器）
• 运维系统成熟，能做进程守护、日志采集、告警
• 需要强可控、少依赖的部署环境（内网/离线）

2. 生产化落地前先做“规划三件套”

在你改配置之前，先把这三件事定下来，后面所有参数都会顺：

1）端口规划
2）资源与并行度规划（CPU/内存/Slots/并行度）
3）状态与数据落盘规划（Checkpoint/Savepoint、TMP 目录、RocksDB）

3. 必改文件清单：只动这几个就够了

• conf/flink-conf.yaml：核心配置（端口、资源、Checkpoint、HA、JVM）
• conf/masters：JobManager 列表（HA 场景写多个）
• conf/workers：TaskManager 机器列表
• conf/log4j.properties：日志级别与滚动策略（至少确认滚动开启）
• （可选）conf/zoo.cfg：你用 Flink 自带脚本起 ZK 时需要

4. 端口规划：把“不确定”变成“固定可控”

建议你为每类端口制定固定值或范围，这样：

• 防火墙/安全组容易放行
• 排障时不用猜
• 多实例不会互相抢端口

建议示例：

• Web UI：rest.port固定（JM 多实例就 masters 里写不同端口）
• RPC/数据：固定或范围化
• Metrics：固定（接 Prometheus/InfluxDB 时尤其重要）

推荐一组常用值：

• rest.port: 8081（第二个 JM 用 8082）
• jobmanager.rpc.port: 6123
• taskmanager.rpc.port: 6122
• taskmanager.data.port: 20000-20100

5. 核心配置模板：flink-conf.yaml（Session Mode 生产版）

下面这份是“稳健默认值”，你只需要替换：

• jobmanager.rpc.address/rest.address
• state.checkpoints.dir/state.savepoints.dir
• JobManager/TaskManager 进程内存
• Slots / 并行度

# ======================# 基础：集群标识与地址# ======================jobmanager.rpc.address:master1rest.address:master1rest.port:8081# ======================# 并行度与 Slots（核心）# ======================parallelism.default:8taskmanager.numberOfTaskSlots:4# ======================# 内存（Flink 2.x 推荐用 process.size）# ======================jobmanager.memory.process.size:2gtaskmanager.memory.process.size:8g# 网络内存（吞吐/Shuffle 相关，按需调整）taskmanager.memory.network.fraction:0.1taskmanager.memory.network.min:256mbtaskmanager.memory.network.max:1gb# ======================# Checkpoint（流作业建议必配）# ======================state.backend.type:rocksdbstate.checkpoints.dir:hdfs:///flink/checkpointsstate.savepoints.dir:hdfs:///flink/savepointsexecution.checkpointing.interval:60sexecution.checkpointing.timeout:10minexecution.checkpointing.min-pause:15sexecution.checkpointing.max-concurrent-checkpoints:1# ======================# 重启策略（按需）# ======================restart-strategy.type:fixed-delayrestart-strategy.fixed-delay.attempts:10restart-strategy.fixed-delay.delay:10s# ======================# JVM 与诊断（生产强烈建议开启）# ======================env.java.opts.all:>-XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/flink/heapdump -XX:ErrorFile=/data/flink/hs_err_pid%p.log -Dfile.encoding=UTF-8# ======================# 本地临时目录（非常关键！）# ======================io.tmp.dirs:/data/flink/tmp

5.1 Slots/并行度怎么定（不纠结版）

• 单台 TM 的 Slots：一般接近 CPU 核数的 1/2～1 倍（看作业 CPU 密集程度）
• 默认并行度：先按“总 Slots”给一个合理值（比如总 slots=24，先用 16 或 24）

经验法则：

• 吞吐型 ETL（轻 join、轻聚合）：并行度可以更高
• 大状态（窗口聚合、TopN、维表 join）：并行度别盲目拉高，先观察 checkpoint 与 RocksDB

6. masters/workers：从单机到分布式只改两份文件

单 JobManager：
conf/masters

master1:8081

高可用双 JobManager：
conf/masters

master1:8081 master2:8082

TaskManager 列表：
conf/workers

worker1 worker2 worker3

注意：用脚本远程拉起，需要免密 SSH + 目录结构一致。

7. Standalone HA（ZooKeeper）配置模板（可选但推荐）

如果你上生产，强烈建议开启 HA：至少能在 JobManager 故障时自动恢复。

在conf/flink-conf.yaml追加：

high-availability.type:zookeeperhigh-availability.zookeeper.quorum:zk1:2181,zk2:2181,zk3:2181high-availability.zookeeper.path.root:/flinkhigh-availability.cluster-id:/prod_cluster_ahigh-availability.storageDir:hdfs:///flink/ha# 建议固定或范围化 HA 端口，便于防火墙high-availability.jobmanager.port:50000-50025

启动顺序建议：
1）确保 ZooKeeper 集群健康
2）启动 Flink：./bin/start-cluster.sh
3）做一次切主演练：kill 掉 leader JM，观察 standby 是否接管（Web UI 与日志双确认）

8. 日志与排障：别等“磁盘满了”才想起来

生产上你至少要确认两点：
1）日志滚动策略开启（log4j 配置）
2）日志目录落在大盘（不要系统盘）

排障时常用的日志级别建议：

• 默认：INFO
• 临时排查 SQL/连接器：对特定包调 DEBUG（排查完立刻改回）

常见排查包：

• SQL 相关：org.apache.flink.table
• 连接器相关：org.apache.flink.connector

9. 运维自检清单（上线前照着过一遍）

端口与网络：

• JM/TM/WebUI/数据端口是否放行（防火墙/安全组）

磁盘与目录：

• io.tmp.dirs是否在大盘、空间足够
• RocksDB 状态盘是否稳定（最好 SSD）
• heapdump/hs_err 输出目录存在且可写

状态存储：

• state.checkpoints.dir必须是可靠存储（HDFS/S3/共享 FS）
• checkpoint 是否能正常落盘、恢复

时钟与时区：

• 全机器 NTP 同步
• session 时区一致（避免 watermark/分区时间偏移）

类路径与依赖：

• 连接器 jar 是否统一放置（lib/或usrlib/），避免版本冲突
• 作业提交 jar 是否包含不该打包的依赖（尤其 hive/hadoop 依赖）

10. 和你前面 Connector 体系的“推荐落地姿势”

你整理了很多 SQL Connector（DataGen/Print/BlackHole/FileSystem/Hive/ES/OpenSearch/HBase）。生产上非常建议按以下方式搭建“最短闭环”：

• 正确性验证：DataGen/Kafka -> Print
  用 Print 看 RowKind（+I/+U/-D）和字段是否符合预期

• 性能压测：DataGen/Kafka -> BlackHole
  用 BlackHole 逼出算子上限，快速定位瓶颈在 source / join / agg / sink

• 实时数仓落地：Kafka -> FileSystem/Hive
  配合分区提交（success-file / metastore）让下游可稳定消费

• 检索/分析落地：Kafka -> Elasticsearch/OpenSearch
  有主键走 upsert，无主键走 append（避免 update/delete 语义不一致）

• 维表场景：Hive/HBaselookup / temporal join
  强烈注意 cache、刷新间隔、内存占用上限（slot 内存装不下会直接翻车）

11. 结语

Standalone 并不是“低配玩法”，只要你把端口、资源、状态、日志这四件事做扎实，它完全可以跑得很稳定，尤其适合对环境掌控要求高、依赖越少越好的生产集群。

如果你愿意再贴两项信息：

• 你的机器规模（几台、每台 CPU/内存/磁盘）
• 主要作业类型（重 join/重状态/ES sink/Hive sink 哪类）