1. Flink 基石：为什么需要 Exactly-Once？
做流计算的人，早晚都会撞上「一致性」这堵墙。我记得刚接触 Flink 那会儿，领导丢给我一个任务：把实时交易流水从 Kafka 读到 MySQL，要求「一分钱都不能差」。我当时心想，这不就是消费、处理、写入嘛，能有多难？结果上线第一天，凌晨三点报警就响了——订单金额翻倍了。
嗯，从那以后我才真正开始琢磨：到底什么是 Exactly-Once？为什么它这么难？
从最朴素的语义说起
在分布式系统中，数据处理语义通常分三个等级。说白了，就是「丢不丢数据」和「重不重复处理」的问题。
| 语义等级 | 核心特征 | 典型场景 |
|---|---|---|
| At-Most-Once | 最多一次，丢了就丢了 | 监控指标、日志采样 |
| At-Least-Once | 至少一次，可能重复 | 通知推送、非关键计数 |
| Exactly-Once | 精确一次，不丢不重 | 金融交易、库存扣减 |
你想想看，如果只是做 PV/UV 统计，丢几条数据无所谓，At-Most-Once 就够了。但换到银行转账场景，少一笔或多一笔都是事故。所以 Exactly-Once 不是锦上添花，而是业务底线。
At-Most-Once：最省心，也最危险
这个语义最简单：数据来了就处理，失败了直接丢弃。不重试、不回溯、不保存状态。
我在早期做 IoT 传感器数据采集时用过这种模式。温度传感器每秒上报一次，丢一两条不影响整体趋势。但如果你把它用在订单系统上——嗯，我劝你别试。
核心问题：At-Most-Once 不保证数据完整性。一旦发生故障，数据永久丢失。
At-Least-Once：保住了数据，但带来了重复
为了解决丢数据的问题，大家自然想到了「失败了就重试」。这就是 At-Least-Once 的思路：每条数据至少被处理一次。
听起来不错对吧？但这里有个坑：重试必然导致重复。比如你往数据库里写一条记录，第一次写成功了，但 ACK 在网络中丢失了。客户端以为失败了，于是重试——结果写了两条。
我曾经在一个实时风控项目里踩过这个坑。规则引擎收到重复事件，连续触发了两次告警，运维同学半夜被电话叫醒……后来我们不得不在下游加了一层去重逻辑，才勉强稳住。
避坑指南：At-Least-Once 虽然保证了「不丢」，但「重复」会引发连锁反应。下游系统必须做好幂等处理，否则数据会越滚越乱。
Exactly-Once：理想中的「不丢不重」
Exactly-Once 的目标很明确：每条数据对系统状态的影响恰好一次。注意，我说的是「影响恰好一次」，而不是「处理恰好一次」。因为底层可能重试多次，但最终效果只算一次。
这就像你去银行存钱。ATM 机可能因为网络问题重试了好几次请求，但你的账户余额只增加了一次。这就是 Exactly-Once 的魔力。
Flink 是怎么做到的呢？核心靠两样东西：
- Checkpoint（检查点）：定期保存算子状态和消费位置的快照
- 两阶段提交（2PC）：保证写入外部系统时，要么全部成功，要么全部回滚
我个人习惯把 Checkpoint 理解为「流计算的时间机器」。一旦发生故障，Flink 可以从最近的 Checkpoint 恢复状态，同时把 Source 的偏移量也回退到那个时刻。这样，故障期间处理过的数据会被重新消费一遍——但因为状态已经回滚，重复处理不会产生额外影响。
个人经验：我在做实时数仓项目时，把 Checkpoint 间隔设为 30 秒。太短会影响吞吐，太长又会导致恢复时间过长。这个值需要根据业务容忍度反复调优。
端到端一致性的挑战
很多人以为 Flink 内部做到 Exactly-Once 就万事大吉了。其实不然。真正的难点在于端到端一致性——从 Source 到 Flink 再到 Sink，整条链路都要保证。
为什么会这样？因为 Flink 只能控制自己的状态和 Checkpoint。它管不了 Kafka 的 offset 提交，也管不了 MySQL 的事务提交。一旦外部系统「不配合」，一致性就破了。
举个例子：Flink 从 Kafka 读取数据，处理完后写入 Elasticsearch。如果 Flink 任务挂了，重启后从 Checkpoint 恢复。Kafka 的 offset 回退了，但 Elasticsearch 里已经写入了部分数据——这就产生了重复。
解决思路通常有三种：
- 幂等写入：下游系统支持幂等操作，重复写入不会改变最终结果
- 事务写入：利用两阶段提交，将 Flink 的 Checkpoint 和外部系统的事务绑定
- 去重机制：在下游维护一个去重表，根据业务主键过滤重复数据
我个人更倾向于第二种方案，虽然实现复杂，但语义最干净。Flink 的 Kafka Sink 和 JDBC Sink 都内置了 2PC 支持，用起来还算顺手。
关键认知：Exactly-Once 不是 Flink 单点能保证的，而是整个数据链路共同承诺的结果。Source、Flink、Sink 三方必须达成一致协议。
一张图看懂一致性演进
下面这张图梳理了从 At-Most-Once 到 Exactly-Once 的演进路径，以及端到端一致性的核心挑战。你可以把它当作本章的知识地图。
小结一下
这一章我们聊了三个语义的演进脉络。At-Most-Once 最简单，但会丢数据；At-Least-Once 保住了数据，却引入了重复；Exactly-Once 是终极目标，但实现起来需要整个链路配合。
我个人觉得，理解 Exactly-Once 的关键不在于记住概念，而在于想清楚一个问题：当系统发生故障时，你的数据到底经历了什么？ 想通了这一点，后面学 Checkpoint、两阶段提交、端到端一致性方案时，就会顺很多。