1. 分布式锁的本质与核心诉求分布式锁是分布式系统中协调多节点访问共享资源的机制其核心要解决三个问题互斥性同一时刻只有一个客户端能持有锁避免死锁持有锁的客户端崩溃后锁能自动释放容错性部分节点宕机不影响整体可用性以电商库存扣减场景为例当多个订单系统实例同时修改同一商品库存时没有分布式锁会导致超卖问题。传统单机锁如synchronized在分布式环境下失效因为不同JVM的锁对象不共享网络延迟可能导致锁状态不一致关键认知误区很多人以为分布式锁就是跨机器的互斥锁实际上它更接近分布式环境下的状态协调器2. Redis分布式锁的演进之路2.1 第一代SETNXDEL手动实现最基础的Redis锁实现方案// 加锁 Boolean locked redis.setnx(lock_key, 1); if(locked) { redis.expire(lock_key, 30); // 设置过期时间 } // 解锁 redis.del(lock_key);致命缺陷加锁和设置过期时间不是原子操作可能死锁可能误删其他客户端的锁无锁持有者标识锁续期问题未解决2.2 第二代SET命令优化Redis 2.6.12后支持SET扩展参数String result redis.set(lock_key, requestId, NX, PX, 30000);NX仅当key不存在时设置PX设置毫秒级过期时间requestId唯一标识锁持有者改进点原子性操作解决死锁风险通过requestId实现锁持有者验证2.3 第三代Redlock算法Redis作者提出的分布式锁算法核心流程获取当前毫秒级时间戳T1依次向N个独立Redis实例申请锁计算获取锁耗时T2-T1当且仅当大多数节点N/21获取成功且总耗时小于锁有效期锁实际有效期 初始有效期 - 获取耗时争议点需要部署多套独立Redis实例时钟漂移问题可能导致锁失效性能开销较大3. Redisson分布式锁源码精析3.1 可重入锁实现Redisson的RLock核心逻辑// 加锁入口 T RFutureT tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommandT command) { internalLockLeaseTime unit.toMillis(leaseTime); return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command, if (redis.call(exists, KEYS[1]) 0) then redis.call(hincrby, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end; if (redis.call(hexists, KEYS[1], ARGV[2]) 1) then redis.call(hincrby, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end; return redis.call(pttl, KEYS[1]);, Collections.ObjectsingletonList(getName()), internalLockLeaseTime, getLockName(threadId)); }设计亮点使用Hash结构存储锁信息支持可重入Lua脚本保证原子性内置看门狗自动续期机制3.2 锁续期机制看门狗Watchdog工作原理加锁时不指定leaseTime则启动看门狗默认每10秒检查一次internalLockLeaseTime/3如果业务线程仍活跃延长锁有效期private void scheduleExpirationRenewal(final long threadId) { if (expirationRenewalMap.containsKey(getEntryName())) { return; } Timeout task commandExecutor.getConnectionManager() .newTimeout(new TimerTask() { Override public void run(Timeout timeout) throws Exception { // 续期Lua脚本 RFutureBoolean future commandExecutor.evalWriteAsync(...); future.addListener(new FutureListenerBoolean() { Override public void operationComplete(FutureBoolean future) throws Exception { if (!future.isSuccess()) { return; } if (future.getNow()) { // 递归调用实现周期性续期 scheduleExpirationRenewal(threadId); } } }); } }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS); }4. Zookeeper分布式锁实战4.1 实现原理ZK通过临时顺序节点实现分布式锁所有客户端在指定目录下创建临时顺序节点判断自己是否是最小编号节点是则获得锁否则监听前一个节点的删除事件释放锁时删除自身节点public void lock() throws Exception { // 创建临时顺序节点 currentPath zk.create(basePath /lock-, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // 尝试获取锁 tryAcquire(); } private void tryAcquire() throws Exception { ListString children zk.getChildren(basePath, false); Collections.sort(children); if (currentPath.endsWith(children.get(0))) { // 获得锁 } else { // 监听前一个节点 String prevNode basePath / children.get( Collections.binarySearch(children, currentPath.substring(currentPath.lastIndexOf(/) 1)) - 1); zk.exists(prevNode, watcher); } }4.2 对比Redis方案特性RedisZookeeper性能高内存操作中需要创建节点可靠性依赖持久化策略高ZAB协议保证锁释放机制超时自动释放会话结束自动释放实现复杂度简单较复杂惊群效应存在避免顺序监听适用场景高频短时锁低频长时锁5. 生产环境避坑指南5.1 Redis锁常见问题锁提前过期现象业务未执行完锁已释放解决方案合理评估锁超时时间使用Redisson看门狗机制集群脑裂问题场景主从切换期间锁状态不一致解决方案使用RedLock性能折损业务层增加补偿机制5.2 ZK锁注意事项避免大量客户端同时抢锁导致羊群效应解决方案使用Curator的InterProcessSemaphoreMutex会话超时设置要合理// 建议配置 CuratorFrameworkFactory.builder() .connectString(127.0.0.1:2181) .sessionTimeoutMs(60000) // 60秒 .connectionTimeoutMs(15000) .retryPolicy(new ExponentialBackoffRetry(1000, 3)) .build();节点数据不要过大ZK对节点数据大小有限制6. 面试深度问题解析6.1 如何实现锁的公平性Redis方案使用ZSet维护等待队列通过发布订阅通知锁释放// 伪代码示例 String queueKey fair_lock_queue; redis.zadd(queueKey, System.currentTimeMillis(), threadId); while(true) { SetString members redis.zrange(queueKey, 0, 0); if(members.contains(threadId)) { // 尝试获取锁 break; } else { // 订阅锁释放消息 redis.subscribe(lock_release_channel); } }ZK方案天然公平顺序节点FIFO监听6.2 分布式锁的性能优化锁分段将大锁拆分为多个小锁// 商品库存锁示例 public void deductStock(Long itemId, int num) { int segment itemId % 16; // 分为16段 RLock lock redisson.getLock(stock_lock_ segment); lock.lock(); try { // 业务逻辑 } finally { lock.unlock(); } }乐观锁配合UPDATE inventory SET stock stock - 1 WHERE item_id 1001 AND stock 1本地缓存定期同步本地缓存持有锁状态定时与中心节点同步7. 技术选型建议根据CAP理论选择CP型场景强一致性优先金融交易系统使用Zookeeper或RedisRedlock需5个以上实例AP型场景高可用优先电商库存系统使用Redis单节点/哨兵模式配合本地标记降级性能基准测试数据仅供参考Redis单节点约50,000 TPSZookeeper约10,000 TPSRedlock约5,000 TPS在实际项目中我们最终选择了RedissonZK双方案高频操作使用Redisson如秒杀低频关键操作使用ZK如资金结算