手抖点了两次付款，为什么没扣我两笔钱？聊聊接口幂等性

【幂等性】分布式系统基石：深入解析幂等性设计与实现方案

人生没有太晚的开始

前言

• 用户在手机弱网环境下买东西，点击“立即支付”，界面转圈圈没反应。用户心急又点了一次。

• 浏览器发出了两次请求，如果后端没有幂等处理，用户就会被扣两次款。这在生产环境中是 P0 级事故。

• 为了解决这个问题，我们需要引入“幂等性”。

一、概念定义——什么是幂等？

定义：对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。

生活中的例子：

• 电梯按钮（幂等）： 你按一次“10楼”，电梯去10楼；你狂按一百次，电梯还是去10楼，不会飞出去。

• 取款（非幂等）： 你取100块，卡里少100；你连取两次，卡里少200。

HTTP 语义中的幂等：

• GET（查询）：天然幂等。

• PUT（更新）：通常是幂等的（把 A 改成 1，改多少次 A 都是 1）。

• POST（新增）：非幂等（每次调用都会创建新资源），这是我们要防范的重点。

二、保证幂等解决方案

1.前端置灰按钮（不能保证幂等）

当用户点击了一次扣款按钮后，前端将按钮置成灰色，防止用户提交两次。
问题

• 可以通过postman等工具重复发送请求
• 当网络波动时，通常会有重试机制导致重复发送

2.数据库唯一索引（Unique Key）

这是博主在项目中使用的一种方式，通过设置了唯一索引，就算多个重复请求，数据库会抛出异常，保证了幂等性。
适用：插入型操作（防重），例如插入一条新订单，不会插入两条。
缺点： 依赖数据库，分库分表时需要注意路由。

3.乐观锁

原理： update t_goods set count = count - 1, version = version + 1 where id = 1 and version = 1。
核心： 带上版本号。如果别人改过了，版本号变了，你的 SQL 就不生效。
适用： 更新库存、扣款。

4.防重Token令牌

原理：

• 进入页面前，先请求后端拿一个 Token。后端从redis拿一个Token返回。

• 前端提交表单时带上这个 Token。

• 后端执行 Redis.del(Token)。如果删除成功（返回1），说明是第一次，进入业务流程；如果删除失败（返回0），说明已经提交过了。
  

核心：在业务流程开始前进行了幂等判断，而不是像第一种数据库唯一索引那种方法（在业务中抛异常来确保幂等）。

5.分布式锁

原理：类似于防重Token令牌，也是在业务进行前进行幂等处理，业务执行前先抢锁（key=业务唯一ID），执行完释放锁。
注意点： 锁要设过期时间（防死锁）；还要考虑一下看门狗机制的引入（防止业务流程还没有完成就释放了锁）

6.状态机幂等（Status Machine）—— 业务层面的优雅

这个例子有点像乐观锁，这个方案的核心在于：流程不可逆，利用当前状态做天然屏障。

生活中的例子
快递状态：待发货 -> 已发货 -> 已签收。

如果现在的状态是 已发货，你发来一个指令说“把状态改为已发货”，系统执行也没事（结果不变）。

如果现在的状态是 已签收，你发来一个指令说“把状态改为已发货”，系统直接拒绝，因为流程不能倒着走。

技术实现细节
这是最优雅、性能最好的方案，因为它不依赖 Redis，直接利用业务数据库的行锁。

SQL 的魔法： 不要先 SELECT 查状态，再 Java 判断，再 UPDATE（这会有并发缝隙）。 要直接把条件写在 UPDATE 语句里。

UPDATE ordersSETstatus='PAID'WHEREid=123ANDstatus='PENDING';

只能由PENDING变为PAID，不可能倒过来。

总结与最佳实践

• 不要过度设计： 不是所有接口都要幂等，查询接口不需要，QPS 很低且允许少量重复的后台接口也没必要搞太复杂。

• 唯一 ID 是关键： 无论是哪种方案，都需要一个全局唯一的 ID来标识“这是同一个请求”。

• 推荐组合： 这里的“银弹”通常是 Token 机制（防误触） + 数据库唯一索引（兜底）。

以上就是幂等的内容了，有任何不足欢迎大佬指正。如果文章对您有所帮助，请务必点赞，收藏，您的支持就是我的最大动力！