最近在调试 Flink 的事件时间窗口时，遇到了一个很“诡异”的现象：
- Kafka 数据源持续有数据输入
- 事件时间也是合理的、并且比系统当前时间还新
- 使用了
SlidingEventTimeWindows - 但窗口处理函数
process()一直不触发！
本文将详细记录问题的表现、分析过程、最终原因及解决方案。
🧪 现象回顾
我有一个如下的窗口代码：
behaviorStream
.keyBy(UserBehavior::getEventType)
.window(SlidingEventTimeWindows.of(Duration.ofSeconds(1), Duration.ofSeconds(1)))
.process(new ProcessWindowFunction<...>() {
@Override
public void process(...) {
LOG.info("数据进了窗口");
}
})
.print();
但运行 10 分钟后，依然毫无输出，日志里没有任何来自 process() 的记录。
✅ 检查点 1：事件时间 vs 当前时间
我在解析 JSON 时加入了调试日志：
long eventTime = rootNode.path("eventTimeEpoch").asLong();
long now = System.currentTimeMillis();
LOG.warn("事件时间={} 当前时间={} 差值={}ms", eventTime, now, eventTime - now);
日志输出类似于：
事件时间=1750912307859 当前时间=1750912307849 差值=+10ms
这说明我传入的事件时间确实非常接近（甚至略大于）当前系统时间。
❓ 这会是问题的原因吗？
不是！ Flink 是事件驱动的系统，事件时间大于系统时间是合法的。
- Flink 不关心系统时间；
- Flink 会以你提供的事件时间为准构建 Watermark；
- 即使事件时间是“未来”，Flink 会等 Watermark 达到窗口结束时间才触发。
这会 延迟触发，但不会 永远不触发。
✅ 检查点 2：Watermark 没有前进！
我们加上日志输出：
@Override
public void process(String key, Context context, Iterable<...>, Collector<...>) {
LOG.info("[Window Trigger] 当前 Watermark: {}", context.currentWatermark());
}
结果发现：Watermark 一直是 Long.MIN_VALUE！
说明 Flink 根本没有推进 Watermark，也就没有任何窗口被触发。
🧠 Watermark 是怎么工作的？
Flink 的全局 Watermark 是所有并行 Subtask 的最小值：
GlobalWatermark = min(Watermark of all Subtasks)
只要有一个 Subtask 没有发出有效 Watermark（仍然是默认值），全局就被它拖住。
✅ 最终发现：Kafka 分区数 < Flink Source 并行度
我使用的是：
- Kafka topic 分区数：3
- Flink Kafka Source 并行度：8（默认并行度）
这就意味着：
- 只有 3 个 Subtask 能真正消费数据
- 剩下的 5 个 Subtask 是“空转”的，但 Flink 并不知道它们“空闲”
- 它们的 Watermark 会一直卡在
Long.MIN_VALUE
于是：
全局 Watermark = min(Long.MIN_VALUE, ..., 正常时间戳) = Long.MIN_VALUE
任何窗口都无法触发！！
✅ 正确做法：告知 Flink 哪些 Subtask 已空闲
✅ 方法一：添加 .withIdleness(...)
WatermarkStrategy
.<String>forBoundedOutOfOrderness(Duration.ofSeconds(0))
.withTimestampAssigner(...)
.withIdleness(Duration.ofSeconds(10)) // 👈 设置 10 秒内无数据则认为“空闲”
这样，Flink 就不会让“空闲任务”的 Watermark 拖慢整体进度。
✅ 方法二：并行度 <= Kafka 分区数
你也可以设置 Flink Source 的并行度为 Kafka topic 的分区数：
env.setParallelism(3);
这样每个 Subtask 都有数据，不存在“拖后腿”的问题。
✅ 方法三：改为 ProcessingTime 窗口（不推荐）
如果你对事件时间没有要求，也可以改为 ProcessingTime：
.window(TumblingProcessingTimeWindows.of(Time.seconds(1)))
ProcessingTime 不依赖 Watermark，所以马上触发，但不具备“乱序容忍”能力。
🧾 总结一句话
Flink 中窗口不触发，绝大多数情况下都是 Watermark 没推进。只要有一个 Subtask 没收到数据，又没设置
.withIdleness()，你的窗口就永远卡死。
✅ 经验建议
| 建议 | 说明 |
|---|---|
| ✅ Kafka 分区数 ≥ Flink 并行度 | 避免空 Subtask |
✅ 一定设置 .withIdleness() |
保护窗口触发 |
| ✅ 打印 Watermark 观察推进情况 | 理解系统行为 |
| ✅ 不要随便让事件时间大于系统时间 | 会延迟窗口，影响实时性 |
希望本文能帮你解决 Flink Watermark 卡死问题！如果你有更深入的问题，欢迎留言交流。
---
如果你还想添加图示（比如 watermark 推进流程、Subtask-Watermark 最小值示意图），我可以帮你补上 SVG 图或 Mermaid 图。是否需要？