## 01、痛点

某天凌晨两点，我们的支付服务告警响了：同一个订单居然被扣了两笔钱。查日志发现，支付回调被上游重试了三次，而我们用 Redis 加锁，在 finally 里直接执行了 DEL lockKey。更巧的是，第一次请求处理得太慢，锁超时自动释放，第二个请求拿到了锁，等第一个请求慢悠悠醒过来，反手一个 DEL，把第二个请求的锁删掉了。第三个请求趁虚而入，重复支付。我是老李，那一刻我意识到，Redis 协调代码看似简单，实际上遍地是坑。

这类问题在分布式系统里太常见了。Redis 经常被用来解决分布式锁、接口幂等、Token Bucket、滑动窗口限流等协调问题，但恰恰是这些场景最容易写错。原因不复杂：很多人从网上复制一段 SETNX + EXPIRE 就上线，不理解原子性、唯一标识、安全释放、锁续期、主从切换这些关键细节。面试也特别爱问：为什么 DEL lockKey 是错误的解锁方式？Redis 主节点刚写入锁就宕机时会有什么问题？今天我把这些细节点一次性讲透，顺便给出两个 Spring Boot 实战：同一个订单只能支付一次，以及每用户每分钟最多请求 100 次。

## 02、是什么

先厘清 Redis 协调模式的本质。

分布式锁，目标是在多个进程之间维护一个互斥标志。标准获取方式是单条命令：SET key value NX PX 10000。其中 NX 表示 key 不存在才写入，PX 表示毫秒过期时间。value 必须是每次请求唯一的标识，比如 UUID 加上线程 ID，而不是固定的 1 或 locked。原因后面会讲。

接口幂等，主要用来防止重复提交。常见做法是把请求唯一编号或者业务单号作为 key，用 SET NX 抢占，成功才处理业务，失败则返回处理中或重复请求。

Token Bucket，即令牌桶，本质是一个计数器加上生成令牌的节奏。每个请求先取令牌，取不到就限流。Redis 里可以用一个 key 记录令牌数量，配合过期时间和时间戳计算。

滑动窗口限流，记录每个用户的最近请求时间戳，用 ZSET 保存，每次请求先删除窗口外的时间戳，再统计剩余数量，超过阈值就拒绝。这个方式比固定窗口更平滑，精度更高。

这些协调模式的共同点：多个操作必须原子完成。比如分布式锁的 SETNX 和 EXPIRE 如果拆成两条命令，中间进程崩溃就会留下永不过期的死锁。再比如释放锁时，需要先 GET 判断锁是否属于自己，再 DEL，但这个“比较并删除”如果不原子，就会误删别人刚获取的锁。解决办法就是 Lua 脚本，让 Redis 在服务端一次性执行这些步骤。

锁续期是指如果业务执行时间可能超过锁的 TTL，就需要一个后台线程周期性地延长过期时间，确保业务没有执行完之前锁不会过期。否则锁提前释放，两个请求同时进入临界区。

Fence Token 是一种更上层的保护：给每一次成功获取锁的请求分配一个单调递增的 token，业务在写入共享存储时带上这个 token，存储层只接受比当前更大的 token。即使锁因为 GC 停顿、网络问题或主从切换提前失效，旧的请求恢复后也无法覆盖新请求写入的数据。

最后，必须明确一个边界：Redis 锁不是数据库事务。它只能提供互斥，不提供原子性、隔离性、持久性这些数据库事务保证。业务数据的最终一致性，还需要数据库唯一约束、状态机、乐观锁等兜底。

## 03、为什么

为什么必须用单条 SET NX PX？因为 SETNX 和 EXPIRE 分开写成两条命令，存在窗口期。假设客户端执行完 SETNX 后进程崩溃，EXPIRE 永远没有机会执行，这个锁就成了永不过期的孤儿锁，所有后续请求都会被阻塞，直到人工删除。

为什么 value 要唯一标识？因为释放锁时需要知道锁是不是自己持有的。如果所有请求都写入同一个固定 value，释放时根本无法判断归属，只能盲目 DEL，就回到了误删别人的锁的问题。唯一标识相当于一把钥匙，只有拿着自己的钥匙才能开门。

