1. Redis分布式锁的核心原理与必要性在分布式系统中多个服务实例需要协调对共享资源的访问时传统的单机锁机制就失效了。想象一下当多个订单服务同时尝试扣减同一件商品的库存时如果没有跨进程的锁机制就会导致超卖问题。这就是Redis分布式锁最典型的应用场景。Redis之所以能实现分布式锁主要依靠其单线程特性和原子操作。当我们在Redis中执行SET key value NX PX 30000这样的命令时NX表示只有当key不存在时才设置成功PX 30000表示这个key会在30秒后自动过期整个操作是原子的不会被其他命令打断这种特性完美符合了分布式锁的三个基本要求互斥性同一时刻只有一个客户端能持有锁避免死锁自动过期机制容错性Redis节点宕机时锁会自动释放2. 基础实现方案与常见陷阱2.1 正确的加锁方式最基础的加锁命令如下SET lock:order:1234 uuid1234 NX PX 30000这个命令中lock:order:1234是锁的名称建议按业务场景命名uuid1234是全局唯一标识通常用UUID生成30000是锁的自动释放时间(毫秒)在Java中使用Jedis客户端的实现如下public boolean tryLock(Jedis jedis, String lockKey, String requestId, int expireTime) { String result jedis.set(lockKey, requestId, NX, PX, expireTime); return OK.equals(result); }2.2 常见错误实现很多初学者会犯的一个典型错误是将加锁和设置过期时间分成两步// 错误示范 Long result jedis.setnx(lockKey, requestId); if (result 1) { // 如果在这步之前程序崩溃就会导致死锁 jedis.expire(lockKey, expireTime); }这种非原子操作在高并发场景下会导致严重问题。3. 安全释放锁的正确姿势3.1 为什么释放锁需要特殊处理直接使用DEL命令删除锁是危险的考虑以下时序客户端A获取锁设置30秒过期客户端A执行耗时操作如数据库事务耗时超过30秒锁自动过期释放客户端B获取到同一个资源的锁客户端A完成操作执行DEL命令结果客户端B的锁被意外释放3.2 Lua脚本实现原子解锁Redis的eval命令可以原子化执行Lua脚本这是最可靠的解锁方式if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1]) else return 0 endJava中的调用示例String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Object result jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));4. 生产环境中的进阶考量4.1 锁续期机制对于可能长时间执行的任务需要实现锁续期也称为看门狗机制。基本思路是获取锁成功后启动一个后台线程每隔一段时间如过期时间的1/3检查锁是否仍由当前客户端持有如果是则延长锁的过期时间Redisson客户端库已经内置了这个功能。4.2 集群环境下的特殊问题在Redis主从架构中当主节点崩溃时客户端A在主节点获取锁主节点还未同步到从节点就崩溃从节点升级为新主节点客户端B也能获取同一个资源的锁针对这种情况Redis作者提出了RedLock算法需要至少5个独立的Redis主节点客户端需要在多数节点上成功获取锁才算真正获取成功。5. 性能优化与最佳实践5.1 锁粒度控制锁的粒度应该尽可能小好的做法lock:order:1234锁定特定订单不好的做法lock:orders锁定所有订单5.2 超时时间设置过期时间需要仔细权衡太短业务未完成锁就自动释放太长系统故障时恢复时间延长建议根据业务操作的最长时间设置基础值增加20-30%的缓冲时间实现锁续期机制5.3 客户端选型建议对于Java项目简单场景Jedis 自研锁逻辑复杂场景Redisson内置分布式锁、锁续期等功能6. 真实案例库存扣减系统我们曾实现一个电商库存系统核心逻辑如下public boolean deductStock(String itemId, int num) { String lockKey lock:stock: itemId; String requestId UUID.randomUUID().toString(); try { // 尝试获取锁 boolean locked tryLock(lockKey, requestId, 5000); if (!locked) { return false; } // 查询库存 int stock getStockFromDB(itemId); if (stock num) { return false; } // 扣减库存 updateStockInDB(itemId, stock - num); return true; } finally { // 释放锁 unlock(lockKey, requestId); } }遇到的坑与解决方案问题高峰期锁竞争导致性能下降 解决引入分段锁将商品库存拆分为多个子库存问题锁自动释放后业务仍在执行 解决实现锁续期机制每2秒检查一次问题Redis节点故障导致锁服务不可用 解决部署Redis哨兵集群并设置合理的故障转移策略7. 监控与问题排查完善的监控应包括锁等待时间锁持有时间锁获取失败率Redis节点健康状态当出现问题时可以检查Redis慢查询日志客户端连接池状态网络延迟情况GC日志如果是Java应用8. 替代方案对比除了Redis常见的分布式锁实现还有方案优点缺点ZooKeeper强一致性可靠性高性能较低部署复杂etcd支持租约API友好社区资源相对较少数据库无需额外组件性能差有死锁风险选择建议强一致性要求高ZooKeeper高性能要求Redis已有etcd集群etcd在实际项目中我们通常会根据具体场景选择合适的方案有时甚至会组合使用多种实现。