Redisson分布式锁异常问题分析与解决方案

2025-05-09 05:43:21作者：齐添朝

Redisson是一款高性能、基于Java的Redis客户端，专为现代应用程序设计。它充分利用Netty框架和异步编程模型，支持广泛的Redis版本及多种部署模式，从单机到云服务如AWS、Azure和GCP，乃至企业级解决方案，全面覆盖。Redisson不仅提供基本的键值存储功能，还扩展至高级特性和分布式Java对象，包括反应式编程支持、lua脚本、事务、多种数据结构与锁机制，以及丰富的集成选项如Spring、Quarkus和Hibernate。通过简洁的API，Redisson让开发人员能够轻松构建可伸缩、低延迟的应用，无论是在微服务架构中还是传统环境，都是提升效率和可靠性的得力工具。开始探索Redisson，解锁数据管理的新高度。

项目地址：https://gitcode.com/gh_mirrors/red/redisson

问题背景

在使用Redisson分布式锁时，开发人员遇到了一个严重的问题：当网络出现异常时，锁机制会进入一个异常状态，导致应用程序陷入无限循环的获取/释放锁操作中。这种情况特别发生在从RedissonBlockingQueue迁移到RedissonPriorityBlockingQueue后，系统运行2-3天后突然停止工作。

问题现象

核心异常表现

锁计数器异常增长：正常情况下，分布式锁的计数器应该保持在0或1之间，但实际运行中计数器值增长到了2甚至更高。
无限循环：发布者线程陷入不断尝试获取和释放锁的循环中，无法正常执行任务发布。
锁无法释放：由于计数器始终大于1，锁永远不会被完全释放。

技术分析

锁机制工作原理

Redisson的分布式锁实现基于Redis的哈希结构，主要逻辑包括：

获取锁：通过执行Lua脚本检查锁状态，如果锁不存在或当前线程已持有锁，则增加计数器并设置过期时间
释放锁：减少计数器，当计数器归零时删除锁并发布解锁消息

问题根源

当网络出现异常时（如使用CLIENT PAUSE模拟的情况），锁机制可能出现以下异常：

计数器不一致：网络问题导致锁释放操作未能正确执行，但客户端认为已释放
重入锁问题：同一线程多次获取锁导致计数器异常增长
锁状态不一致：由于网络分区，客户端和Redis服务器对锁状态的认知出现分歧

关键Lua脚本分析

获取锁的脚本逻辑：

if ((redis.call('exists', KEYS[1]) == 0) or (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]);

释放锁的脚本逻辑：

local val = redis.call('get', KEYS[3]); 
if val ~= false then 
    return tonumber(val);
end; 
if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then 
    return nil;
end; 
local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); 
if (counter > 0) then 
    redis.call('pexpire', KEYS[1], ARGV[2]); 
    redis.call('set', KEYS[3], 0, 'px', ARGV[5]); 
    return 0; 
else 
    redis.call('del', KEYS[1]); 
    redis.call(ARGV[4], KEYS[2], ARGV[1]); 
    redis.call('set', KEYS[3], 1, 'px', ARGV[5]); 
    return 1; 
end;