想象你是小区门口快递驿站的站长。今天同一个包裹——单号「T20240516001」——快递员送来了三次：第一次你签收入库，第二次你发现单号已经在台账上，直接告诉他“这个收过了”；第三次你连头都没抬，扫一眼单号就放他走了。三次配送，只有第一次真正入库，后面两次都被“单号台账”挡在了门外。这个小动作，就是数据管道世界里的幂等。 而重试，是快递员的另一种专业素养：敲门没人应，他不会把包裹扔在门口就走，而是等十分钟再来、再等二十分钟再来，直到最后确认实在送不到，才把包裹退回转运中心，进入“死信区”。AI 数据管道里，把数据从 A 搬到 B 这件事每天都在上演：Kafka 事件要落数仓、模型特征要在线更新、ETL 任务要按天跑批。线上没有一帆风顺——网络闪断、下游超时、数据库重启，任何意外都会让同一个任务被重复执行。如果没有“幂等”这层台账，重复执行就会变成重复扣费、特征翻倍；如果没有“重试”这套配送规范，一次抖动就让整条管道停摆。 本文就用驿站的故事把这两个机制一次讲透：幂等是“重复执行也不出错”的保证，重试是“失败了敢再来一次”的底气。两者合在一起，才能让 AI 数据管道在不可靠的网络上，对外呈现出“恰好处理一次”的可靠假象。

岗位关联

幂等与重试是数据管道可靠性的地基。掌握它们，你就能设计出“夜里安心睡觉、管道不会搞出脏数据”的高质量系统，这是数据工程师与 AI 架构师的硬通货能力。

目录
  1. 可视化演示
  2. 幂等的基础认知
  3. 幂等实现策略
  4. 重试机制原理
  5. 重试策略设计
  6. 幂等与重试协同
  7. 工程实践要点
  8. 典型应用场景
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

幂等键去重 数据管道幂等写入与重试退避策略可视化，展示消息投递、去重验证和指数退避重试过程

幂等的基础认知

驿站站长手里那本台账，核心只记一件事：这个单号签过没有。数学上，幂等就是一个操作无论执行一次还是十次，最终状态都一样——签收这个动作，签了一次台账多一条记录，再签十次，记录不会变成十一条。这就是幂等最朴素的味道：重复执行，结果不变。

在数据管道里，一个任务、一条消息、一次 API 调用，都可能因为网络原因被上游重复推送。判断一个步骤是否幂等，要看它对同一输入重复执行后系统状态是否保持一致。“把状态置为已完成”是幂等的，“余额加 100 元”这种累加操作则不幂等，重复执行会翻倍。管道工程里最重要的辅助工具是幂等键（idempotency key），相当于快递单号，通常由业务唯一标识生成：订单号、请求 ID、或消息的“分区号 + 偏移量”。有了幂等键，下游才能区分“新数据”和“重放数据”。另一个概念是条件幂等：操作只在满足前置条件时执行，比如“仅当状态为 PENDING 时才支付”。

还要分清幂等与去重：去重是省算力，幂等是保正确性——去重表丢了只影响性能，幂等键失效则正确性崩坏。两者常一起出现，但定位完全不同。

回到驿站：签收一箱已入库，再签一百次，柜台上还是那一箱。幂等不是“防止包裹送来”，而是“多送几次也无所谓”。它为后面的重试铺好了路——没有这层台账，快递员每次重试都等于往错误里再加一笔。

