在 Flink 挂掉并从 Checkpoint 恢复的场景下，由于 Checkpoint 机制的特性，Sink 端不可避免地会收到从上一个 Checkpoint 到故障发生期间的“重放数据”。这就导致了端到端的语义退化为 At-Least-Once（至少一次）。 如果你没有使用支持精确一次（Exactly-Once）的二阶段提交（2PC）Sink，那么在业务侧设计幂等性（Idempotence）是容忍数据重放的唯一且最有效的手段。 针对 HBase、Redis 和 MySQL 等通常的存储介质，设计幂等操作的核心原则是：将“增量/相对修改”转化为“绝对/覆盖修改”。具体可以通过以下几种设计模式来实现： --- 1. 核心策略：基于唯一键的 Upsert（覆盖写） 这是最基础也最常用的幂等设计。业务侧必须能从数据中提取或生成一个全局唯一的主键（Primary Key / RowKey / Redis Key）。 设计原则：无论同样的数据重放多少次，写入存储时都直接覆盖旧值。由于重放的数据内容是完全一致的，所以覆盖 n 次和写入 1 次的结果完全相同。 各组件实现： MySQL：禁止...
播面