Reliability & Graceful Degradation: 解释幂等性与精确一次语义的实现。

Core Concept: 重试与重放必须幂等（请求 ID 去重、唯一键写入、状态机去重）；端到端精确一次通常由'至少一次 + 幂等'实现，即有效一次（effectively-once）。

数学机理：<strong>幂等性（idempotency）</strong>——(1) <strong>定义</strong>——f(f(x)) = f(x)：对同一输入重复执行与执行一次结果相同。(2) <strong>为何需要</strong>——(a) <strong>重试</strong>——超时后不确定是否成功，重试可能重复执行；(b) <strong>重放</strong>——消息队列至少一次投递会重复；(c) <strong>用户重复提交</strong>——双击/网络重发。(3) <strong>实现方式</strong>——(a) <strong>去重键（idempotency key / request_id）</strong>——客户端生成唯一 ID，服务端维护去重表（已处理则返回缓存结果）；(b) <strong>唯一约束</strong>——DB 唯一索引（重复插入失败 → 视为已处理）；(c) <strong>乐观锁/版本号</strong>——CAS 更新（版本不匹配则拒绝）；(d) <strong>状态机</strong>——只允许合法状态跃迁（已支付不能再次支付）；(e) <strong>条件写入</strong>——'若不存在则创建'。(4) <strong>幂等键设计</strong>——(a) <strong>唯一且稳定</strong>——由业务语义决定（订单号 + 操作类型）；(b) <strong>客户端生成</strong>——而非服务端（否则重试时不同）；(c) <strong>过期</strong>——去重表需 TTL 与清理。<strong>精确一次（exactly-once）</strong>——(1) <strong>难处</strong>——(a) <strong>分布式不确定性</strong>——网络超时下无法区分'请求未到'与'响应丢失'（两将军问题）；(b) <strong>端到端</strong>——涉及多服务/多存储，任一处重复都破坏精确一次。(2) <strong>实践方案</strong>——(a) <strong>至少一次投递 + 幂等消费</strong> = <strong>有效一次（effectively-once）</strong>；(b) <strong>事务性消息</strong>——消息发送与业务写入同一事务（如 Kafka 事务 + 幂等生产者）；(c) <strong>两阶段提交（2PC）</strong>——跨资源原子提交（但性能与可用性差）；(d) <strong>补偿事务（Saga）</strong>——每步有补偿操作，最终一致。(3) <strong>流的精确一次</strong>——(a) <strong>Flink 检查点 + 幂等/事务 sink</strong>；(b) <strong>Kafka 事务</strong>——幂等生产者 + 事务。(4) <strong>副作用的处理</strong>——(a) <strong>非幂等副作用</strong>——扣款、发消息、发邮件——必须加去重或放在幂等边界内；(b) <strong>顺序</strong>——先落库（幂等）再发副作用，或副作用本身幂等。(5) <strong>与一致性模型的关系</strong>——(a) <strong>强一致</strong>——线性一致（成本高）；(b) <strong>最终一致</strong>——Saga/补偿；(c) <strong>选择</strong>——按业务容忍度。(6) <strong>测试</strong>——(a) <strong>重复投递测试</strong>——验证重复请求不产生重复副作用；(b) <strong>故障注入</strong>——在关键点杀进程验证恢复。(7) <strong>常见错误</strong>——(a) <strong>重试非幂等操作</strong>——重复扣款；(b) <strong>去重键由服务端生成</strong>——重试时新键导致去重失效；(c) <strong>去重表无 TTL</strong>——无限增长；(d) <strong>只在应用层去重</strong>——多实例下失效（需共享存储/分布式锁）。<strong>与其他问题的关系</strong>——(a) 与超时重试（重试安全的前提）；(b) 与优雅降级（降级重试）；(c) 与数据管道（流处理的精确一次）；(d) 与分布式一致性。<strong>度量</strong>——(a) 重复副作用事件数（应为 0）；(b) 重试成功率；(c) 去重表大小与命中率；(d) 补偿事务触发率。

深度剖析与工程权衡：① <strong>端到端 exactly-once 几乎不可实现</strong>——实践用'至少一次 + 幂等'；面试中能指出'两将军问题'是深度理解的标志。② <strong>幂等键必须客户端生成且稳定</strong>——否则重试时去重失效。③ <strong>去重表需 TTL 与共享存储</strong>——多实例下应用层去重无效。④ <strong>非幂等副作用必须显式处理</strong>——扣款/发消息是重灾区。⑤ <strong>2PC 性能差</strong>——大规模下多用 Saga 最终一致。⑥ <strong>流处理的精确一次靠检查点 + 幂等 sink</strong>。⑦ <strong>面试要点</strong>——被问怎么保证重试不重复，应给出'<strong>幂等键 + 去重表/唯一约束/状态机 + 至少一次投递 + 补偿（Saga）</strong>'；能指出端到端精确一次的困难与幂等键设计要点是深度理解的标志。