分布式事务：幂等性设计

可视化演示

动态展示幂等原理、唯一ID去重流程、四种实现策略与状态机约束机制。

幂等基础

自动售货机的小管家是个非常较真的人。他每天收钱出货，但有一条铁律：同一张订单号，只出一次货。你可能会问：如果客人明明被扣了两次款，凭什么只出一次货？小管家的回答是：因为这是同一笔订单的重复通知，不是新生意。他要做的，是把多出来的那次扣款退回去，而不是再搬一瓶水。这就是幂等性的生活原型——同一件事，做一次和做多次，世界不该因此改变。

在技术世界里，我们把“做一次和做多次结果都一样”的操作称为幂等操作。数学上可以写成 f(f(x)) = f(x)：不管对同一输入执行多少次操作函数 f，最终的结果都等于只执行一次。注意，幂等不等于“只执行一次”，而是“重复执行的副作用为零”。系统无法阻止请求重复到达，但它可以保证重复到达后不再重复生效。

为什么分布式系统特别需要幂等？因为分布式环境里没有可靠的“一次且仅一次”投递。网络会超时，客户端会重试，消息队列会重投，用户会手抖连点。任何一环都不是百分之百可靠，而幂等性是让整个链路在不确定性中保持业务一致性的“安全气囊”。它和“防重”也有区别：防重是并发场景下的去抖（比如 1 秒内只让一个请求通过），而幂等要对付的，是已经成功执行过后再次到达的“幽灵请求”。

回到小管家的账本，他判断“这单是不是重复”靠的不是记忆，而是规则：订单号相同，就是同一件事。第一笔真正出货，账本记下；后续相同的订单号进来，直接调出上次的结果回复客人——“您的水已经出过了，在取货口呢”。数学上等价于 f(f(x)) = f(x)：无论同样的指令来多少次，货只出一瓶，结果一直是那瓶水。

唯一请求 ID

小管家最怕两单生意长得一模一样。假如两个客人同时买了一款同样的水，付的钱也一样，光看内容根本分不清谁是谁。还好每张支付回执单上都有一个“订单号”——这是这笔交易从生到死都不变的身份证。凭借这串数字，小管家才能知道：哦，这单号我见过，这是刚才那笔的重复通知。

在系统里，这个身份证就是唯一请求 ID（Request ID / Idempotency Key）。它的核心作用是让所有下游节点都能识别“这是哪一笔操作”。如果请求里没有这个 ID，服务端就只能靠“参数是否完全一致”来猜测，面对参数相同的两笔合法请求就会误伤——所以唯一请求 ID 是幂等设计的基石。

唯一请求 ID 的生成要满足两个要求：全局唯一、尽量有序。业界常用方案有 UUID、数据库自增 ID，以及高并发下常见的雪花算法（Snowflake）。雪花算法把 ID 拆成三部分：时间戳 + 机器编号 + 序号，既能保证唯一，又能让 ID 大体递增，有利于数据库索引。生成后，ID 由客户端在发起请求时创建，放在请求头或消息体中一路透传到服务端；服务端拿到后，把它作为幂等键存入数据库或 Redis，配合后续的去重表、状态机一起使用。

有了订单号这枚“身份证”，小管家的账本才有意义。他不需要去比对两位客人的长相、买的水是不是同一个牌子——只看订单号，就能认出谁是新客户、谁又是同一笔订单换了身衣服又来敲门。这就是唯一请求 ID 在整个幂等体系里的位置：它是所有后续方案的前置基础。

去重表方案

小管家管自己叫“记账型选手”。他每天上岗第一件事，就是把出货记录册摊开：每出一瓶水，就在册子上工工整整写一行“订单号 + 已出货 + 时间”。下一次再有订单号过来，他先翻册子——查到了就直接说“这单出过了”，查不到才动手出货。这本册子，就是去重表。

去重表方案是最直观的幂等实现：单独建一张“幂等记录表”，主键或唯一键就是请求 ID。每次请求到达时，先查这张表；如果已存在记录，说明是重复请求，直接返回首次处理的结果；如果不存在，则执行业务逻辑，同时向去重表插入一条记录。图省事的话也可以把幂等键直接挂在业务表上作为唯一索引，比如“订单号唯一”，让数据库来强制去重。

去重表最关键的机制是“插入时的唯一约束兜底”。为什么不能只做“先查再插”？因为在高并发下两个相同的请求可能同时通过查询，都发现“查无此单”，然后都去执行业务——重复就发生了。解决办法是给请求 ID 建唯一索引：两个请求同时插入时，数据库保证只有一个能成功，另一个插入直接报唯一键冲突，冲突方把这次操作视为“已被别人处理”，不再执行业务。这样即使业务层竞争失败了，数据层也绝不放水。去重表的缺点是记录会不断增长，所以需要定期清理（例如只保留最近 30 天），或者按日期分表归档。

