考察点
「Flink 是不是 Exactly-Once」是道陷阱题，直接答「是」就掉坑里了。面试官想听到三个层次：Checkpoint 只保证内部状态一致、端到端需要 sink 配合、两阶段提交是怎么把提交动作和 Checkpoint 绑定的。追问会往 2PC 的失败场景、幂等 sink、At-Least-Once 的取舍走。
参考答案
先分清三个语义
At-Most-Once 不保证不丢，At-Least-Once 保证不丢但可能重复，Exactly-Once 保证每条数据精确影响最终结果一次。Flink 的 Checkpoint 机制保证的是「内部状态的 Exactly-Once」：故障恢复后，算子状态和 source 消费位点回到同一个一致点，重新处理的数据不会让内部状态算错。但数据出了 Flink 就管不着了——sink 已经写出去的数据，故障重放时会再写一遍。端到端 Exactly-Once 必须是「Checkpoint + 一致性 sink」的组合。
两阶段提交怎么接上轨
Flink 的 TwoPhaseCommitSinkFunction 把外部系统的事务生命周期和 Checkpoint 对齐：
- 第一阶段（预提交）：正常处理时，每条数据写入 sink 的「进行中事务」（Kafka 的事务写入、MySQL 的未提交事务）。Checkpoint barrier 到达时，sink 先拍自己的状态，然后调用 preCommit——把事务刷到外部系统但不对外可见，事务句柄存进 Checkpoint。
- 第二阶段（提交）：JobManager 通知所有算子「Checkpoint n 完成了」，sink 收到 notifyCheckpointComplete 后调用 commit，事务正式对外生效。
- 失败路径：Checkpoint 失败或作业崩溃，未完成的事务调用 abort 中止丢弃，外部系统里不留痕迹。
妙处在于：对外可见的数据一定属于已完成的 Checkpoint。故障恢复从最近完成的 Checkpoint 重放，重放的数据要么之前没提交过（重新走流程），要么提交过但那次 Checkpoint 之后已被覆盖——配合幂等，结果精确一次。
常见 sink 的一致性实现
Kafka sink：事务模式（DeliveryGuarantee.EXACTLY_ONCE），走 Kafka 事务 API，consumer 侧要配 read_committed 隔离级别才读不到未提交数据。注意事务超时时间要大于 Checkpoint 间隔。
数据库 sink（MySQL/Doris/StarRocks）：通常不走 2PC，走幂等 upsert——按业务主键 insert-or-update，重复写结果一样，天然扛重放。这是实时数仓最常见的姿势。
文件 sink（写 Hive/Iceberg 表）：StreamingFileSink/FileSink 用「in-progress 文件 + Checkpoint 完成时 rename 正式文件」的方式，文件系统层面的两阶段提交。
代价与取舍
2PC 不是免费的：数据对外可见延迟被拉长到 Checkpoint 间隔（Checkpoint 一分钟，下游最多晚一分钟看到数据）；sink 侧要维护事务状态。所以工程上有明确的取舍：下游能幂等就优先幂等（简单、低延迟）；下游是 Kafka 这类支持事务的系统且要严格语义才上 2PC；纯监控类场景 At-Least-Once 加下游去重往往性价比最高。面试里主动讲出这个权衡，比背书更加分。
可能的追问
- 如果 commit 阶段 JobManager 挂了怎么办？——恢复后 sink 会从 Checkpoint 状态里读到「待提交事务」并继续提交，2PC 的状态机覆盖了这个场景。
- 幂等和 2PC 选哪个？——幂等优先，前提是 sink 有稳定业务主键；2PC 用于无幂等能力但支持事务的系统（主要是 Kafka）。
- source 端要配合什么？——source 要可重放（Kafka 重置 offset、文件重读），像 socket 这种不可重放的 source，端到端 Exactly-Once 无从谈起。