求助最近使用 Redission 分布式锁遇到的坑

[alexfarm]

现象描述

最近一次上线使用了 Reentrant Lock ，上限次日早上 9 点迎来流量高峰，出现较多 RedisTimeoutExcpetion:Command execution timeout for command(EVAL)...(省略的部分是 lua 的加锁和解锁逻辑部分)，几天观察下来，一般会在 9:00-9:15 期间自动恢复，后面再也没有任何该搞错出现，待凌晨迎来流量低谷，次日 9 点该现象会再次出现。 伴随着该报错，能观察到的是 redis 节点的 client connection 会在短暂上升后，迎来一个平台阶段，这个阶段报错最多，后快速上升达到一个数值，此时报错也自动恢复。 下面 client connection 的曲线和报错量曲线

使用版本

redisson 2.9.2 redis 为哨兵模式，1 主 2 从 应用 8 个节点，redis client 配置的最大线程数 100 ，即加起来为 800 ，最小空闲线程数 20 ，图中初始的 300 多，是因为其他应用共用了该 redis 集群。

翻了很多关于 redisson 类似问题，没有相似的，目前没有了排查头绪，求助一下。

[ufan0]

差点怀疑你是我的同事了，哈哈哈。

有检查过内存使用情况吗？

某个应用昨天出现了很多稀奇古怪的问题，后面发现是 Redis 内存爆了。

[alexfarm]

@ufan0 redis 集群的一些指标都看过了，cpu 、内存都正常，就是这个客户端连接数增长得有点可疑

[siweipancc]

我没这么用过的场景（写崩了？），上锁是否有等待获取锁时间，如果有的话可以调低一点。

另一个不负责任的猜想：其他应用的客户端不支持非单机连接。

[alexfarm]

@siweipancc 一般 9:15 恢复之后，QPS 还是这么大，但不会报错了，感觉和等待获取锁时间这些关系不大，不然应该会一直报错

[siweipancc]

@alexfarm 把对面 ban 了试一个早上:D ，我这边崩过，结果是有人没释放锁跟监听器

[alexfarm]

@siweipancc 应该不是。。因为 share 资源的应用都是我们维护的，且还没到 redis 的配置的最大线程数啊

[siweipancc]

@alexfarm 一般这时候我们按数据库连接超时或者锁行来排查（隔壁用了个运维给的虚拟机，线程数是假的）