为什么要用 Lua 安全释放？直接 DEL 不对，但 GET + DEL 两步也不安全。因为 GET 之后、DEL 之前，锁可能刚好过期，另一个请求获取了同一把 key 的锁。此时前一个请求再 DEL，就会删掉别人的锁。Lua 脚本把 GET、比较、DEL 放在同一个原子操作里，Redis 不会在执行脚本期间插入其他命令，所以能保证只删除自己持有的锁。

为什么要锁续期？业务执行时间往往很难精确预估。如果设置 TTL 太短，业务没跑完锁就过期，其他请求会并发进入；如果设置 TTL 太长，业务崩溃后其他请求需要等很久才能获取锁。续期机制允许设置一个相对短的初始 TTL，然后在后台周期性检查并延长，这样既避免死锁，又能覆盖长任务。

为什么需要 Fence Token？即使有了续期，极端情况依然存在。比如 Java 应用发生长时间的 Full GC，整个进程暂停，锁虽然看门狗在续期，但业务根本没执行；或者 Redis 主从切换，锁数据还没同步到从节点，新主已经上线。这些情况下，锁可能被错误地判为失效，另一个请求进入临界区。Fence Token 从存储层拒绝旧请求写入，弥补 Redis 锁的不足。

为什么 Redis 锁不是数据库事务？因为 Redis 锁只在 Redis 层面保证互斥，业务代码可能在拿到锁后执行数据库写入，但数据库提交与锁释放之间存在时间差。如果先释放锁再提交事务，其他请求可能会读到未提交的数据；如果先提交事务再释放锁，锁持有时间过长影响吞吐。此外，数据库写入可能失败，但锁已经释放，其他请求进入后看到的状态也不一致。所以数据库事务和 Redis 锁是两个维度的工具，不能互相替代。

## 04、架构

从架构视角看，一个完整的 Redis 分布式锁方案至少包含这几层：

第一层是 Redis 服务端，可以是单实例、主从哨兵或集群。单实例简单，但存在单点故障和数据丢失风险；主从哨兵能自动切换，但异步复制可能导致锁丢失；集群模式分片，但锁通常要求单 key 落在同一个分片。

第二层是客户端库，负责生成唯一标识、发送 SET NX PX、执行 Lua 释放、续期等。最小实现可能只有两个方法：tryLock 和 unlock。成熟方案如 Redisson 提供 RLock 接口，底层用 Hash 结构保存锁信息和重入次数，默认开启看门狗，30 秒续期一次，释放时自动取消续期任务。

第三层是锁 key 设计。一般用业务资源 ID 作为前缀，比如 order:pay:123。value 使用 UUID + 线程 ID，保证不同进程、不同线程都不会撞车。TTL 要结合实际业务设定，通常初始值 10 到 30 秒，配合续期。

第四层是监控和告警。需要统计锁等待时长、持有时长、释放失败次数、续期失败次数等指标。发现锁等待时间突然变长，可能意味着大事务或慢查询阻塞。

最小锁和 Redisson 的对比可以这样看：最小锁适合短期任务，代码几十行，便于理解原理；Redisson 适合生产复杂场景，支持可重入、公平锁、联锁、红锁，提供自动续期和线程安全，但依赖更重，需要额外维护。一般来说，刚入门可以先自己写一个最小锁，体会 SET NX PX、Lua 释放、续期这几个核心点，再在生产环境引入 Redisson。

## 05、实战

下面用 Spring Boot 举例。假设已经引入 spring-boot-starter-data-redis，有 StringRedisTemplate。

先实现一个最小锁。获取锁的伪代码：

```
token = UUID.randomUUID().toString()
ok = redis.opsForValue().setIfAbsent(key, token, Duration.ofMillis(ttlMs))
如果 ok 为 true，返回 token，否则返回 null
```

释放锁必须用 Lua 脚本，脚本内容为：

```
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
```

Java 侧可以用 DefaultRedisScript 执行，把 key 和 token 作为参数传入。关键就是比较和删除在服务端一次完成，不会误删别人的锁。

接着实现“同一个订单只能支付一次”。整体思路分三层：

第一层，业务状态机。订单表里要有状态字段，比如 0 待支付、1 支付中、2 已支付、3 已取消。支付前先判断状态，只有待支付才能继续。

第二层，Redis 锁。用订单号作为 key，tryLock 成功后进入支付流程。即使并发请求同时到达，只有一个能抢到锁。抢不到的直接返回支付处理中。

第三层，数据库唯一约束。可以把订单号和支付渠道组成联合唯一键，防止极端情况下写入重复支付记录。

流程伪代码：

