Flink Timer 什么时候用？有哪些坑？
面试怎么回答
Flink Timer 适合结合 Keyed State，在未来时间点继续处理某个 Key，例如超时告警、延迟输出、低层 Join 和状态清理。Processing Time 按机器时间触发，Event Time 要等 Watermark 推进。实现时保存最新 Timer 时间，更新事件时删除旧 Timer、注册新 Timer，回调中校验是否过期，并控制 Timer 粒度和数量，避免状态与 Checkpoint 压力。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
订单状态流里有一个需求：同一个订单超过 30 分钟没有新事件，就输出一条超时告警。
它不是固定窗口统计，也不是每来一条数据就立即输出，而是要在未来某个时间点再次处理这个 Key。
这正是 Flink Timer 适合解决的问题。
Timer 的核心是：把 Keyed State 与未来的时间回调组合起来，在指定的处理时间或事件时间触发 onTimer。
Timer 适合哪些场景？
- 一段时间没有新事件时输出超时结果
- 等待关联数据，到期后决定补偿或丢弃
- 延迟发送、状态清理或周期性检查
- 基于事件时间等待 Watermark 越过业务截止点
它适合“记住当前状态，稍后再回来处理”的逻辑。如果只是固定窗口聚合，优先使用 Window API，语义更直接。
Processing Time 和 Event Time 怎么选？
Processing Time Timer
按照机器处理时间触发。墙上时钟到达目标时间后执行，延迟低、实现直接，但结果会受任务恢复、背压和运行环境影响。
适合系统超时、定时刷新等更关心“现在过了多久”的场景。
Event Time Timer
按照事件时间触发。只有 Watermark 推进到目标时间，onTimer 才会执行。
适合需要处理乱序数据、希望按业务发生时间得到可重复结果的场景。但如果上游没有 Watermark，或者某个输入分区长期空闲又没有正确配置 idleness，Timer 可能一直不触发。
一个常见实现：无新事件则超时
每来一条同 Key 数据时：
- 更新 Keyed State
- 删除上一次尚未触发的 Timer
- 注册一个新的超时时间
- 把新 Timer 时间写入 State
触发 onTimer 时，再检查触发时间是否仍是 State 中记录的最新 Timer。这样可以避免旧 Timer 把已经更新过的状态误判为超时。
生产里最容易踩的坑
没有先 keyBy
Keyed State 和用户级 Timer 依赖 KeyedStream。Timer 与注册它的 Key 绑定，触发时也会恢复对应 Key 的上下文。
只注册新 Timer，不删除旧 Timer
同一个 Key 不断产生不同时间戳的 Timer，会让 Timer 数量和状态持续增长。对于会话超时等场景，要保存旧时间并及时删除或让触发逻辑识别过期 Timer。
以为相同时间戳会触发多次
Flink 会按 Key 和时间戳去重，同一个 Key 在相同时间戳重复注册，只会触发一次。
Timer 粒度过细
海量 Key 每条数据都注册毫秒级不同 Timer，会增加状态和 Checkpoint 压力。允许误差时，可以把时间向秒或分钟取整，让多个触发时间合并。
触发后忘记清理 State
Timer 执行完成不代表相关业务 State 自动清理。要根据状态生命周期显式删除。