Flink 作业连续运行三个月Checkpoint 从未失败Doris 导入任务也全部成功。月底对账却发现部分订单被重复累计另一些订单停在旧状态。团队最容易得出的结论是 Doris Connector 没有做到 Exactly-Once。这个判断通常太早。Checkpoint、Doris 事务和业务结果分别解决三个不同问题。Exactly-Once 只能证明一批数据不会因为失败恢复被重复提交不能证明事件顺序正确、表模型正确更不能替代业务对账。一条链路里其实有三种正确Flink 状态正确失败后从同一 Checkpoint 恢复 ↓ Doris 提交正确同一批数据只成功提交一次 ↓ 业务状态正确乱序、删除、主键和字段合并符合业务规则第一层由 Flink Checkpoint 管第二层依赖 Connector、Stream Load 2PC 和 Label第三层依赖 Key 模型、Sequence、删除语义和对账。上层成功不能自动推出下层成功。四种方案看起来都能重试语义完全不同下面做同条件对比Kafka 至少一次投递Sink 写入后在提交前崩溃任务恢复并重放同一批数据。写入方案重试时发生什么能保证什么仍然解决不了什么普通 Stream Load每次随机 Label重放生成新事务每次请求原子提交重复数据固定业务 Label相同 Label 被识别单批幂等跨批边界和 Label 过期Flink Connector 2PCCheckpoint 与 Doris PRECOMMIT/COMMIT 协调故障恢复后的提交唯一性乱序、错误主键、漏同步 DeleteBatch Mode Unique Key可能重复写主键覆盖最终一主键一行Duplicate/Aggregate 表重复旧事件覆盖新状态Doris 事务官方文档 明确区分两层Label 保证单个事务不重复2PC 用于跨系统协调。Label 还会按时间和数量清理默认保留边界不能被当成永久幂等账本。2PC 真正绑定的是 Checkpoint 与 Doris 事务Flink Doris Connector 官方文档 中流式写入默认依赖 Checkpointsink.enable-2pc默认开启。核心链路可以压成五步数据写入 Doris 临时事务 → Flink 触发 Checkpoint → Sink 预提交当前事务 → Checkpoint 全局完成 → Sink 提交 Doris 事务并开启下一事务故障发生在不同位置恢复动作不同PRECOMMIT 前失败本批状态随 Checkpoint 一起回滚并重放PRECOMMIT 后、Checkpoint 完成前失败未完成事务不能冒充成功批次Checkpoint 已完成但客户端未收到 COMMIT 响应恢复后通过事务标识判断而不是盲目再写一批。sink.label-prefix必须全局唯一。两个作业共用前缀不是增强幂等而是在争用事务身份。最小故障实验比看 SUCCESS 更有价值建立 Unique Key 订单状态表Sequence 使用单调业务版本op_version。准备三个事件创建、支付、迟到取消。Connector 开启 2PCCheckpoint 间隔设置为测试可观察的 30 秒。CREATETABLEorder_state_eos(order_idBIGINT,op_versionBIGINT,statusVARCHAR(16),amountDECIMAL(12,2))UNIQUEKEY(order_id)DISTRIBUTEDBYHASH(order_id)BUCKETS4PROPERTIES(enable_unique_key_merge_on_writetrue,function_column.sequence_colop_version);测试不要只杀一次进程而要覆盖三个切点写入中、预提交后、Checkpoint 完成附近。每次恢复后检查四项证据SELECTorder_id,COUNT(*)FROMorder_state_eosGROUPBYorder_idHAVINGCOUNT(*)1;SELECTorder_id,MAX(op_version),MAX_BY(status,op_version)FROMorder_event_auditGROUPBYorder_id;第一条检查服务表的一主键一行第二条从审计事件重建期望状态。只查 Doris 最终行无法发现源端事件是否漏掉所以生产上最好保留 Duplicate Key 审计表作为旁路证据。三个经典假成功Batch Mode 把 EOS 悄悄关掉Connector 开启sink.enable.batch-mode后提交由时间和数据量触发不再跟随 Checkpoint。官方文档明确说明此模式不保证 Exactly-Once。Unique Key 可以消除同主键重复却不能保护 Duplicate Key 明细和 Aggregate Key 累加值。旧事件被精确提交一次迟到的取消事件只提交一次完全满足传输 EOS没有 Sequence 的 Unique Key 仍会让它覆盖支付状态。一次且仅一次地写错仍然是错。删除事件根本没有进入 SinkConnector、上游 CDC 或表模型未正确处理 DeleteCheckpoint 仍会成功。状态表保留幽灵记录技术指标全部绿色。源码该追的是状态边界发布文章前应将 Connector 版本与 Doris4.0.8同时固定。源码阅读只追四个状态不需要展开整个 Connectorbegin transaction → write data → preCommit on checkpoint barrier → commit or abort after checkpoint resultDoris 端重点核对 FE 事务管理中的 Label 唯一性、PRECOMMITTED 到 COMMITTED/VISIBLE 的状态迁移以及重复 COMMIT 的处理。源码价值在于确认失败窗口而不是证明配置项存在。生产验收只认端到端证据层次必须留下的证据SourceKafka partition/offset 或源库位点FlinkCheckpoint ID、完成时间、恢复点DorisLabel、事务状态、可见时间、过滤行数业务主键集合、最大版本、Delete 结果、关键金额聚合如果任意一层无法通过同一批次标识串起来就不能宣称端到端 Exactly-Once。Exactly-Once 不是一个开关而是 Source 位点、Checkpoint、事务身份、表模型和业务版本共同闭合的一条证据链。官方资料TransactionsLoad TransactionsFlink Doris ConnectorData Update Overview Apache Doris 4.0.8 一致性实战（第 3 篇）：Checkpoint 一直成功，Exactly-Once 为什么仍可能是假的
Flink 作业连续运行三个月Checkpoint 从未失败Doris 导入任务也全部成功。月底对账却发现部分订单被重复累计另一些订单停在旧状态。团队最容易得出的结论是 Doris Connector 没有做到 Exactly-Once。这个判断通常太早。Checkpoint、Doris 事务和业务结果分别解决三个不同问题。Exactly-Once 只能证明一批数据不会因为失败恢复被重复提交不能证明事件顺序正确、表模型正确更不能替代业务对账。一条链路里其实有三种正确Flink 状态正确失败后从同一 Checkpoint 恢复 ↓ Doris 提交正确同一批数据只成功提交一次 ↓ 业务状态正确乱序、删除、主键和字段合并符合业务规则第一层由 Flink Checkpoint 管第二层依赖 Connector、Stream Load 2PC 和 Label第三层依赖 Key 模型、Sequence、删除语义和对账。上层成功不能自动推出下层成功。四种方案看起来都能重试语义完全不同下面做同条件对比Kafka 至少一次投递Sink 写入后在提交前崩溃任务恢复并重放同一批数据。写入方案重试时发生什么能保证什么仍然解决不了什么普通 Stream Load每次随机 Label重放生成新事务每次请求原子提交重复数据固定业务 Label相同 Label 被识别单批幂等跨批边界和 Label 过期Flink Connector 2PCCheckpoint 与 Doris PRECOMMIT/COMMIT 协调故障恢复后的提交唯一性乱序、错误主键、漏同步 DeleteBatch Mode Unique Key可能重复写主键覆盖最终一主键一行Duplicate/Aggregate 表重复旧事件覆盖新状态Doris 事务官方文档 明确区分两层Label 保证单个事务不重复2PC 用于跨系统协调。Label 还会按时间和数量清理默认保留边界不能被当成永久幂等账本。2PC 真正绑定的是 Checkpoint 与 Doris 事务Flink Doris Connector 官方文档 中流式写入默认依赖 Checkpointsink.enable-2pc默认开启。核心链路可以压成五步数据写入 Doris 临时事务 → Flink 触发 Checkpoint → Sink 预提交当前事务 → Checkpoint 全局完成 → Sink 提交 Doris 事务并开启下一事务故障发生在不同位置恢复动作不同PRECOMMIT 前失败本批状态随 Checkpoint 一起回滚并重放PRECOMMIT 后、Checkpoint 完成前失败未完成事务不能冒充成功批次Checkpoint 已完成但客户端未收到 COMMIT 响应恢复后通过事务标识判断而不是盲目再写一批。sink.label-prefix必须全局唯一。两个作业共用前缀不是增强幂等而是在争用事务身份。最小故障实验比看 SUCCESS 更有价值建立 Unique Key 订单状态表Sequence 使用单调业务版本op_version。准备三个事件创建、支付、迟到取消。Connector 开启 2PCCheckpoint 间隔设置为测试可观察的 30 秒。CREATETABLEorder_state_eos(order_idBIGINT,op_versionBIGINT,statusVARCHAR(16),amountDECIMAL(12,2))UNIQUEKEY(order_id)DISTRIBUTEDBYHASH(order_id)BUCKETS4PROPERTIES(enable_unique_key_merge_on_writetrue,function_column.sequence_colop_version);测试不要只杀一次进程而要覆盖三个切点写入中、预提交后、Checkpoint 完成附近。每次恢复后检查四项证据SELECTorder_id,COUNT(*)FROMorder_state_eosGROUPBYorder_idHAVINGCOUNT(*)1;SELECTorder_id,MAX(op_version),MAX_BY(status,op_version)FROMorder_event_auditGROUPBYorder_id;第一条检查服务表的一主键一行第二条从审计事件重建期望状态。只查 Doris 最终行无法发现源端事件是否漏掉所以生产上最好保留 Duplicate Key 审计表作为旁路证据。三个经典假成功Batch Mode 把 EOS 悄悄关掉Connector 开启sink.enable.batch-mode后提交由时间和数据量触发不再跟随 Checkpoint。官方文档明确说明此模式不保证 Exactly-Once。Unique Key 可以消除同主键重复却不能保护 Duplicate Key 明细和 Aggregate Key 累加值。旧事件被精确提交一次迟到的取消事件只提交一次完全满足传输 EOS没有 Sequence 的 Unique Key 仍会让它覆盖支付状态。一次且仅一次地写错仍然是错。删除事件根本没有进入 SinkConnector、上游 CDC 或表模型未正确处理 DeleteCheckpoint 仍会成功。状态表保留幽灵记录技术指标全部绿色。源码该追的是状态边界发布文章前应将 Connector 版本与 Doris4.0.8同时固定。源码阅读只追四个状态不需要展开整个 Connectorbegin transaction → write data → preCommit on checkpoint barrier → commit or abort after checkpoint resultDoris 端重点核对 FE 事务管理中的 Label 唯一性、PRECOMMITTED 到 COMMITTED/VISIBLE 的状态迁移以及重复 COMMIT 的处理。源码价值在于确认失败窗口而不是证明配置项存在。生产验收只认端到端证据层次必须留下的证据SourceKafka partition/offset 或源库位点FlinkCheckpoint ID、完成时间、恢复点DorisLabel、事务状态、可见时间、过滤行数业务主键集合、最大版本、Delete 结果、关键金额聚合如果任意一层无法通过同一批次标识串起来就不能宣称端到端 Exactly-Once。Exactly-Once 不是一个开关而是 Source 位点、Checkpoint、事务身份、表模型和业务版本共同闭合的一条证据链。官方资料TransactionsLoad TransactionsFlink Doris ConnectorData Update Overview