微服务中请求的幂等方案

Thu, 23 Jul 2026 00:00:00 +0000

幂等的意思是：同一个请求无论执行一次还是多次，产生的副作用都和只执行一次一样。

在微服务架构中，网络是不可靠的。客户端超时重试、消息队列重复投递、用户手抖连点两次按钮，都会导致同一笔业务操作被重复提交。如果不做幂等，扣款可能扣两次，订单可能创建两条——这比服务挂了还危险。

先记住三句话：

幂等不是性能优化，是正确性保障。 它保证在重试场景下业务结果唯一，不保证性能。
幂等键的设计决定了方案的可靠程度。 键选错了，整个幂等机制形同虚设。
没有万能方案，只有适合你场景的方案。 Redis 快但有丢失风险，数据库稳但性能有限，删 Token 简单但只适合一次性的场景。

方案一：Redis 幂等键

原理

在请求到达业务层之前，用唯一请求 ID（通常是客户端生成的 UUID）去 Redis 里查一次：

键不存在 → 执行业务，执行完后 SET key 1 EX 300
键已存在 → 说明是重复请求，直接返回已有的结果或拒绝

func (s *OrderService) CreateOrder(ctx context.Context, reqId string, req CreateOrderReq) (*Order, error) {
 // 1. 幂等检查
 key := fmt.Sprintf("idempotent:order:%s", reqId)
 ok, err := s.redis.SetNX(ctx, key, "processing", 5*time.Minute).Result()
 if err != nil {
 return nil, err
 }
 if !ok {
 // 重复请求，直接返回已有结果
 result, _ := s.redis.Get(ctx, key+":result").Result()
 return s.parseOrderResult(result)
 }

 // 2. 执行业务
 order, err := s.create(ctx, req)
 if err != nil {
 // 业务失败要释放锁，允许重试
 s.redis.Del(ctx, key)
 return nil, err
 }

 // 3. 缓存结果
 result, _ := json.Marshal(order)
 s.redis.Set(ctx, key+":result", result, 5*time.Minute)
 return order, nil
}

关键细节

用 SETNX 而非先查后设，避免并发下的竞态。SETNX 是原子操作。
必须设过期时间，否则死 key 会撑爆内存。过期时长要大于单次请求的最长处理时间。
业务失败要删除幂等键，否则客户端想重试都没机会。也可以用状态机：processing → success/failed。
值里存处理状态，而不是只存 1。这样并发请求进来时可以根据状态做更精细的判断。

适用场景

请求量大的读写服务
能接受极低概率的 Redis 数据丢失（可配合持久化策略降低风险）
幂等键由客户端生成（UUID），不依赖业务数据

方案二：数据库防重表

原理

在数据库里建一张专门的防重表，利用数据库的唯一索引 + INSERT 来拦截重复请求。

幂等 on giftiaのblog

微服务中请求的幂等方案

方案一：Redis 幂等键

原理

关键细节

适用场景

方案二：数据库防重表

原理