```
lockKey = order:pay: + orderId
token = simpleRedisLock.tryLock(lockKey, 30000)
如果 token 为空，返回支付处理中
否则：
  查询订单状态
  如果已经是已支付，返回订单已支付
  否则发起支付、更新状态、写入支付流水
最后在 finally 中调用 unlock(lockKey, token)
```

这里锁的 TTL 要能覆盖支付流程，如果不能，换成 Redisson 看门狗或手动续期。

再实现“每用户每分钟最多请求 100 次”。用 ZSET 做滑动窗口，key 为 rate:user:用户 ID。每次请求执行 Lua 脚本：

```
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, tonumber(ARGV[1]) - 60000)
local count = redis.call('ZCARD', KEYS[1])
if count >= tonumber(ARGV[2]) then return 0 end
redis.call('ZADD', KEYS[1], ARGV[1], ARGV[3])
redis.call('PEXPIRE', KEYS[1], 60000)
return 1
```

参数 ARGV[1] 是当前毫秒时间戳，ARGV[2] 是阈值 100，ARGV[3] 是唯一成员，可以用时间戳加随机数，避免同一毫秒多次请求覆盖。返回 1 表示放行，返回 0 表示限流。

Spring Boot 里可以封装成一个 RateLimiter 组件，用 DefaultRedisScript 执行。注意这里的时间戳要和 Redis 服务器保持一致，或者使用客户端传入的单调时间。

最后比较 Redisson。引入 redisson-spring-boot-starter 后：

```
RLock lock = redissonClient.getLock(lockKey)
boolean locked = lock.tryLock(0, 30, TimeUnit.SECONDS)
如果 locked 为 false，返回支付处理中
否则执行业务，finally 中判断 lock.isHeldByCurrentThread() 后 unlock
```

Redisson 的 tryLock 使用 Hash 结构，key 是锁名，field 是线程标识，value 是重入次数。默认看门狗 30 秒续期，即使业务超过 30 秒也会自动延长，释放时检查当前线程是否持有锁，避免误释放。

## 06、洞见

现在回答开头留下的两个测验问题。

为什么 DEL lockKey 是错误的解锁方式？因为 DEL 不检查锁的归属，会删除任何进程持有的锁。假设 A 获取锁，TTL 10 秒，业务执行了 12 秒，锁在第 10 秒过期；B 在第 11 秒获取锁成功；A 在 12 秒业务结束执行 DEL lockKey，删掉的是 B 的锁。随后 C 可以获取锁，于是 B 和 C 并发进入临界区。正确做法是用 Lua 脚本先 GET 比较 value，再决定是否 DEL。

Redis 主节点刚写入锁就宕机时会有什么问题？Redis 主从复制默认是异步的，主节点写入锁后，可能还没来得及同步给从节点就宕机。哨兵提升从节点为新主，新主上并没有这把锁的数据。此时另一个客户端向新主发起 SET NX，可以成功获取同一把锁，导致两个客户端同时持有同一把锁，互斥被打破。如果业务是扣库存或者支付，就可能出现超卖或重复扣款。缓解手段包括：使用 WAIT 命令强制等待部分从节点同步；使用 RedLock 在多个独立 Redis 实例上过半成功；引入 Fence Token，让存储层拒绝旧请求写入；同时在数据库层加唯一约束和状态机。

Fence Token 尤其值得展开。它的思路是：锁服务在每次成功获取锁时返回一个递增 token，业务写入共享存储时携带这个 token，存储会把当前最大 token 作为门槛，只接受更大的 token。这样即使旧持有者因为 GC 停顿或网络延迟恢复后继续写入，存储也会拒绝，因为新持有者已经拿到了更大的 token。这个机制和 Redis 锁配合，能大幅降低异步复制带来的风险。

还要看清 Redis 锁不是数据库事务。比如支付场景，A 拿到锁，调用第三方支付，数据库更新失败，A 释放锁后 B 进入，B 看到的数据可能还是旧状态。如果不加数据库唯一约束，B 也可能发起重复支付。所以 Redis 锁只是第一道防线，数据库事务和唯一约束才是最后防线。

## 07、行动

如果今天只记几条，我建议记这 10 条：