小管家的出货记录册有一个死规矩：册子上每一行订单号都只能用一次，谁也别想涂改。正因为册子背后有“一条订单号只能写一行”的铁律，他才敢在客人催单时说：“这单早出过了，您去取货口看看。”——账本不乱，生意就不乱。

乐观锁机制

后来售货机生意太好，一台机器配了两位小管家。麻烦来了：两位管家可能同时翻开记录册，同时看到“订单号 10086 还没有出货记录”，然后同时搬起饮料往出货口塞——两瓶水卡在一起，货道直接崩了。小管家的对策是在记录册上盖“版本号”印章：谁要改这一行，先记下当前版本号，落笔时如果版本号没变才允许写；如果发现别人已经改过了，这一笔就算白抢。

这就是乐观锁（Optimistic Lock）的思想。它不锁数据，而是靠“版本号比对”保证并发改写的安全性。业务表里加一个 version 字段，每次更新时带着当初读到的 version 作为条件：UPDATE … SET version = version + 1 WHERE version = 旧版本。如果更新的影响行数是 1，说明这期间没有人改过，操作成功；如果影响行数是 0，说明 version 已经变了，操作失败，需要重读后重试或放弃。

乐观锁非常适合“并发竞争少、冲突频率低”的场景，例如防止订单金额被重复扣减、库存被超卖。它与去重表的区别在于：去重表解决的是“同一请求来了两次”，乐观锁解决的是“不同请求同时改同一行数据”。二者经常组合使用：去重表挡住重复请求，乐观锁挡住并发竞争。需要注意，乐观锁不适合写冲突极高的热点数据——如果同一把库存每秒被抢 10 万次，乐观锁会大量失败重试，反而拖垮系统，这时应该换用分布式锁或队列化。

两位管家后来养成了好习惯：动手改记录册之前，先看一眼右上角的“版本号”。如果还是自己刚才记下的那个数字，就放心下笔；如果已经被人加过一横，就乖乖合上册子退一步。这份“核对再落笔”的默契，让两个管家能同时在店里忙碌，而账本永远不会乱。

状态机方案

小管家的出货记录册越写越厚，他发现光记“已出货”不够。比如客人付款后网络断了几秒，他这边已经扣了款、正在出货，这时订单来了，他该怎么说？总不能翻遍册子说“查无此单”然后再扣一次款。于是他把册子升级成了“状态条”：每笔订单从生到死，必须依次经历「待出货 → 出货中 → 已出货」三个阶段。

这个思路在系统设计中叫状态机（State Machine）：把业务对象建模成一组有限状态，只有在规定的顺序里才能从一个状态跳到另一个状态。比如订单的状态依次是“待支付 → 已支付 → 已发货 → 已完成”，任何一步都不能跳级或倒流。重复请求到达时，状态机只需检查当前状态：如果订单已经在“已完成”这种终态，任何后续事件都不会改变它。

状态机天然具备幂等性，因为它的核心是“状态决定行为，而不是次数决定行为”。比如支付回调进来时先查订单状态：如果订单是“待支付”，就执行入账并把状态推进到“已支付”；如果订单已经是“已支付”或“已完成”，说明这笔回调是重复消息，直接返回成功，不再动账。终态尤其重要——终态一旦达到，必须拒绝一切流转，这样哪怕同一个事件被重投一万次，业务也纹丝不动。状态机的实现可以是数据库里的状态字段加校验逻辑，也可以引入专门的状态机框架。

有了状态条，小管家面对客户的连环追问再也不慌了。“出货中？稍等，正在掉货。”“已出货？去取货口拿吧。”最妙的是一旦订单盖上了“已出货”的终态章，哪怕客户把订单号报上一百遍，他也只会指着取货口说同一句话。状态机的魔法就在这：答案由状态决定，与询问次数无关。

策略选型

同样是售货机，摆在早晚高峰的地铁站和摆在景区门口，脾气完全不同。地铁站的机器每分钟被扫几百次，顾客排队，网络经常抖动，重复回调像下雨一样密——小管家必须用最轻快的手段挡下大部分重复；景区门口的机器一天开不了几单，偶尔来一单重试，小管家有充分时间慢慢翻册子。

这就是幂等方案的选型问题：没有银弹，只有取舍。核心判断维度有三个：重复请求量有多大、写冲突有多激烈、能不能接受额外的存储成本。网络重试场景下，因为系统层面无法阻止重试，通常用“唯一请求 ID + 去重表”来兜底；消息队列场景下，很多 MQ 只能保证 at-least-once（至少一次）投递，消费端必须靠状态机或去重表自行去重；高并发场景下，要把压力最重的那条路用乐观锁和状态机顶住，把去重表的查询尽量前置到缓存。

