考察点
双流 Join 是实时宽表的核心操作，也是状态膨胀的重灾区。面试官想听到：Join 的双侧缓存机制、为什么普通 Join 的状态理论上无限大、TTL 靠什么依据来定。追问会往 left join 的回撤语义、Join 不上怎么办、大状态优化走。
参考答案
实现机制：双侧缓存，互相探测
两条流 keyBy 同一个 Join key 之后进入同一个 Join 算子。核心思想是：每条流都把自己的数据按 key 存进状态，同时拿这条数据去对方的状态里探测匹配。
左流来一条订单数据：先把订单存进左侧状态（keyed state），然后遍历右侧状态里同 key 的支付数据，每匹配到一条就向下游发一条 Join 结果。右流来支付数据时对称操作。所以「Join 是双边都有状态的」，任何一侧的数据都要等对方「未来可能到达」的匹配数据——这就是普通 inner join 状态无限膨胀的根源：你永远不知道某个 key 的另一半明天会不会来，只能一直存着。
三种 Join 形态
- 普通 Join（Regular Join，Table API 的
join）：不限制时间范围，状态必须配 TTL 兜底，否则必然撑爆。输出带回撤语义（+I/-U/+U/-D），下游必须能处理 changelog。 - 时间间隔 Join（Interval Join）：
a.time between b.time - 10min and b.time + 5min这类，Join 条件里带时间边界，Flink 能推导出状态只需保留边界内的数据，自动过期清理。能用 interval join 就别用普通 join，这是最重要的工程结论。 - 窗口 Join（Window Join）：两条流按相同窗口划分，窗口内配对，窗口触发时输出，状态随窗口清理。语义最清晰，但要求两边的时间对齐到同一窗口，适用面窄。
TTL 怎么定
这是面试的必考追问，答案要讲依据而不是拍数字：
- 业务回溯窗口是第一依据。订单和支付 99.9% 在 30 分钟内配对，TTL 设 1-2 小时；埋点的曝光和点击可能隔天归因，TTL 就得按归因窗口设 24-48 小时。TTL 设短的代价是 Join 不上（右流晚到时左流状态已过期），设长的代价是状态膨胀，按业务的匹配时长分布（P99/P999）来定。
- 数据量级反推可行性。估算状态大小：key 基数 × 单 key 平均条数 × 单条大小 × 2（双侧）。算出 500G 就得认真考虑 RocksDB + 增量 Checkpoint，或者改方案。
- 留余量但别翻倍。TTL 到期是硬删除，宁可略大于 P99 也不要卡着 P95 设。
大状态的优化手段
Join 状态扛不住时的常规套路：能改 interval join 就改；把不需要的字段在 Join 前裁剪掉，状态里只存必要列；单侧是维表就换成 lookup join（异步查外部 KV + 缓存），不存状态；两流时间差天然有界的场景用 interval join 收紧边界。还有一个容易忽略的：Join 输入先去重，重复的 key 会让单侧状态的 list 越堆越长。
Left Join 的语义坑
Left join 时左流数据先到、右流还没来，会先输出一条右侧为 null 的结果；右流到了之后发回撤（-U）旧结果再发新结果（+U）。下游如果是 append-only 的 Kafka 消费者或不了解回撤的报表，会看到「数据变来变去」。接 changelog 流要么下游是 upsert 语义存储，要么消费端正确处理撤回消息，这个坑面试官很爱和 TTL 一起考。
可能的追问
- Interval join 的状态怎么自动清理的？——Join 条件的时间界让引擎知道某条左流数据最多等「上界时长」就不会再有匹配，到时自动从状态清除，等价于按条目的逻辑 TTL。
- 一侧流量远大于另一侧怎么办？——主流大、支流小且基本是全量维表时，别用双流 join，用 broadcast 或 lookup join，状态只在维表侧且很小。
- Join 结果比预期少怎么排查？——先看 TTL 是否太短导致一侧状态提前过期，再看 Watermark 推进是否一致（两流时间戳体系要对齐），最后看 key 是否真的能对上（字段类型、空值、大小写）。