Java后端接口幂等性设计的四种方案与取舍

在分布式系统和高并发场景下，接口幂等性早已不是“加分项”，而是“保命项”。用户点击按钮提交订单，网络抖动导致重试，MQ消息重复消费，第三方回调重复通知……任何一个环节没有幂等保护，都可能造成重复扣款、重复下单、数据错乱等严重事故。所谓幂等，就是同一个请求无论执行多少次，结果都保持一致。今天我们就聊聊Java后端常见的四种幂等性设计方案，以及它们各自的适用场景和取舍。

一、唯一索引与数据库约束

最简单粗暴也最可靠的方式，是利用数据库的唯一约束来保证幂等。比如在订单表里增加一个`biz_id`字段，并建立唯一索引。每次插入前先查一次，或者直接插入捕获`DuplicateKeyException`。这种方式能从根本上防止重复数据落库。

优点是实现简单，强一致，不需要额外组件。缺点是只能针对“插入”类操作，对于“更新”类操作需要额外设计；而且数据库性能会成为瓶颈，高并发下唯一索引冲突带来的异常处理也有一定开销。适合对一致性要求极高、写并发不太夸张的场景，比如创建支付流水。

二、Token令牌机制

这是前后端交互中最常见的方案：客户端在请求前先向服务端申请一个全局唯一的token，服务端将其存储在Redis中并设置过期时间；真正提交业务请求时，客户端携带该token，服务端先校验并删除token，删除成功才继续执行，否则拒绝。

这种方案的核心在于“先取后删”的原子操作，通常用Redis的`getAndDelete`或Lua脚本实现。优点是能覆盖绝大多数写操作，且对业务代码入侵小。缺点是需要额外一次网络交互，且如果token丢失或过期，用户需要重新获取，体验略差。同时，如果服务端是集群部署，Redis必须共享，不能使用本地缓存。适合表单提交、订单创建等用户主动发起的操作。

三、状态机与乐观锁

对于订单这类有明确状态流转的对象，状态机本身就是一种天然的幂等屏障。比如订单状态只有`待支付 -> 已支付 -> 已发货 -> 已完成`，更新时带上当前状态作为条件：

UPDATE order SET status = 'PAID'
WHERE order_id = 123 AND status = 'WAIT_PAY'

如果更新影响行数为0，说明状态已经变了，这条请求就是重复的，直接返回成功即可。这种方案本质上是乐观锁的变种，通过版本号或状态字段来控制。

优点是无需额外存储，性能好，语义清晰。缺点是只能用于状态流转明确的场景，对于复杂的非状态型更新无能为力。设计时务必保证状态枚举的顺序和迁移路径是严格限定的，否则容易留下后门。

四、分布式锁与去重表

当业务操作不单纯是数据库写操作，还涉及调用外部API、发送消息等副作用时，状态机就不够用了。此时可以在执行前先获取一把分布式锁（基于Redis或Zookeeper），锁的key就是幂等ID，比如`order:pay:123`。获取锁成功的才执行，执行完释放锁。或者使用去重表，在业务操作前向去重表插入一条记录，插入成功才继续，失败则说明已处理。

分布式锁的粒度控制很关键，锁太粗会串行化所有请求，太细则可能锁不住真正的临界区。另一个风险是锁的持有时间与业务执行时间不匹配，超时自动释放后，第二个请求又进来了。因此最好配合去重表或状态标记做二次校验，形成“双保险”。

取舍建议：对于有状态流转的核心业务，优先使用状态机；对于必须保证唯一落库的记录，用唯一索引兜底；对于外部系统触发的接口，如回调、MQ消费，用Redis幂等表（去重表）最简单；而涉及多步骤复杂业务，可以组合使用分布式锁加上数据库约束，毕竟没有银弹，只有权衡。

总结

幂等性设计不是孤立的某个技术点，而是需要你根据业务的并发量、一致性要求、故障容忍度来综合决策。设计时记住一个原则：让每次请求都拿到同一个结果，而不是让每个请求都执行一遍过程。凡是无法通过算法天然保证幂等的地方，就用存储的特性去兜底。实际项目中，往往多种方案混合使用，比如外接API用token，内部写库用唯一索引，订单流转用状态机。理解了各自的取舍，你在面对面试官或团队评审时，就能讲出“为什么选它，而不选另一个”的底气了。