【Redis】Could not get a resource from the pool 实乃集群配置问题

时间:2023-09-11 20:36:08

先说些题外话~自上次确诊为鼻窦炎+过敏性鼻炎到现在已经一个月了,最初那会,从下午到晚上头疼难忍。大概是积劳成疾,以前流鼻涕、打喷嚏的时候从来没有注意过,结果病根一下爆发。

关键在于锁定问题,开始治疗一两天之后就不会头疼了。当然,习惯也很重要,再也不敢用力擤鼻子了。

挺过那一阵就好受很多,之后就是鼻塞稍微烦人一些。鼻子的问题很容易串到其他面部器官中去,一旦发展严重必然大幅度影响生活质量。

治疗方法推荐洗鼻(前两周先消炎,吃地红霉素),但注意不要让医院赚的太狠,药包到药店或者网上买都可以;如果是过敏引发流涕也要吃抗过敏药。

以上,为同样深受困扰的小伙伴提供一些经验。。

【问题】使用jediscluster连接redis集群,使用jedis执行redis命令,一些时候报Could not get a resource from the pool ,底层是连接超时异常,另一些时候则正常。

【复现】时好时坏,有时失败后马上第二次请求相同命令即成功,进一步测试发现竟然与请求的key有关,极难定位问题原因。

【方案】1、考虑为服务端与客户端版本不匹配问题,而

<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>

jedis版本已为最新,另有3.X-m1版本,换用之后也无效。此处麻烦大家告知一下“m1”的意思。

换用spring的包装客户端,spring-data-redis,亦无效。

从时好时坏这一点来看,版本不是主因。事实上,redis对于版本匹配并不如kafka那般严格。

2、考虑为客户端连接参数问题,结合网上各种经验调整JedisPoolConfig与JedisCluster构造方法参数,均无效。这里时间浪费最多,网上信息庞杂而大部分无用。

3、考虑为服务端单个redis节点配置问题,bind不到外网ip,这点很疑惑。

4、考虑为服务端密码问题,从slot槽的设计入手,假设在目前的客户端中,如果请求的key需要转发到其他节点,则因为没有验证密码而被其他节点拒绝。(实际上这是对部署脚本或者jedis集群客户端不信任)

服务端取消密码构建集群后问题依旧,但已经接近问题答案。

【解决】定位问题在于集群节点。

原因排查依据:

(1)命令执行时好时坏,同一命令请求不同key,一些一直成功,其他一直不成功。

(2)查询所有节点的keys命令从未成功。

(3)debug之下发现不成功的命令请求的节点是内网ip,成功的命令是另一节点的外网ip。

原来,为了测试方便,我使用了外网ip构建集群。但是,官方提供的redis-trib.rb脚本带有极大的迷惑性,在构建时返回屏幕的信息正确,而自动生成的每个节点的nodes.conf中,表述自身的一行与预期均有出入,如下所示:

【Redis】Could not get a resource from the pool 实乃集群配置问题

图中139为外网ip,而172则是内网ip。导致客户端经对key哈希后得到的槽,所对应的请求节点有可能拿到内网ip,导致无法连接。超时后报错。

为解决问题,我假设只要该配置存在,节点之间即可相互感知,节点重启后也不会影响集群状态。故而手工将内网ip修改为外网ip,重启每个redis节点,问题解决。

【目前最佳实践】

目前认为官方提供用于构建和管理集群的redis-trib.rb脚本,对外网ip的支持并不完善。因此,

1、在开发测试阶段,通过外网ip构建集群,通过密码保证安全性。

2、单个redis配置:bind注释掉,打开保护模式,设置密码和集群master密码,ruby client.rb中对应修改密码。

我的路径/usr/local/rvm/gems/ruby-2.4.1/gems/redis-4.0.2/lib/redis/client.rb 密码用就替换,不用就填nil,不是空字串!

3、清除每一个节点的持久化记录和之前的nodes.conf之后,用外网ip正常构建集群。

4、手工修改生成的每一个nodes.conf,然后重启对应的redis节点。

如有理解偏差或更好方案,希望可以告知,大家一起讨论。