组合运用是生产环境的常态。一个典型的订单接口会这样分层：第一层，前端和网关携带唯一请求 ID；第二层，Redis 缓存快速判断“这个 ID 最近是否见过”，挡住 99% 的重复请求；第三层，数据库去重表用唯一索引做最终裁决；第四层，订单表用版本号乐观锁防止两个不同请求同时改同一订单；第五层，订单状态机保证终态后再来的任何消息都进不了业务逻辑。层层设防，每一层都能独立兜底。另外，在引入“失败重试 n 次”策略前，一定要确认操作是幂等的——否则重试越多，账错得越离谱。

地铁站的小管家把防重复的活儿分给了三道工序：门口快速看一眼订单号（缓存）、柜台核销记录册（去重表）、出货口核对状态条（状态机）。景区的小管家则只需要一本册子慢慢翻。选型不是找最贵的兵器，而是摸清自己站台的客流强度，再决定把防线铺在第几层。

实践复盘

月底，售货机厂商来巡查。老板撂下一摞投诉单：“这个月有 3 个客人说被扣了两次款，还有 5 个说水出了但没扣款。小管家，你的册子是怎么记的？”面对事故，小管家不慌，他有固定的排查三步：先找出这笔订单的订单号，再查记录册上有没有登记，最后看订单当前处于哪个状态。证据链一旦串起来，问题出在哪个环节一目了然。

生产环境的幂等故障排查，遵循同样的三步走：第一步确认请求是否携带了唯一请求 ID，以及这个 ID 在整条链路中有没有被透传；第二步查幂等记录（去重表、Redis 缓存）里有没有对应条目，检查插入是否命中唯一索引；第三步查业务对象的状态，看它停在了哪一步。顺序很重要——先确认“是不是同一笔”，再判断“有没有被执行过”，最后看“执行到什么程度”。

幂等性设计上线时就要配套监控告警：去重表命中率（重复请求占比）、唯一索引冲突次数、状态机非法流转次数、幂等拦截率的变化曲线。用幂等率 R 衡量有效性。一个典型的生产案例复盘：某支付系统在网关升级后，部分回调丢失了原始请求 ID，服务端用“子订单号 + 时间戳”重新拼了一个不够唯一的幂等键，导致同一笔订单产生了多条记录，重复入账——最后通过固定幂等键生成规则、增加状态机终态校验才彻底修复。

小管家把三个月的记录册摊在会议室桌上，用订单号做索引，一条一条核对状态，最后定位到问题：上周更换新记录册时，有一页纸没印版本号栏。他连夜补上这一栏，并给册子加了“终态红印”。厂商老板听完点了点头：“有订单号可查、有记录可对、有状态可验——这套账本，才是售货机真正值钱的东西。”

AI 应用场景

Python 演示

import threadingimport timeimport uuidfrom datetime import datetime  class IdempotentProcessor:    """幂等处理器：相同 request_id 只执行一次业务"""     def __init__(self):        self._store = {}        self._lock = threading.Lock()     def process(self, request_id, business_func):        with self._lock:            if request_id in self._store:                return self._store[request_id], False  # 命中幂等            result = business_func()                    # 真正执行一次            self._store[request_id] = result            return result, True  def main():    processor = IdempotentProcessor()    call_count = []     def deduct_balance():        """模拟扣款业务：真实环境里这里是改库操作"""        time.sleep(0.05)        call_count.append(1)        return "扣款成功"     request_id = str(uuid.uuid4())    # 两个线程同时用同一个 request_id 发起请求，模拟网络重试    threads = [        threading.Thread(target=lambda: processor.process(request_id, deduct_balance)),        threading.Thread(target=lambda: processor.process(request_id, deduct_balance)),    ]    for t in threads:        t.start()    for t in threads:        t.join()     print(f"实际执行业务次数: {len(call_count)} (期望 1)")    print(f"幂等存储记录数: {len(processor._store)} (期望 1)")    print(f"当前时间: {datetime.now().strftime('%H:%M:%S')}")  if __name__ == "__main__":    main()

1. self._store = {}用字典模拟去重表，键是请求 ID，值是首次处理结果。
2. if request_id in self._store:查重逻辑：命中说明请求已处理过，直接返回旧结果，不再执行业务。
3. result = business_func()只有首次到达的请求才会真正调用业务逻辑，这份“第一次”是被幂等机制保护起来的。
4. self._store[request_id] = result处理完后把请求 ID 记入“去重表”，后面的重复请求就能查到了。
5. with self._lock:加锁避免两个线程同时查重都判断为“未处理”，从而造成重复执行。

常见误区

面试题