f(f(x))=f(x)\displaystyle f(f(x)) = f(x)
释义：f 是一次处理动作，x 是输入数据。对同一输入连续施加两次处理，等价于只施加一次——这是幂等的数学签名。
  1. f 代表处理动作管道中的一个算子，比如“清洗一条记录”“扣减一次库存”。
    f:X→Xf: X \rightarrow X
  2. x 代表输入数据进入算子的一条记录或一个事件，通常携带幂等键。
    x∈Xx \in X
  3. f(x) 是第一次执行的结果处理后数据达到的新状态。
    x′=f(x)x' = f(x)
  4. f(f(x)) 是第二次执行的结果把第一次的输出再喂给同一个 f。
    x′′=f(x′)x'' = f(x')
  5. 等式 f(f(x)) = f(x)两次执行得到相同状态，说明重复执行被安全吸收。
    x′′=x′x'' = x'

幂等实现策略

驿站怎么保证同一单号只入一次库？靠三样东西：柜台上贴了唯一编号的格子、入库流程的固定顺序、每次扫单时核对“是否已在已入库列表”。数据管道的幂等落地，也对应这三类工程手段。

最常见的是数据库唯一约束：给表加主键或唯一索引，重复插入直接冲突报错，业务把“冲突”捕获后当成功处理。第二种是状态机：任务有明确的合法状态迁移路径，重复的迁移指令被忽略。第三种是写入前比对：先读当前值，确认一致才写入，适合覆盖写场景。版本号是写入比对的通用实现——表里加 version 字段，更新语句带条件 WHERE version = 期望值，成功则 version+1，这就是乐观锁：两个并发写只有一个能成功，天然防重复。

在批处理管道中，还有一招“分区覆盖写”：离线 ETL 刷全量当天分区时，先 DELETE 分区再 INSERT 新数据，任务重跑多少遍，分区里都是同一份最新结果。增量场景则用 upsert——有则更新，无则插入。

台账的三道防线，落到数据库里就是唯一索引、状态机校验、版本号并发控制。有了它们，快递员手抖多扫一次码不怕，上游多推一条重放数据也不怕——重复写入、并发竞争、覆盖错乱，全被挡在门外。

U(x)={x′,x∈Sx,x∉S\displaystyle U(x) = \begin{cases} x', & x \in S \\ x, & x \notin S \end{cases}
释义：U 是带条件的状态更新。只有输入状态落在允许迁移的集合 S 内，才推进到新状态；否则保持不变。这就是“条件幂等”的统一表达。
  1. U 表示更新算子管道中对某条记录或任务状态执行的写操作。
    U:X→XU: X \rightarrow X
  2. x 是当前状态比如一个调度任务正处于 RUNNING。
    x∈Xx \in X
  3. S 是允许迁移的状态集合调度任务只允许 RUNNING→SUCCESS，不允许 RUNNING→RUNNING。
    S⊆XS \subseteq X
  4. x ∈ S 时推进到 x'状态合法，执行迁移，版本号同时递增。
    x′=U(x)x' = U(x)
  5. x ∉ S 时保持 x状态已迁移过，直接忽略，重复执行无副作用。
    U(x)=xU(x) = x

重试机制原理

快递员第一次敲门没人应，他不会立刻退货，而是发条短信、等十几分钟再来。这背后有一套朴素判断：是错峰了？还是客户搬家了？对应到系统，就是可重试失败与不可重试失败之分。

可重试失败是暂时性的：网络超时、连接被重置、下游返回 5xx 服务不可用、限流 429——等一等就可能恢复。不可重试失败是确定性的：鉴权失败 401、参数错误 400、数据格式损坏、业务校验不通过——重试只会浪费算力。给每次失败打上“是否可重试”的标签，是管道步骤的第一行防御。决定重试节奏的是退避策略（backoff）：固定退避每次等 3 秒，简单但故障恢复瞬间所有任务同时重试，容易“惊群”打爆服务。指数退避让等待按 2 的幂增长，1s、2s、4s、8s，给下游留出恢复窗口。再叠加抖动（jitter）——在间隔上加入随机扰动，避免同步重试。指数退避 + 抖动是分布式系统事实上的标准做法。

快递员的“等十分钟、二十分钟、一小时”就是最早的指数退避，而那一条“明天再来”的短信就是抖动——不会所有快递员同时砸你的门。记住：重试只该给“会好的错误”，永远别给“好不了的错误”。

dn=d0×2n+rand(0,c)\displaystyle d_n = d_0 \times 2^{n} + \text{rand}(0, c)
释义：第 n 次重试前的等待间隔 = 初始间隔 × 2 的 n 次方，再叠加一个随机抖动项，防止大量任务在同一时刻重试。
  1. d₀ 是初始等待间隔第一次重试前等多久，比如 1 秒。
    d0=1sd_0 = 1\text{s}
  2. n 是已重试次数第几次重试，从 0 开始计数。
    n∈{0,1,2,… }n \in \{0, 1, 2, \dots\}
  3. 2ⁿ 构成指数增长间隔按 1、2、4、8 倍增，给下游恢复时间。
    2n:1,2,4,8,162^{n}: 1, 2, 4, 8, 16
  4. rand(0, c) 是随机抖动c 通常取当前间隔的一部分（如 20%），打破同步。
    jitter∼Uniform(0,dn×0.2)\text{jitter} \sim \text{Uniform}(0, d_n \times 0.2)
  5. 整体节奏前几次重试快，后几次重试慢，既快速恢复又不给下游添乱。
    d0×2n+jitterd_0 \times 2^{n} + \text{jitter}

重试策略设计

快递公司定配送规范：普通件最多送 3 次，贵重件最多送 5 次，48 小时内送不到就退回仓库。这些上限给重试套上了缰绳——没有上限的执着，会变成对客户和系统的双重骚扰。

管道工程里要显式设计四个参数。最大重试次数：超过即放弃，转入失败处理。超时预算（deadline）：单次调用耗时与重试等待的总时长，不能超过业务能容忍的延迟上限。退避上限（cap）：指数增长要封顶，比如最长等 60 秒，否则一次请求能等出银河系。还有断路器（circuit breaker）：统计连续失败率，超过阈值后快速失败一段时间，不再发起重试，让下游喘息。断路器有三个状态：关闭（正常放行）、打开（短路拒绝）、半开（放少量探针流量测试恢复）。它和重试的区别是：重试是“单任务视角”，断路器是“全局保护视角”。

好的配送规范不是“一定送到”，而是“在承诺时间内有分寸地送到”。超了预算就退回仓库（进死信），而不是无限重试。策略设计的本质，是给执着装上刹车和地图：什么时候试、试几次、什么时候放弃，全在掌握之中。

∑i=1n(Ti+Di)≤Tdeadline\displaystyle \sum_{i=1}^{n} (T_i + D_i) \le T_{\text{deadline}}
释义：任务从开始到结束，历次尝试的耗时与等待间隔之和，不能超过总超时预算。先定预算，再倒推最大重试次数，而不是拍脑袋定次数。
  1. Tᵢ 是第 i 次尝试的耗时一次调用从发出到返回（或超时）的时间。
    Ti≤TtimeoutT_i \le T_{\text{timeout}}
  2. Dᵢ 是第 i 次尝试前的等待间隔退避策略产生的等待，同样计入总预算。
    Di=d0×2i−1D_i = d_0 \times 2^{i-1}
  3. 求和得到总耗时所有尝试的耗时累加。
    total=∑i=1n(Ti+Di)\text{total} = \sum_{i=1}^{n}(T_i + D_i)
  4. T_deadline 是总预算业务可接受的最大延迟，超过则必须放弃重试。
    total≤Tdeadline\text{total} \le T_{\text{deadline}}
  5. 设计顺序先定预算、再推次数，配套熔断保护下游。
    n=max⁡{n∣total≤Tdeadline}n = \max\{n \mid \text{total} \le T_{\text{deadline}}\}

幂等与重试协同

快递员敢一次次重试，是因为驿站有台账兜底：多送几次不怕，单号能挡住重复入库。重试提供“再试一次的勇气”，幂等提供“试了也不出错的安全感”，两者天生一对。

理论上，只要存在重试，投递语义就是至少一次（at-least-once）——每条消息至少被尝试处理一次，可能更多。这是多数消息系统的默认语义：Kafka 消费端依赖 offset 提交（记录消费位置的标记），宕机回放必然产生重复。要对外宣称“恰好一次”（exactly-once），几乎不可能靠网络协议实现，只能靠“至少一次 + 幂等消费”在语义上收敛。落地手段是去重表：消费端维护一张 dedup 表，主键就是幂等键（request_id 或 partition+offset），处理业务前先插入去重表，插入冲突说明已处理过，直接跳过。去重表同时保存处理结果，防止“重试处理到一半”的脏数据。最后的兜底是死信队列（DLQ）：重试耗尽仍失败的消息进入 DLQ，由人工或专门任务补偿，保证主链路不堵。

驿站敢承诺“丢件包赔”，不是因为它能阻止快递员多跑，而是台账保证多跑不坏事。设计任何一条数据链路，顺序都是先保幂等，再谈重试——重试给了管道面对故障的勇气，幂等给了重试擦屁股的能力。

at-least-once+idempotent consumption⇒exactly-once (semantic)\displaystyle \text{at-least-once} + \text{idempotent consumption} \Rightarrow \text{exactly-once (semantic)}
释义：消息系统保证每条消息至少送一次，消费端用幂等吸收重复，两者叠加，对外呈现“恰好一次”的处理效果。业内称为有效恰好一次。
  1. at-least-once 是投递语义每条消息至少被送达一次，允许重复。
    delivery: ≥1 次\text{delivery: } \ge 1 \text{ 次}
  2. idempotent consumption 是消费语义消费者重复处理同一消息不改变结果。
    consume: 重复处理⇒结果一致\text{consume: 重复处理} \Rightarrow \text{结果一致}
  3. 两者叠加重复送达被幂等消费吸收，等价于只处理一次。
    ≥1 次送达∩重复无害≡1 次有效\ge 1 \text{ 次送达} \cap \text{重复无害} \equiv 1 \text{ 次有效}
  4. effectively-exactly-once工程可实现的上限，逻辑等价于恰好一次。
    语义: exactly-once\text{语义: exactly-once}

工程实践要点

一家成熟驿站，不只靠站长的记性：有交接班日志、有扫码留存记录、有每日异常件清单。数据管道的生产级运维，同样靠台账体系。第一道防线是并发控制：多个 worker 同时消费同一分区时，光靠业务表唯一约束不够，还要有分布式锁或事务性写入，保证“检查-写入”原子化，否则两个 worker 可能同时通过检查。第二道是审计日志：每次执行都落一条记录，包含批次 ID、消费位置、结果哈希、重试次数——既是排查依据，也是去重的辅助证据。

第三道是监控告警，核心指标有三个：重试率（骤升说明下游不稳定）、失败率（骤升说明有不可重试错误或需扩容）、去重率（持续偏高说明上游重复投递严重或回放频繁）。第四道是链路追踪：同一条数据从产生到落库打上同一个 trace_id，重试和去重都在同一段轨迹下，排障时少猜疑、多实证。

驿站没台账，客户投诉说不清；管道没日志，出脏数据查不明。工程化的本质不是算法多花哨，而是每一步都有迹可循——重试能不能做、去重证据在哪、指标异动怎么归因，全在这套台账体系里。

audit_log=(trace_id, batch_id, offset, attempt, status, hash)\displaystyle \text{audit\_log} = (\text{trace\_id},\ \text{batch\_id},\ \text{offset},\ \text{attempt},\ \text{status},\ \text{hash})
释义：一条审计日志由六个字段构成：链路标识、批次位置、消费偏移、重试代次、处理状态与结果哈希。它们共同构成重试与去重决策的证据链。
  1. trace_id 是链路标识同一条数据从产生到落库的所有日志共享同一个追踪号。
    trace_id=同一条数据的统一身份\text{trace\_id} = \text{同一条数据的统一身份}
  2. batch_id 与 offset 是位置标识定位数据属于哪个批次、在分区内第几个位置。
    position=(batch_id, offset)\text{position} = (\text{batch\_id},\ \text{offset})
  3. attempt 是重试代次记录第几次执行，区分偶发抖动与持续故障。
    attempt∈{1,2,…,n}\text{attempt} \in \{1, 2, \ldots, n\}
  4. status 与 hash 是结果指纹status 记录成败，hash 保存结果摘要，用于比对重复处理差异。
    hash=H(result)\text{hash} = H(\text{result})
  5. 证据链闭环出问题时凭日志可复现、可对账、可定向补偿。
    log⁡⇒reproduce+audit+recover\log \Rightarrow \text{reproduce} + \text{audit} + \text{recover}

典型应用场景

驿站每天要处理收件、分拣、派送、退货几条业务线，每条线都得有单号台账和配送规范。AI 数据管道里，也有四个高频场景依赖幂等与重试的黄金组合。

场景一，事件流摄入：Kafka 消费者处理一条事件后写数仓，再提交 offset（消费位置标记）。如果处理成功但提交超时，重平衡后同一事件被再次消费；没有幂等，数仓就出现重复行。方案是目标表以 (topic, partition, offset) 为主键 upsert。场景二，特征计算：模型在线推理依赖的特征由离线任务更新、在线写入特征存储；同一实体同一天的特征重复计算会翻倍，方案是按 (entity_id, feature_date) 唯一键 upsert。

场景三，ETL 同步：离线跑批失败重跑是家常便饭。全量表用“先删分区再写”保证幂等，增量表用业务主键 upsert 并带 updated_at 去重。场景四，LLM API 调用：批量调用大模型接口时，限流 429 和网络超时是常态，必须重试，但重试会重复计费。方案是给每次调用生成幂等键（如请求内容哈希），服务端缓存同键响应，同时用指数退避应对限流。还有个经典错误：补偿任务不带幂等，每次重试都发一条补偿 SQL 把数据改乱——补偿逻辑必须是天然幂等的。

收件线、分拣线、派件线各有各的单号与规范，但底层是同一套逻辑：台账挡重复，重试给韧性。AI 管道的四个场景也是同一套组合拳——给数据一个唯一身份（幂等键），给失败一个重试计划。把这两个习惯内化到每个管道步骤里，架构的可靠性就水到渠成了。

INSERT … ON CONFLICT (key) DO UPDATE SET value=EXCLUDED.value\displaystyle \text{INSERT } \ldots \text{ ON CONFLICT } (\text{key}) \text{ DO UPDATE SET } \text{value} = \text{EXCLUDED.value}
释义：PostgreSQL / ClickHouse 等数据库支持的 upsert 语句：遇到主键冲突时转为更新而非报错，多次执行结果一致，是表级幂等的标准写法。
  1. INSERT 部分尝试向目标表插入一行新数据。
    INSERT INTO t (key, value)\text{INSERT INTO } t \ (\text{key},\ \text{value})
  2. ON CONFLICT (key)检测主键或唯一键冲突。
    conflict on key⇒重复行\text{conflict on key} \Rightarrow \text{重复行}
  3. DO UPDATE冲突时改为更新已有行，而不是报错。
    UPDATE SET value=EXCLUDED.value\text{UPDATE SET value} = \text{EXCLUDED.value}
  4. EXCLUDED 引用本次待插入的新值把新值覆盖上去，重复执行收敛到同一结果。
    value←新值, 重复执行结果不变\text{value} \leftarrow \text{新值, 重复执行结果不变}

AI 应用场景

金融支付对账管道

阶段：数据管道构建 / 数据落库

解决的问题：传统按“交易时间 + 金额”对账，重复扣款识别不出。引入幂等键（交易流水号）+ 唯一约束 + 重试后，扣款事件即使被重放十次，也最多生效一次，金额翻倍问题从根上消失。这就像驿站靠单号台账区分“同一包裹被送了三次”和“三个不同包裹”。

具体案例：某支付系统接入 Kafka 事件流，消费者处理“扣款事件”时先写去重表，重复事件直接提交 offset 跳过；下游银行接口超时则按指数退避重试，退避上限 60 秒，超过上限进入死信队列，由对账任务次日人工复核。

大模型 Batch 推理任务

阶段：模型推理 / 特征生成

解决的问题：用 LLM 做批量文本打标，网络抖动导致调用失败，重试会重复消耗 token 浪费成本。按请求内容哈希生成幂等键，服务端命中缓存直接返回，重试不再重复计费——好比驿站签收前先扫单号，同一包裹不会收两次钱。

具体案例：RAG 离线文档解析每天处理千万级文本片段，每片段哈希作幂等键；OpenAI 429 限流率超过 5% 时启用指数退避 + 抖动，单任务失败 5 次后进 DLQ，次日晨会修复后将 DLQ 消息重放，全程无重复入库。

Python 演示

python55 行
# 管道模拟: 幂等键去重 + 指数退避重试处理瞬时失败import randomimport time  class PipelineRunner:    def __init__(self, max_retries=4):        self.max_retries = max_retries        self.seen = set()        self.accepted = 0        self.skipped = 0     def process_once(self, record):        if record["data"] == "boom":            raise ConnectionError("downstream timeout")        return {"ok": True}     def process(self, record):        key = record["id"]        if key in self.seen:            self.skipped += 1            return {"ok": True, "dedup": True}        for attempt in range(self.max_retries + 1):            try:                result = self.process_once(record)                self.seen.add(key)                return result            except ConnectionError:                if attempt == self.max_retries:                    raise                wait = 0.1 * (2 ** attempt) + random.uniform(0, 0.02)                time.sleep(wait)        return {"ok": False}  def main():    events = [        {"id": "A-001", "data": "hello"},        {"id": "A-001", "data": "hello"},        {"id": "B-001", "data": "boom"},        {"id": "B-001", "data": "world"},    ]    runner = PipelineRunner(max_retries=3)    for ev in events:        try:            res = runner.process(ev)            tag = "dedup_skip" if res.get("dedup") else "processed"            print(ev["id"], "->", tag)        except ConnectionError:            print(ev["id"], "-> failed, go DLQ")    print("accepted:", runner.accepted, "skipped:", runner.skipped)  if __name__ == "__main__":    main()
目的：模拟一个具备幂等去重和指数退避重试的管道消费者，演示重复事件被拦截、瞬时故障自动重试、重试耗尽进死信三条路径。
  1. key = record["id"]取出幂等键，相当于快递单号，后续用它查台账。
  2. if key in self.seen:去重表命中，说明已处理过，直接跳过不重复执行。
  3. for attempt in range(self.max_retries + 1):重试循环，最多尝试 max_retries+1 次。
  4. wait = 0.1 * (2 ** attempt) + random.uniform(0, 0.02)指数退避叠加随机抖动，重试间隔逐次拉长。
  5. self.seen.add(key)只有处理成功才登记台账，避免“半成功”被误跳过。
  6. if attempt == self.max_retries:重试耗尽，抛出异常，交给上层进入死信队列。
  7. res.get("dedup")判断本次是否被幂等拦截，用于统计去重率。

常见误区

误区任务失败了就多试几次，反正重试又不花钱，设个 10 次 20 次总能成功吧？

正解重试是有代价的：占用线程、堆积队列、压垮下游。指数退避下 10 次重试的累计等待会到分钟级，用户请求早超时了。正确做法是先用超时预算倒推最大重试次数，再配断路器防雪崩。好比快递员不会一天敲你 20 次门，而是按约定次数量力而行。

为何常见：把重试当成免费保险，忽略了系统全局限流效应和超时预算约束。

误区我重试十几遍终于成功了，数据也进来了，还要幂等干嘛？

正解重试解决“能不能送到”，幂等解决“送到两次怎么办”。重试成功恰恰是重复投递的高峰——第一次处理成功但 ack 丢失，重试就会再处理一遍。Kafka 的 at-least-once 语义决定了重复必然存在，幂等是最后一道接收确认。快递员多跑几趟没问题，但驿站必须认单号。

为何常见：只看到重试解决了瞬时失败，没意识到长期运行中重复消费才是常态。

误区我把所有字段拼在一起当幂等键，总不会重复了吧？

正解幂等键要“业务唯一”而不是“内容唯一”。把 payload 全字段哈希当键，同一业务事件的两次重放（时间戳变化、字段乱序）会生成不同键，去重失效；且键越长存储和索引开销越大。应该用业务天然标识：订单号、request_id、partition+offset。快递单号之所以好用，是因为它稳定且唯一，而不是因为它长。

为何常见：混淆了“内容一致性”与“业务标识稳定性”，以为内容没变就安全，忽略了乱序和字段敏感性。

误区重试都失败了说明这条数据有问题，丢就丢了，不影响大局。

正解DLQ 是“待人工处理”区，不是垃圾桶。失败原因可能是上游 bug、schema 变更、甚至代码部署导致老数据不兼容，修复后整批重放是常态。丢掉 DLQ 等于丢掉了对账和补偿的入口——驿站退回的包裹也会登记在案，而不是扔进垃圾箱。

为何常见：把 DLQ 当错误数据，忽略了它作为系统最后兜底与数据对账入口的价值。

误区给表加个唯一索引，插入冲突跳过，幂等就完成了。

正解唯一索引只挡住“重复插入”，挡不住“重复更新”“部分成功”和“下游副作用”。比如先写业务表成功、再写审计表失败，重试时唯一索引让业务表跳过，但审计表仍然缺失；或者幂等键本身生成不稳定，每次重启都换新 UUID。幂等要覆盖整条写入链路，包括去重表、状态位、结果哈希，而不只是数据库一行约束。

为何常见：把数据库单点约束当成全链路保证，忽略了分布式事务边界。

面试题

Q1. 关于幂等的定义，下列说法正确的是：

单选题 · easy

  • A.幂等指操作系统永远不会失败
  • B.幂等指重复执行效果等同于执行一次← 正确答案
  • C.幂等指操作结果可复制到多个副本身
  • D.幂等指多次执行结果不断累加翻倍

答案：B。幂等的数学定义是 f(f(x)) = f(x)，重复执行与执行一次效果相同。A 说的是可用性，C 说的是副本复制，D 恰恰是幂等要避免的累加行为。驿站签收的例子：签一次入库一条记录，重复签收不会变成多条。

Q2. 幂等键（idempotency key）的作用最像生活场景中的：

单选题 · easy

  • A.快递单号，用于识别同一个包裹← 正确答案
  • B.收货地址，用于定位包裹的投递位置
  • C.快递员姓名，用于标识谁负责配送
  • D.包裹重量，用于决定配送的费用

答案：A。幂等键用于识别“同一业务事件”，即使它被重放多次，下游也能凭它认出是重复的。快递单号让驿站区分“同一包裹被送三次”和“三个不同包裹”，地址、快递员、重量都无法做到这一点。

Q3. 关于至少一次（at-least-once）投递语义，下列说法正确的是：

单选题 · mid

  • A.每条消息恰好只被处理一次
  • B.每条消息至少被尝试处理一次← 正确答案
  • C.每条消息最多被尝试处理一次
  • D.每条消息可能永远不会被处理

答案：B。at-least-once 允许重复、不允许丢失，是多数消息系统的默认语义。Kafka 消费端提交 offset 失败后回放，就会重复投递。A 是 exactly-once，C 是 at-most-once，D 是消息丢失，违背 at-least-once 的“至少”保证。

Q4. 指数退避（exponential backoff）的核心目的是：

单选题 · mid

  • A.让重试次数无限地增长下去
  • B.以越来越快的节奏去完成重试
  • C.逐次拉长间隔给下游恢复时间← 正确答案
  • D.让所有任务在同一时刻重试

答案：C。指数退避让等待间隔按 2 的幂增长（1s、2s、4s……），避免故障恢复瞬间所有任务同步重试造成惊群。A 是错误认知，重试次数上限由策略决定；B 是固定快速重试，反而会压垮恢复中的下游；D 是典型的反模式。

Q5. 下列哪种失败类型最适合立即重试：

单选题 · mid

  • A.请求参数校验失败（400 错误）
  • B.下游服务返回 5xx 或网络超时← 正确答案
  • C.用户鉴权失败（401 错误）
  • D.数据格式不合法（400 错误）

答案：B。可重试失败是暂时性的，如网络抖动、服务暂不可用（5xx）、限流（429）。A、C、D 是确定性失败，重试只会重复消耗资源，应直接失败或进死信。好比快递员只对“家里没人”改日再来，不会对“地址不存在”反复尝试。

Q6. 在“至少一次投递 + 幂等消费”组合中，去重表最合理的位置是：

单选题 · hard

  • A.只在生产端做，保证不重复发送
  • B.只在网络层做，保证不重复传输
  • C.消费端业务处理前写入，冲突则跳过← 正确答案
  • D.消费端业务处理之后再写入去重表

答案：C。生产端和网络层都无法保证端到端不重复（ack 丢失就会重发），必须在消费端拦截。正确顺序是“先查/写去重表，再执行业务”，或与业务在同一事务中原子写入。D 的问题在于业务处理到一半失败时，去重表没有记录，重试仍会重复处理。

Q7. 死信队列（DLQ）中积压的消息，正确的处理方式是：

单选题 · easy

  • A.定期清空，防止占用额外存储
  • B.直接忽略，因为都是脏数据
  • C.监控分析原因，修复后重放← 正确答案
  • D.立即无限重试，直到最终成功

答案：C。DLQ 是系统最后兜底，积压通常意味着系统性 bug：schema 变更、依赖故障或部署失误。正确做法是告警、排查、修复后重放。A、B 会丢数据，D 会引发雪崩。就像驿站退回的包裹要登记在案，而不是扔进垃圾箱。

Q8. 下列哪些是实现幂等的工程手段：

多选题 · mid

  • A.数据库唯一索引约束← 正确答案
  • B.状态机限制非法状态迁移← 正确答案
  • C.版本号乐观锁条件更新← 正确答案
  • D.提高消费者并行处理度

答案：ABC。唯一索引挡重复插入、状态机挡非法迁移、乐观锁保证并发条件更新，三者都是幂等的标准实现。D 提高并发度只增加吞吐，反而可能放大重复风险，与幂等无关。对应驿站台账、入库流程和扫码核对三层防线。

Q9. 关于重试与幂等的配合，下列说法正确的有：

多选题 · hard

  • A.有幂等保障时，可以更放心地重试← 正确答案
  • B.重试次数耗尽后，可进入死信队列← 正确答案
  • C.断路器可在下游故障时快速失败← 正确答案
  • D.幂等可以替代重试，无需再设重试

答案：ABC。幂等吸收重复，让重试无后顾之忧（A 对）；重试耗尽进 DLQ 是标准兜底（B 对）；断路器在下游持续故障时短路请求，防止重试雪崩（C 对）。D 错：幂等解决“重复结果正确”，重试解决“失败后恢复”，二者互补而非替代。

Q10. Kafka 幂等消费者处理一条消息的正确流程包括：

多选题 · extreme

  • A.先向上游确认成功，再处理业务
  • B.先查询或写入去重表，再处理业务← 正确答案
  • C.业务成功后提交该分区的偏移量← 正确答案
  • D.业务失败时回滚等待，稍后重试← 正确答案

答案：BCD。正确顺序是幂等检查在前（B），业务成功后提交 offset（C），失败则回滚重试或进 DLQ（D）。A 反了——处理成功后才向消息系统确认（提交 offset），先确认会导致消息丢失。整体体现“至少一次投递 + 幂等消费”的有效恰好一次语义。