Flink Window Join 和 Interval Join 怎么选？
面试怎么回答
我先看业务是共同时间桶还是事件相对时间。按固定 5 分钟、1 小时核算，使用 Window Join；围绕左流事件匹配前后某个时间范围，使用 Interval Join。还要明确窗口或区间边界、Event Time 与 Watermark，并评估区间长度、热点 Key 对状态规模的影响。例如点击后 30 分钟下单应使用 Interval Join，避免跨窗口后无法匹配。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多人会回答：
“一个按窗口 Join，一个按时间范围 Join。”
这只是定义。真正做选型时，要看业务关系是“落在同一时间桶”，还是“围绕每条左流事件寻找相对时间范围内的右流事件”。
Window Join 先划共同窗口，Interval Join 先定义两条事件之间允许的时间差。
Window Join：同一个窗口内匹配
两条流先按 Key 分组，再分配到相同类型、相同大小的 Window 中。只有 Key 相同且落在同一个窗口的记录才会组合。
适合：
- 每 5 分钟汇总一次曝光与点击
- 按小时关联两条流的窗口结果
- 业务本身就以固定时间桶核算
需要注意窗口边界。两条时间很接近的事件，如果恰好落在相邻窗口，也不会匹配。
Interval Join：按事件相对时间匹配
Interval Join 同样要求两条流先 keyBy，但它围绕左流每条事件定义一个时间区间：
left.timestamp + lowerBound
≤ right.timestamp
≤ left.timestamp + upperBound适合：
- 点击后 30 分钟内是否下单
- 请求前后几秒内关联响应
- 行为发生后一定时间内匹配结果事件
当前 DataStream Interval Join 基于 Event Time，并且是 Inner Join 语义；上下界默认包含边界，也可以显式排除。
选型时看四个维度
业务时间关系
固定周期统计选 Window Join；围绕单条事件定义前后关系，选 Interval Join。
边界语义
Window Join 受窗口切分影响；Interval Join 受上下界影响。两者都必须用业务规则说明边界，而不是随便定一个时间。
乱序与等待
两种 Join 都依赖正确的 Event Time 和 Watermark 推进。Watermark 太激进会让迟到事件错过匹配，太保守则会增加状态保留和结果等待。
状态规模
时间范围越大、Key 越集中、流量越高，需要保留的待匹配记录越多。选型不能只看 API，还要估算每个 Key 的事件量和清理时机。
一个典型反例
比如要判断点击后 30 分钟内是否产生订单，却使用 30 分钟滚动 Window Join。
点击发生在 10:29，订单发生在 10:31。两条记录只相差 2 分钟，却落在两个窗口，最终无法匹配。
这个业务关系不是“同一个半小时窗口”，而是“订单时间位于点击后 0～30 分钟”。使用 Interval Join 才符合真实语义。
时间接近，不代表一定落在同一个窗口。