Redisson的lock()默认30秒超时在高并发下易出问题：WatchDog每10秒续期，但业务线程若卡在慢查询或远程调用中，续期可能延迟或失败，导致锁提前释放；且30秒为全局默认值，无法适配不同业务耗时。
Redisson 分布式锁的性能瓶颈往往不在 Redis 本身，而在于客户端配置不合理、锁粒度失控或续期策略失当。直接调大超时时间或盲目加锁，反而会放大阻塞风险。
RLock.lock() 默认 30 秒超时为什么在高并发下容易出问题
Redisson 的 lock() 方法默认使用 30 秒锁过期时间，并启动 WatchDog 每 10 秒续期一次。这个设计在多数场景下安全，但在秒杀、订单创建等短时高频操作中会暴露两个隐患：
- WatchDog 续期依赖心跳线程，若业务线程卡在数据库慢查询或远程调用上，续期可能延迟甚至失败，导致锁提前释放
- 30 秒是全局默认值，对耗时
- WatchDog 启动条件是“未显式指定 leaseTime”，一旦你传入
lock(10, TimeUnit.SECONDS)，WatchDog 就被禁用 —— 这个行为极易被忽略
实操建议：对确定耗时的短任务（如缓存预热、幂等校验），显式指定 leaseTime 并关闭 WatchDog；对不确定耗时的长任务（如文件上传后处理），保留默认行为但需监控续期成功率。
redisson.yaml 中 connectionTimeout 和 retryInterval 怎么配才不拖慢锁获取
这两个参数直接影响锁请求失败前的等待成本，尤其在网络抖动或 Redis 负载高时：
-
connectionTimeout（默认 10000ms）：建立 TCP 连接的上限时间。秒杀流量突增时，若连接池已满，新连接会在此阶段卡住 —— 建议压测后下调至3000，配合连接池扩容 -
retryInterval（默认 1500ms）：重试间隔。锁竞争激烈时，大量线程在tryLock(waitTime, leaseTime, unit)的等待队列中，每轮重试都触发一次 Redis 请求 —— 把它设成500会显著增加 Redis QPS，应保持默认或略上调至2000 -
retryAttempts（默认 3）：不是“最多重试 3 次”，而是“最多尝试获取锁 3 次”，每次失败后等retryInterval再来 —— 若你设了waitTime=5000，实际等待可能远超预期
关键点：这些参数作用于底层 Netty 连接，和锁逻辑无关。它们调得越激进，单次锁操作越快，但整体系统抖动容忍度越低。生产环境建议先用默认值，再根据 redisson_netty_client_connection_pool_size 指标调整。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么 setMaxIdleConnection 和 setMinIdleConnection 配得太大会吃光 Redis 连接
Redisson 默认使用 Netty 连接池管理 Redis 连接，setMaxIdleConnection 和 setMinIdleConnection 控制空闲连接数。问题在于：
- 每个 RLock 实例在加锁/解锁时，都会从连接池取一个连接执行 Lua 脚本 —— 不是复用同一个连接
- 若你为每个业务方法都 new 一个
RLock（比如redisson.getLock("order:" + id)），锁对象虽轻量，但连接池压力会随锁 key 数量线性增长 - Redis 默认
maxclients=10000，若单机部署 Redisson 客户端且setMaxIdleConnection=100，100 个微服务实例就能占满连接
实操建议：统一用 Spring Bean 管理 RedissonClient，避免重复初始化；将 setMaxIdleConnection 设为 64（Netty 默认），并通过 setConnectTimeout 缩短异常连接的释放周期；必要时开启连接泄漏检测：setReferenceEnabled(true)。
watchdogTimeout 参数不存在？别被旧文档误导
很多博客提到通过 watchdogTimeout 控制看门狗行为，但 Redisson 3.16+ 版本已移除此配置项。WatchDog 的续期周期固定为 internalLockLeaseTime / 3（即默认 30s 锁 → 每 10s 续一次）。真正可调的是：
-
setLockWatchdogTimeout：设置锁的初始 leaseTime（单位 ms），影响 WatchDog 首次续期时机 -
setRetryInterval：仅影响tryLock失败后的重试节奏，不影响 WatchDog - WatchDog 是否启用，只由是否传入
leaseTime决定 —— 传了就是关，不传就是开
最容易被忽略的一点：WatchDog 续期失败时不会抛异常，只会打 warn 日志 "Can't update lock xxx lease time due to interruption。必须在日志系统中对这条 warn 做告警，否则锁提前释放的问题会静默发生。
