Flink核心部件和坑点
🔧 三个核心部件（人话版）
| 部件 | 你叫它 | 干嘛的 | 对应你的 Java 程序 |
|---|---|---|---|
| JobManager | 总管/调度员 | 决定谁干什么、什么时候存档（Checkpoint）、崩了怎么重启 | 你代码里的 main 方法 + 定时任务调度器 |
| TaskManager | 工人/执行器 | 实际干活的机器（读数据、转换、写入），一台电脑可以跑多个工人 | 你代码里处理数据的 while 循环 + 线程池 |
| State | 工作台/暂存区 | 记录处理到哪儿了（如当前计数、去重集合） | 你代码里的 HashMap、offset 变量、Redis 缓存 |
💾 两种"工作台"（存状态的地方）
关键选择：数据放内存还是放硬盘？
| 类型 | MemoryStateBackend | RocksDBStateBackend |
|---|---|---|
| 存哪儿 | JVM 内存（电脑内存条） | 本地硬盘（SSD/机械硬盘） |
| 能存多少 | 几百 MB（大了就崩） | 几百 GB（硬盘多大存多大） |
| 速度 | 飞快（纳秒级） | 较快（微秒级，比内存慢100倍但比网络快） |
| 挂了怎么办 | 状态全丢（没存档的话） | 状态在硬盘，能找回来 |
| 适合场景 | 测试、小数据（<100万条） | 生产环境、大数据（千万级以上） |
你的迁移场景建议：
- 小表迁移（百万级以内）：用 Memory（简单快速）
- 大表迁移（千万级+）：必须用 RocksDB（否则内存爆掉）
⚠️ 四个必知坑点（血泪经验）
1. "存档别太快，也别太慢"
- 太快（每秒存档）：硬盘和网络被拖垮，迁移速度比蜗牛还慢
- 太慢（10分钟存档）：挂了要重跑10分钟数据，崩溃
- 黄金分割：30秒~2分钟一次（根据数据量调）
// 设置每 60 秒存档一次（单位毫秒）
env.enableCheckpointing(60000);
2. "网络不好时，存档会超时"
如果公司网络垃圾，存 HDFS 老是失败，要调大超时时间：
env.getCheckpointConfig().setCheckpointTimeout(10 * 60 * 1000); // 10分钟
3. "并行度别乱设"
- TaskManager 里的槽位（Slot） ：可以理解为"同时开几个线程跑"
- 坑：你设并行度=10，但只给了 2 个 Slot，那它只能串行跑，反而慢
- 建议：并行度 = CPU 核心数 × 2（比如 8 核机器设 16）
4. "数据倾斜会卡死"
- 现象：95% 的数据都去了 1 个 Worker，其他 Worker 闲死，这个 Worker 累崩
- 表现：迁移时突然某个 Task 爆红，进度卡死
- 解决：在 Key 上加随机前缀打散（如
user_id→random + user_id）
🎯 一句话记住 Flink
JobManager 是大脑（调度），TaskManager 是手脚（执行），RocksDB 是硬盘（存状态），Checkpoint 是自动保存（防崩溃）。
对比你现在的工作：
- 你现在用 Java 写迁移 = 手动挡汽车（自己挂档、自己踩刹车、自己记路）
- Flink = 自动挡汽车（你只要踩油门（写业务逻辑），它自动换挡（调度）、自动刹车（容错）、自动导航（状态恢复））
建议：先用 Flink 做一个小表迁移（Memory 模式），感受下"不用写事务控制代码"有多爽，再挑战大表（RocksDB 模式）。
