背景：
- Redis：阿里云redis集群8个节点
- Redisson version：3.11.1
- 应用：10个pod
阿里云集群中db-7出现异常，自动主从切换，切换后7个pod使用正常，3个pod出现RedisTimeoutException异常。
redirect=null,
entry=MasterSlaveEntry [masterEntry=[freeSubscribeConnectionsAmount=1, freeSubscribeConnectionsCounter=50, freeConnectionsAmount=10, freeConnectionsCounter=64, freezed=false, freezeReason=null, client=[addr=redis://10.10.3.112:6379], nodeType=MASTER, firstFail=0]]],
connection: RedisConnection@1662347556 [redisClient=[addr=redis://10.10.3.113:6379], channel=[id: 0xb21f069b, L:/10.10.3.117:50884 ! R:10.10.3.113/10.10.3.113:6379]], command: (HGET),
command params: [shiro-activeSessionCache, t$afb4da38-cf18-4117-9159-ce16fc61b9d9] after 3 retry attempts
可能一：
redisson版本3.9.1：这版在redis出问题之后，watchdog发现连接无效之后，只打印了一个警告日志，没有自动重连了，后续redis的命令还是继续使用原无效连接。这问题在The connection not reconnect #1811 修复了。
我们使用的是3.11.1查看源码后发现已经升级，不存在该问题
可能二：
怀疑是linux的可打开文件数太小
/etc/security/limits.conf
使用ulimit命令查看，可打开文件数最大1048576，实际情况肯定用不到，这个也排除
可能三：
在redisson的github上找到一个类似情况，使用redis集群，应用有两个pod，redisson版本：3.10.7。一个pod报RedisTimeoutException，另外一个正常，cpu使用率高、需要重启pod恢复正常。我们那天10个pod其中3个pod出现该问题，重启后修复。这个帖子跟我们这次的报错信息和情况一致。
官方给的解答是由于 MPSC 队列的误用，NonStickyEventExecutorGroup 中出现了无限 while 循环导致。
https://github.com/redisson/redisson/issues/2299
https://github.com/netty/netty/pull/9579
可惜当天是线上环境急着降低影响，直接重启了pod，没有查看线程。但问题现象和恢复方法完成一致
问题总结
已知redisson-3.11.5 以下均有这些问题，redisson问题bug还是比较多，建议使用最新的稳定版本。准备升级到 3.13.6。
注意：本文归作者所有，未经作者允许，不得转载
