当前位置：首页 > news >正文

Redis 实现接口幂等性的三种高效策略

news 2026/6/4 4:39:33

1. 接口幂等性基础认知

第一次听说"幂等性"这个词时，我正盯着生产环境里两条完全相同的订单记录发愁。用户只是抱怨页面卡顿多点了两次提交按钮，结果系统就产生了重复数据。这种场景就像你去ATM机取钱，输入密码后机器没反应，于是你又按了一次——如果银行系统没有幂等性控制，你的账户可能就被扣了两次款。

幂等性的数学本质其实很简单：f(x) = f(f(x))。翻译成程序员能理解的话就是：无论调用多少次，结果都和调用一次相同。在HTTP协议中，GET、PUT、DELETE都是幂等的，而POST是非幂等的。这就像你刷新网页(GET)不会改变内容，但重复提交表单(POST)就可能产生多条数据。

在实际业务中，这些场景最容易出现幂等问题：

支付系统：网络超时导致重复扣款
订单创建：用户快速点击生成多个订单
库存扣减：并发请求导致超卖
消息队列：消费者重试造成重复处理

我曾遇到过最棘手的案例是医院挂号系统：某个专家号被重复预约了三次。排查发现是移动端在网络抖动时自动重试导致的。这就是为什么我们需要Redis这样的利器——它不仅能解决幂等问题，还能保持系统的高性能。

2. Token机制：先领票再办事

去年给电商系统做秒杀功能时，Token机制帮了大忙。它的原理就像银行排队：先取号(Token)，等叫到号才能办理业务。具体实现分为五个步骤：

客户端调用/getToken接口获取令牌
服务端生成UUID作为Token，存入Redis并设置过期时间
客户端提交业务请求时携带该Token
服务端校验Redis中是否存在该Token
存在则删除Token并处理业务，不存在则拒绝请求

这里有个关键细节：检查Token和删除Token必须是原子操作。我早期版本用两步操作就踩了坑：

// 错误示范！非原子操作可能重复处理 if(redisTemplate.hasKey(token)) { redisTemplate.delete(token); processRequest(); }

后来改用Lua脚本保证原子性：

-- KEYS[1]是token键名 if redis.call('GET', KEYS[1]) then redis.call('DEL', KEYS[1]) return true end return false

在SpringBoot中的完整实现：

@RestController public class TokenController { @Autowired private StringRedisTemplate redisTemplate; @GetMapping("/token") public String getToken() { String token = UUID.randomUUID().toString(); redisTemplate.opsForValue().set( token, "1", 5, TimeUnit.MINUTES); // 5分钟过期 return token; } @PostMapping("/submit") public ResponseEntity<String> submit( @RequestHeader("X-Token") String token) { String script = "if redis.call('GET', KEYS[1]) then " + " redis.call('DEL', KEYS[1]) " + " return true " + "end " + "return false"; Boolean result = redisTemplate.execute( new DefaultRedisScript<>(script, Boolean.class), Collections.singletonList(token)); if(Boolean.TRUE.equals(result)) { // 处理业务逻辑 return ResponseEntity.ok("成功"); } return ResponseEntity.badRequest().body("请勿重复提交"); } }

实际踩坑经验：

Token过期时间要根据业务合理设置（支付类建议5分钟）
前端需要实现Token自动获取和重试机制
在高并发场景下，Redis可能需要分片部署

3. 唯一序列号：给每个请求办身份证

物流系统的运单号给了我灵感——为什么不用唯一ID来标识每个请求呢？这种方案特别适合第三方系统对接：

调用方生成唯一请求ID（如订单号）
调用接口时携带该ID
服务端将ID作为Redis Key存入
重复请求会被Redis拦截

public boolean checkRequestId(String requestId) { // SETNX + EXPIRE 原子操作 Boolean result = redisTemplate.opsForValue().setIfAbsent( "req:" + requestId, "1", 10, TimeUnit.MINUTES); return Boolean.TRUE.equals(result); }

性能优化技巧：

对RequestId做MD5压缩减少存储空间
使用Redis集群提高吞吐量
针对热点请求可以采用本地缓存+Redis二级校验

在物流轨迹更新系统中，我们结合了唯一序列号和版本号：

UPDATE package_tracking SET status = 'DELIVERED', version = version + 1 WHERE package_id = ? AND version = ?

这样即使重复请求，数据库层面的乐观锁也能兜底。

4. 分布式锁：业务处理的VIP通道

大促时库存系统的惨痛教训让我意识到：有些业务需要强一致性保障。Redis分布式锁就是解决方案：

public String deductStock(String productId) { String lockKey = "lock:stock:" + productId; String clientId = UUID.randomUUID().toString(); try { // 尝试获取锁 Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS); if(Boolean.TRUE.equals(locked)) { // 处理核心业务 return "扣减成功"; } return "系统繁忙请重试"; } finally { // 确保只释放自己的锁 String script = "if redis.call('GET', KEYS[1]) == ARGV[1] then " + " return redis.call('DEL', KEYS[1]) " + "else " + " return 0 " + "end"; redisTemplate.execute( new DefaultRedisScript<>(script, Long.class), Collections.singletonList(lockKey), clientId); } }

关键注意事项：

必须设置锁的过期时间，防止死锁
每个客户端使用唯一标识，避免误删他人锁
考虑锁续期问题（复杂场景可用Redisson）
锁粒度要尽可能细（如按商品ID加锁）

在秒杀系统中，我们最终采用了分段锁方案：将100个商品库存分成10组，用10个锁来减少竞争。配合Redis集群，QPS从最初的200提升到了5000+。

5. 方案选型指南

面对具体业务场景时，我的选择策略是这样的：

方案	适用场景	性能影响	实现复杂度	可靠性
Token机制	用户交互类操作（表单提交）	中	低	高
唯一序列号	第三方系统对接	低	中	中
分布式锁	资金/库存等强一致性场景	高	高	高