1. 获取锁永远用单条 SET key token NX PX，不要拆成 SETNX + EXPIRE。
2. token 必须是唯一标识，推荐 UUID + 线程 ID。
3. 释放锁永远用 Lua 比较 token 后删除，禁止直接 DEL。
4. 锁 TTL 要合理，长任务要续期；生产环境优先用 Redisson 看门狗。
5. 锁内尽量只做短操作，避免远程调用、大事务和慢 SQL。
6. 幂等优先靠数据库状态机和唯一约束，Redis 锁只是辅助。
7. 限流优先用 Lua 滑动窗口，注意成员唯一性和窗口边界。
8. 监控锁等待时间、持有时间、误删次数，异常及时告警。
9. 评估 Redis 主从切换风险；金融级场景加 Fence Token 和 WAIT。
10. 上线前用压测模拟并发、超时、主从切换，验证锁和幂等逻辑。

## 08、小结

Redis 分布式锁看着简单，真正写对却需要同时关注原子获取、唯一标识、Lua 释放、续期、Fence Token、主从切换和业务边界。最小实现是理解原理的最好方式，但生产环境不要裸奔，选择 Redisson 这类经过验证的库可以少踩很多坑。下次再遇到同一个订单支付两次或者每用户每分钟限流时，先问自己：失败会误删别人的锁吗？主节点宕机会重复执行吗？把这两个问题回答清楚，Redis 协调代码才真正算过关。

## 09、链接与概念说明

概念说明：

- SET NX PX：Redis 单条命令，key 不存在才写入，并设置毫秒过期时间，保证获取锁的原子性。
- Lua 脚本：在 Redis 服务端原子执行，常用于安全释放锁和滑动窗口限流。
- Fence Token：获取锁时返回单调递增 token，存储层只接受更大的 token，防止旧进程覆盖新数据。
- Redisson：Java Redis 客户端，提供分布式锁、限流器等高级对象，默认看门狗 30 秒续期。
- Token Bucket：令牌桶算法，固定速率生成令牌，请求消耗令牌，允许一定突发流量。
- 滑动窗口：记录每个请求时间戳，统计最近窗口内请求数，比固定窗口更平滑。
- Redis 主从复制：异步复制，主节点故障可能丢失最近写入。
- RedLock：多个独立 Redis 实例过半成功获取锁，降低单点故障风险，但存在争议。

推荐阅读：

- Redis 官方文档：SET 命令与 Lua 脚本部分
- Redisson 官方文档：分布式锁与 RLock
- Martin Kleppmann《How to do distributed locking》

某天凌晨两点，我们的支付服务告警响了：同一个订单居然被扣了两笔钱。查日志发现，支付回调被上游重试了三次，而我们用 Redis 加锁，在 finally 里直接执行了 DEL lockKey。更巧的是，第一次请求处理得太慢，锁超时自动释放，第二个请求拿到了锁，等第一个请求慢悠悠醒过来，反手一个 DEL，把第二个请求的锁删掉了。第三个请求趁虚而入，重复支付。我是老李，那一刻我意识到，Redis 协调代码看似简单，实际上遍地是坑。

《Redis 8.10 + Spring Boot 实战》第9招 分布式协调——锁、幂等、限流到底应该怎么做

一篇文章讲透 Redis 分布式锁、幂等和限流的正确实现：SET NX PX 原子性、Lua 安全释放、锁续期、Fence Token、Redisson 对比，

架构师

数据库

后端

架构设计

分布式协调是Redis最容易被误用的场景，原子获取、唯一标识、Lua安全释放、锁续期和FenceToken五要素缺一不可。本文用支付重复扣款和限流实战，剖析SETNX+EXPIRE拆分的死锁隐患、主从切换的锁丢失风险，给出Redisson与最小锁的对比方案，并提炼10条避坑指南，助你写出生产级Redis协调代码。

网络延迟

数据丢失

代码解释

服务器

Redis

Java

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Redis 8.10 + Spring Boot 实战》第9招 分布式协调——锁、幂等、限流到底应该怎么做-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第9招分布式协调——锁、幂等、限流到底应该怎么做

《Redis 8.10 + Spring Boot 实战》第9招分布式协调——锁、幂等、限流到底应该怎么做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第9招 分布式协调——锁、幂等、限流到底应该怎么做

《Redis 8.10 + Spring Boot 实战》第9招 分布式协调——锁、幂等、限流到底应该怎么做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第9招分布式协调——锁、幂等、限流到底应该怎么做

《Redis 8.10 + Spring Boot 实战》第9招分布式协调——锁、幂等、限流到底应该怎么做