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 / 并行度

yaml 复制代码

# ======================
# 基础：集群标识与地址
# ======================
jobmanager.rpc.address: master1
rest.address: master1
rest.port: 8081

# ======================
# 并行度与 Slots（核心）
# ======================
parallelism.default: 8
taskmanager.numberOfTaskSlots: 4

# ======================
# 内存（Flink 2.x 推荐用 process.size）
# ======================
jobmanager.memory.process.size: 2g
taskmanager.memory.process.size: 8g

# 网络内存（吞吐/Shuffle 相关，按需调整）
taskmanager.memory.network.fraction: 0.1
taskmanager.memory.network.min: 256mb
taskmanager.memory.network.max: 1gb

# ======================
# Checkpoint（流作业建议必配）
# ======================
state.backend.type: rocksdb
state.checkpoints.dir: hdfs:///flink/checkpoints
state.savepoints.dir: hdfs:///flink/savepoints

execution.checkpointing.interval: 60s
execution.checkpointing.timeout: 10min
execution.checkpointing.min-pause: 15s
execution.checkpointing.max-concurrent-checkpoints: 1

# ======================
# 重启策略（按需）
# ======================
restart-strategy.type: fixed-delay
restart-strategy.fixed-delay.attempts: 10
restart-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 追加：

yaml 复制代码

high-availability.type: zookeeper
high-availability.zookeeper.quorum: zk1:2181,zk2:2181,zk3:2181
high-availability.zookeeper.path.root: /flink
high-availability.cluster-id: /prod_cluster_a
high-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/HBase lookup / temporal join

强烈注意 cache、刷新间隔、内存占用上限（slot 内存装不下会直接翻车）

11. 结语

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

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

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