幂等性定义

• 一次支付请求和重复提交多次支付请求，最终只能扣款一次。
• 一次创建订单请求和重复提交多次创建订单请求，最终只能生成一笔订单。
• 同一个消息被 MQ 重复投递多次最终只能执领域务一次。不过，

使用者常见痛点

• 重复扣款或扣库存使用者在网络抖动、页面刷新或误点“确认”时会看到资金或商品被二次扣除。
• 订单/流水号冲突在秒杀、抢购等高并发场景，程序往往出现“订单已存在”或“流水号重复”的异常提示。
• 前端渲染重复AI 对话流式输出时同一段文本被多次推送导致页面内容重复、语义混乱。
• 程序性能下降每一次重复请求都进入业务层进行实际处理，导致数据库写入冲突、锁竞争激增。
• 难以定位根因缺少统一的幂等标识，使得排查“为何出现两笔相同交易”变得异常困难。

常见场景

• 支付场景：支付程序必须保证同一笔支付请求不会被重复扣款，这是支付网站对使用者资金安全最基本的保障。其实，

• 订单场景：避免使用者因重复点击、网络重试或消息重复投递而重复下单。还需要防止同一使用者重复创建订单并多次扣减库存。

• AI 对话场景：在流式输出过程中。不要同一段文本或同一个 Token 被重复推送，否则可能出现前端内容重复，甚至引起语义错误。

再看主要思路。幂等 Key

幂等 Key 必须能够唯一标识一次业务操作，而不能只标识某个接口或某类业务。常见生成方式示例：

业务名称 + 业务主键
# 示例
payment_10001_order_20001_message_30001_10

基于业务状态机实现幂等

对于具有明确状态流转的业务。可以利用业务 ID 与当前状态进行条件更新，实现乐观锁效果。怎么说呢，

假设状态只能按顺序流转：

A → B → C

将状态从 A 更新为 B 的 SQL 示例：

UPDATE table_name
SET status = 'B'
WHERE id =?AND status = 'A';

• 影响行数 = 1 → 状态变更成功。
• 影响行数 = 0 → 状态已不是 A，说明是重复请求或非法流转。按理说，

基于唯一键去重

为每一次业务操作生成唯一 Key。 并依靠以下手段做去重：

① Redis SET NX

SET idempotent_key CONSUMING NX EX 300

② 数据库唯一索引

CREATE UNIQUE INDEX uq_payment_no ON payments;

A I 对话流式输出示例：

requestId_offset // 如 chat_10001_0、chat_10001_10 等

前端维护已处理偏移集合；说起来，收到相同偏移时直接丢弃；服务端写库时可在表上建立 唯一索引防止重复插入。

基于 MQ + Redis 消费状态实现幂等

第一次消费流程

1. 收到消息 → 根据业务生成幂等 Key（如 {bizName}:{msgId})。
2. 使用 Redis SET NX 写入状态 C​ONSUMING​。成功则获得消费资格，说到执领域务逻辑。
   • 成功 → 将 Redis 值改为 C​ONSUMED​.失败 → 删除 Key 或让其自然过期，以便后续重试。

     重复消费处理逻辑

     • Status = CONSUMING： 说明其他使用者正在处理。此时应抛异常，让 MQ 稍后重新投递。其实，
     • Status = CONSUMED： 已经成功处理过直接返回消费成功即可。避免 执领域务，

     数据库唯一约束作为最终兜底

     Redis 并非绝对可靠；如果出现 “DB 写入成功 → Redis 更新失败” 场景。则可能导致 MQ 投递，同一事务 执行。为关键业务仍需依赖数据库唯一约束或状态机做最终防护。

      CREATE UNIQUE INDEX uq_payment_no ON payments;

     再看综合方案示例，

      Redis 快速拦截 + DB 唯一索引/状态机 最终兜底
     

     ---

     要点

     • **明确幂等 Key**：业务名称 + 主键/消息 ID + 可选上下文。
     • **首选轻量级拦截**：Redis SET NX 或缓存层去重，可把大多数冗余请求挡在入口。其实，
     • **持久化兜底**：对关键表加唯一索引或采用状态机更新。使即使缓存失效也不会产生副作用。
     • **统一错误码/日志**：当检测到 “已消费” 时返回特定幂等码并记录日志，帮助运维快速定位 “为何出现两笔相同交易”。
     • **监控指标**：监控 Redis SET NX 命中率、DB 唯一冲突次数还有 MQ 重投次数，可及时发现幂等失效风险。