一：Redisson 分布式锁

. 为什么需要分布式锁？

单体应用用 synchronized 或 ReentrantLock 已经足够，但跨进程、跨节点的互斥访问成为痛点。没有可靠的分布式锁，常见问题包括：

• 同一业务在不同机器上并发执行导致库存超卖、订单重复。
• 业务代码依赖本地锁，迁移到云环境后失效。
• 手动实现锁时容易出现死锁或误删他人锁。

. 三种实现方式对比

维度	Redis	ZooKeeper	MySQL
实现原理	SET NX EX + Lua 脚本释放	临时顺序节点 + Watcher 唯一索引 / 乐观锁	唯一索引+ 乐观/悲观锁
性能	极高	中等	低
一致性	最终一致	强一致	强一致
可靠性	需 Redisson 看门狗续期，防止因网络抖动导致会话过期自动释放。	依赖会话失效自动删除临时节点。	需定时清理过期记录防止死锁。

选型建议：

• 绝大多数高并发、性能敏感场景：使用Redis + Redisson；话说回来，环境成熟、社区支持好。
• 金融级别或强一致需求：Kafka 等程序更倾向于使用Zookeeper 锁或 Paxos/Raft 实现的分布式协调服务。
• Mysql 已经是项目唯一数据源且不想引入新组件：# 使用唯一索引实现的轻量级锁。
• 无论选哪种方案，都要关注「锁过期」和「误删」这两个最常见痛点。

. 手写 Redis 分布式锁

@Component
public class SimpleRedisLock {
@Autowired
private StringRedisTemplate redisTemplate;private static final String LOCK_PREFIX = "lock:";private static final long EXPIRE_SECONDS = 30L;// 根据业务自行调节
/** 加锁 */
public boolean tryLock {
Boolean success = redisTemplate.opsForValue
.setIfAbsent(LOCK_PREFIX + lockName。requestId,EXPIRE_SECONDS,TimeUnit.SECONDS);return Boolean.TRUE.equals;}
/** 解锁 */
public void unlock {
String script =
"if redis.call == ARGV n " +
" return redis.call " +
"else " +
" return 0 " +
"end";redisTemplate.execute。Collections.singletonList,requestId);话说回来，}
}

为什么释放锁要用 Lua？

LUA 脚本在 Redis 中一次性执行，避免了下面两步之间被其他线程抢占导致的误删问题——这正是“释放错误导致资源泄漏/业务异常回滚失败`”这一痛点的根源。

. 手写实现遇到的问题

• 业务执行时间> 锁过期时间：其他实例可能提前获得同一资源，引发并发冲突。

续期逻辑全靠自己写：If forget to renew → “死锁” or “业务被中断”。Redisson 的看门狗正是为了解决这个痛点而设计的。

LUA 脚本写错或未加载成功：LUA 执行错误会导致加解锁失败，线上调试成本极高。

No visibility / monitoring:If you cannot see which keys are locked,troubleshooting becomes a nightmare.

二：Redisson 分布式锁与看门狗机制

. 快速上手依赖 & 配置示例

org.redisson
redisson-spring-boot-starter
3.23.0

从spring来看。redis:
redisson:
config的观点是，|
singleServerConfig:
address: "redis://127.0.0.1:6379"
password: null
database: 0
# 看门狗超时时间，默认30000ms，可根据业务调大/调小
lockWatchdogTimeout: 60000
# 可选：如果是集群模式，用 clusterServersConfig ...

. 基础使用示例

@Service
public class OrderService {
@Autowired
private RedissonClient redissonClient;public void deductStock {
RLock lock = redissonClient.getLock;try {
// 无参 lock 开启看门狗自动续期，省掉手动续期代码。lock.lock，// 默认 leaseTime = 看门狗 timeout
// ======== 主要业务 ========
int stock = getStock;
老实说，if {
updateStock;} else {
throw new IllegalStateException;}
} finally {
// 防止误删：只有当前线程持有才会真正 unlock。if ) {
lock.unlock;}
}
}
}

. 看门狗机制细节​​​​​​​​​​​​​​​​​​​​‍‍‍‍‍‍‍​‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‏‏‏‏‎‎‎‎‎‏‏‏‏‏)

主要参数表：

参数名	默认值	说明

lockWatchdogTimeout 

30 000 ms 

当调用无参lock时看门狗为该线程维护的租约时长。按理说，若线程在此期间仍持有锁，看门狗每10 s 自动将 TTL 延长至该值。以防止因网络抖动或 GC 暂停导致提前失效。

watchdogCheckInterval 

10 s 

内部 Netty HashedWheelTimer 的检查频率。频率越高响应越快，但 CPU 开销略增。

leaseTime  

N/A 

若调用lock则禁用看门狗，TTL 固定为 leaseTime；适用于明确知道最长执行时间且不想额外心跳的场景。

/watchdogEnabled    >

为何采用 Netty HashedWheelTimer 而不是 JDK Timer？< / strong>& lt ul>& lt li>& nbsp;异步非阻塞，复用 EventLoop。可与 Redis 客户端共用线程池；& lt / li>& lt li>& nbsp;单个任务异常不会影响其它任务；& lt / li>& lt li>& nbsp;哈希轮算法 O，即使成千上万并发续期也能保持低 GC 压力。说起来，& lt / li>& lt / ul>

. 工作流程图示意。帮助定位“看门狗未启动”“续期失效”等故障根源：

1. A 调用lock成功后Redisson 在内部创建一个租约键并设置 TTL 为30 s；随后启动后台看门狗任务，话说回来，

unlock或者进程宕机。看门 狗将停止运行，此键将在剩余 TTL 后自动失效，从而防止死锁。

A 正常结束后调用unlock/r ediss onClient .unlock 会删除租约键，并立即终止对应的看 门 狗任务。

. 可重入特性  

Redission 的 RLock 默认可重入：内部通过 Redis 哈希结构记录 ThreadID 与重入计数。当同一线程 调用lock 时只会把计数 +1，而不是重新竞争全局资源。这让开发者可以像使用 ReentrantLock 那样安全地编写业务代码，而无需担心意外死等问题。

public void methodA {
RLock lk = redi sonClient.getLock;lk.lock，// 第一次获取
try { methodB;} finally { lk.unlock;按理说，} // 解开一次计数
}
public void methodB {
RLock lk = redi sonClient.getL ock;lk.lock，// 重入计数 +1，不会阻塞自身
try { /* …*/ } finally { lk.unlock;} // 重入计数 –1
}
<\/c ode><\/pr e>

---