理解与应用：幂等性设计原理-优快云博客

本文链接：https://blog.youkuaiyun.com/key_next/article/details/99705612

本文探讨了幂等的概念，强调了在支付、数据一致性等场景中幂等的重要性。介绍了几种实现幂等的方法，如CAS、唯一索引、分布式锁和操作前检查。并列举了导致重复处理的常见场景，如前端重复提交、消息重复消费等。在SCRM系统中，幂等主要应用于防止资损和状态不一致。文章还提出了幂等键设计和系统交互的规范，以确保正确处理重复请求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言：应TL的邀请，在团队内做一次幂等相关的总结和分享

一、幂等概念及使用

1、什么是幂等?

首先，我们需要了解下幂等的概念：https://baike.baidu.com/item/%E5%B9%82%E7%AD%89/8600688?fr=aladdin

注意这句话：“一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同”。这里的意思就是用户对于同一种操作发起的一次或者多次请求，其结果状态是一致的，不会因为多次请求而产生了其他影响。

2、为什么需要幂等

引用一个经典的例子，那就是支付。用户购买商品支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了。用户再次点击按钮，假设这里的请求没有做幂等处理，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条。而实际期望的是，一笔订单只进行一次扣款。

3、常见的幂等控制实现方式有哪些？

cas（通过db的状态、版本号字段来控制，根据更新操作的成功、失败状态来判断：update table set state = x1 where state = x2）
uniqe index（通过指定db的唯一索引来控制，处理前，先前置插入数据到db，捕获Duplicate Exception判断是否重复处理。至于唯一索引的选择，需要根据具体业务来决定，是内部控制还是外部业务传入）
分布式锁（通过分布式锁控制请求的并发处理、多次访问，比如Redis的 setnx）
操作前置select状态（这种处理方式只适合没有并发的情况，操作前，先查询是否被处理过，可以结合上面的三个幂等实现方式一起使用，防止过多的写操作及异常）

4、什么时候该使用幂等？

一般需要幂等的场景是写场景，并非所有场景下我们都需要幂等设计，只有一些数据敏感、需要保证强一致性的场景下才会需要。

当某个业务流程存在被重复处理的场景，且要求该业务流程无论被执行多少次，最终结果都要和只处理一次时的状态保持一致（请求的次数不影响最终处理状态），这时就需要幂等。

二、幂等场景

1、常见的导致重复处理的场景有哪些？

前端相同请求表单被重复提交。例如：①提交按钮被用户多次点击；②请求超时但实际处理成功，前端重试；
上层业务重复调用。例如：由于上层业务逻辑的不合理，重复调用底层服务处理。
请求超时重试。例如：rpc调用超时重试、代理层超时重试、中间件客户端超时重试等。
消息重复消费。例如：mq不保证消息唯一，可能重复推送；消息处理ack超时重复推送等。
任务调度中心重复调度。例如：定时任务、延时任务回调时，单个任务被多次重复调用。
单个请求业务处理时，部分流程异常。例如：处理单个请求时，步骤1成功、步骤2异常，步骤1未回滚，第二次请求时，步骤1仍会重复处理。
网络报文重发。一般极少出现，server端正常收到报文，但client端未收到ack，于是client端进行重发。

2、scrm存在哪些场景需要幂等？

①scrm资损场景：资损场景

②重复请求时，可能导致状态不一致的写服务（例如更新卡模板接口，新增权益项，商家在同一表单多次点击更新，可能会创建多个相同的权益项，这里就需要幂等；但是对于禁用卡模板来讲，无论禁用多少次，最终卡模板都会是禁用状态，这种场景就不需要幂等）。

三、幂等使用规约

1、幂等键设计

业务内部保证幂等：业务自身的特性决定了需要保证强一致性，业务内部组合部分业务字段做幂等键。例如：扣减库存，库存业务本身需要保证单笔订单只会被扣减一次。
业务外部保证幂等：业务自身并不需要保证幂等，但由于上层业务的需求，支持幂等处理；业务方传入source来源、seq序列号，source+seq在做幂等键，防止重复处理请求。例如：发放优惠券，优惠券本身调用多少次，就发放多少次，但是很多业务方需要做内部业务逻辑的幂等，防止重发；比如升级发放优惠券时，需要确保只能发放一次，这时优惠券提供幂等能力，而幂等键由上层业务决定。