【幂等性】分布式系统基石：深入解析幂等性设计与实现方案
人生没有太晚的开始
文章目录
- 【幂等性】分布式系统基石：深入解析幂等性设计与实现方案
- 前言
- 一、概念定义——什么是幂等？
- 二、保证幂等解决方案
- 1.前端置灰按钮（不能保证幂等）
- 2.数据库唯一索引（Unique Key）
- 3.乐观锁
- 4.防重Token令牌
- 5.分布式锁
- 6.状态机幂等（Status Machine）—— 业务层面的优雅
- 总结与最佳实践
前言
用户在手机弱网环境下买东西，点击“立即支付”，界面转圈圈没反应。用户心急又点了一次。
浏览器发出了两次请求，如果后端没有幂等处理，用户就会被扣两次款。这在生产环境中是 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 机制（防误触） + 数据库唯一索引（兜底）。
以上就是幂等的内容了，有任何不足欢迎大佬指正。如果文章对您有所帮助，请务必点赞，收藏，您的支持就是我的最大动力！
