做后端开发时分布式锁是一个绕不开的话题。比如秒杀时同一个商品库存不能被多个请求同时扣成负数定时任务部署了多台机器但同一时刻只能有一台执行用户重复点击支付按钮不能生成多笔订单多个服务同时更新同一份缓存不能互相覆盖这些场景里我们都希望有一把“锁”。在单机程序里可以用synchronized、ReentrantLock。但服务一旦部署到多台机器上本地锁就不够用了。因为 A 机器加的锁B 机器根本不知道。这时候Redis 分布式锁就很常见了。不过Redis 分布式锁不是简单写个setnx就完事了。真正上线时我们还要考虑两个问题怎么保证高可用怎么保证高性能这篇文章就用比较直白的方式聊一聊。一、Redis 分布式锁的基本写法最常见的加锁方式是SET lock_key unique_value NX EX 30这条命令里有几个关键点lock_key锁的名字unique_value锁的唯一标识通常用 UUIDNX只有 key 不存在时才设置成功EX 30锁 30 秒后自动过期为什么不用普通的setnx再单独设置过期时间因为这两步不是原子操作。如果代码刚执行完setnx服务突然宕机还没来得及设置过期时间这把锁就可能永远不释放。所以加锁一定要用 Redis 的原子命令SET key value NX EX seconds二、释放锁不能直接 delete很多新手会这样释放锁DEL lock_key看起来没问题但这里有个坑。假设线程 A 拿到了锁锁过期时间是 10 秒。结果 A 执行业务执行了 15 秒锁已经自动过期了。这时线程 B 又拿到了同一把锁。然后 A 执行完了直接DEL lock_key。问题来了A 删除的是谁的锁其实删掉的是 B 的锁。所以释放锁时必须先判断这把锁是不是自己的。一般用 Lua 脚本保证“判断 删除”是原子操作if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end也就是说谁加的锁谁才能释放。这里的unique_value就派上用场了。三、锁过期时间怎么设置这是分布式锁里很容易被忽略的问题。锁时间太短业务还没执行完锁就过期了可能导致多个线程同时处理。锁时间太长服务宕机后其他请求要等很久才能重新拿到锁。所以一般建议先估算业务正常执行时间过期时间设置为正常耗时的 2 到 3 倍对耗时不稳定的业务考虑自动续期比如一个扣库存接口正常 200ms 完成那锁设置 3 到 5 秒就够了。但如果是导入 Excel、生成报表、批量处理数据这种任务耗时可能波动很大就不能简单写死 30 秒。四、自动续期别让锁半路过期如果业务执行时间不确定可以用“看门狗”机制。简单理解就是线程拿到锁之后后台开一个续期任务。只要业务还没执行完就定期延长锁的过期时间。Redisson 就内置了这个机制。比如RLock lock redissonClient.getLock(order:lock: orderId); try { lock.lock(); // 业务逻辑 } finally { lock.unlock(); }默认情况下Redisson 会帮你自动续期避免业务还没执行完锁就过期。当然这不是说用了 Redisson 就万事大吉。我们还是要控制业务耗时不要把锁持有得太久。分布式锁的原则是锁的范围越小越好持有时间越短越好。五、如何保证高性能Redis 本身性能很高但分布式锁用不好也会拖慢系统。1. 锁粒度要小不要动不动就锁一个大 key。比如扣库存时不要写成product_lock这样所有商品都会抢同一把锁。更好的方式是product_lock:1001 product_lock:1002 product_lock:1003不同商品用不同的锁互不影响。锁粒度越细并发能力越好。2. 加锁失败不要疯狂重试有些代码加锁失败后会立刻 while 循环重试。这很危险。如果并发量很大大量请求一直打 Redis会让 Redis 压力变大。更好的方式是加锁失败后短暂休眠设置最大重试次数使用随机退避时间避免请求同时再次冲上来比如for (int i 0; i 3; i) { boolean locked tryLock(); if (locked) { break; } Thread.sleep(50 new Random().nextInt(50)); }别小看这几十毫秒它能明显降低 Redis 的瞬时压力。3. 锁内代码越少越好不要把无关逻辑都塞进锁里。比如下面这种就不太好如果真正需要保护的只是“扣库存”那就只锁扣库存那一小段。锁内代码越多其他线程等待越久系统吞吐量越差。4. 能不用锁就不用锁分布式锁不是银弹。有些场景可以用数据库唯一索引、乐观锁、消息队列来解决。比如防止重复下单可以用订单表唯一索引UNIQUE(user_id, product_id)这样即使并发请求进来数据库也能拦住重复数据。能用业务模型解决的问题不一定非要上分布式锁。六、如何保证高可用Redis 分布式锁依赖 Redis。如果 Redis 挂了锁自然也会受影响。常见方案有几种。1. Redis 主从 哨兵这是比较常见的部署方式。Redis 主节点挂了以后哨兵会自动选举新的主节点。优点是简单、成熟很多公司都在用。但它也有一个问题Redis 主从复制是异步的。假设客户端在主节点加锁成功但这条数据还没同步到从节点主节点突然挂了。哨兵把从节点提升为主节点后新主节点上可能没有这把锁。这时其他客户端可能再次加锁成功。所以主从哨兵能提高 Redis 可用性但不能完全保证锁在极端故障下绝对安全。2. Redis ClusterRedis Cluster 可以把数据分片到多个节点提高整体容量和可用性。但对分布式锁来说通常一把锁只会落到某一个 Redis 节点上。所以它更多解决的是 Redis 集群扩展问题不是锁语义的绝对可靠问题。3. RedLockRedLock 是 Redis 官方提出的一种分布式锁算法。它的思路是客户端向多个独立 Redis 节点尝试加锁只有超过半数节点加锁成功才认为锁获取成功。比如有 5 个 Redis 节点至少 3 个加锁成功才算成功。这样单个 Redis 节点挂掉时不会直接影响锁的判断。不过 RedLock 在业界也有一些争议主要是实现复杂度、时钟漂移、网络延迟等问题。我的建议是普通业务Redisson Redis 主从/哨兵基本够用金融、支付、强一致场景不要只依赖 Redis 锁要结合数据库事务、唯一索引、状态机等机制兜底一句话Redis 分布式锁可以提高并发控制能力但不要把系统正确性全部压在它一个人身上。七、实际开发中的推荐写法如果是 Java 项目比较推荐直接使用 Redisson。它帮我们处理了很多细节原子加锁自动续期可重入锁释放锁校验等待时间控制示例代码RLock lock redissonClient.getLock(stock:lock: productId); boolean locked false; try { locked lock.tryLock(3, 10, TimeUnit.SECONDS); if (!locked) { throw new RuntimeException(系统繁忙请稍后再试); } // 执行业务逻辑 deductStock(productId); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(获取锁失败, e); } finally { if (locked lock.isHeldByCurrentThread()) { lock.unlock(); } }这里有几个细节tryLock(3, 10, TimeUnit.SECONDS)表示最多等待 3 秒锁 10 秒后过期finally里释放锁避免异常导致锁不释放isHeldByCurrentThread()防止误删其他线程的锁总结Redis 分布式锁看起来简单真正用好却需要注意很多细节。高性能主要靠小粒度锁短时间持有合理重试减少锁内逻辑高可用主要靠Redis 主从、哨兵或集群部署Redisson 这类成熟客户端必要时考虑 RedLock核心业务用数据库事务、唯一索引、状态机兜底最后记住一句话分布式锁解决的是“谁先执行”的问题业务兜底解决的是“数据最终不能错”的问题。
