redis Reconnecting,last destination was /ip:port

目录

一、问题背景

二、排查过程

2.1 造成redis重新连接的原因有以下几点

2.2 排查思路

2.3 问题原因

三、解决方案

1、增加 Redis 服务器的最大连接数限制

2、优化应用程序的连接使用方式

3、考虑使用连接池管理 Redis 连接

4、最快速且方便的就是给不用的用户分配不同的索引库

---

一、问题背景

        最近几天我们生产环境中程序老是告警，经过排查日志，发现了奇怪的是在程序执行定时任务过程中老是出现redis重新连接的情况，而且是不定时的发生，这让我百思不得其解。

二、排查过程

        报错内容是：Reconnecting,last destination was /ip:port

        这个报错的意思是：正在重新连接，最后一个重连目标是 /ip:port

报错内容

2.1 造成redis重新连接的原因有以下几点

• 初始连接：当与 Redis 服务器建立初始连接时，会进行握手并建立连接。

• 连接断开：如果与 Redis 的连接意外断开（如网络故障），Redis 客户端会尝试自动重新连接。

• 连接超时：如果 Redis 客户端与服务器之间的连接超时，客户端会尝试重新连接。

• 最大连接数限制：如果 Redis 服务器已达到最大连接数限制，并且没有可用的连接槽位，新的连接请求将会被延迟，直到有可用的连接槽位。

2.2 排查思路

首先我们排除初始连接，因为程序已经稳定运行了一段时间。

其次我们排除连接断开，因为只有在报错前后redis服务是可以正常提供数据的。’

其次我通过日志和redis客户端工具连接redis也正常排除连接超时。

最后剩下一个最大连接限制数，因为我们系统业务量并不大，基本上没有其他业务会去连接redis，然后也排除了这个最大限制数。

2.3 问题原因

万万没想到是因为”最大连接限制数“导致，我们疏忽了一个问题点就是，这台redis有很多用户为其他用户提供服务。你们是不是在想，其他用户的事关你系统什么事？问题就是出现在这里，

redis最大限制数详解:

当 Redis 服务器已达到最大连接数限制，并且没有可用的连接槽位时，新的连接请求会被延迟，直到有可用的连接槽位。

这是因为 Redis 服务器有一个默认的最大连接数限制。一旦达到该限制，任何新的连接请求都会处于排队状态，直到有旧的连接关闭或释放出连接槽位为止。

在排队等待期间，新的连接请求将被暂时挂起，而不会立即获得连接。这意味着连接请求可能会经历一段延迟，直到有可用的连接槽位为止。延迟的时间取决于系统的负载情况和连接的释放速度。

在以上解释中我们知道redis有最大限制，如果超出就会进入排队等待状态。

最最主要的关键点是：

在 Redis 中，不同的账号可以访问相同的库，而不是每个账号都指向独立的库。

        根据以上解释 也就是说，无论使用哪个账号，当切换到第三个数据库时，它们都会指向同一个数据库，而不是独立的库。

这意味着如果 A 账号和 B 账号都切换到第三个数据库，它们会共享相同的数据。对于 A 账号进行的修改或查询操作，B 账号也能看到相同的数据。

因为我们使用的redis服务同时向别的平台提供了服务，然后这个“别的平台”把redis服务直接达到了redis服务的最大连接，也就导致别的连接就会进入等待状态，导致程序报错。

三、解决方案

1、增加 Redis 服务器的最大连接数限制

        这可以通过修改 Redis 配置文件中的 maxclients 参数来实现。注意，增加最大连接数可能会影响服务器的性能和资源消耗，因此需要谨慎权衡。

2、优化应用程序的连接使用方式

        确保连接的及时释放和复用，避免持续的长连接或无效连接占用连接槽位。

3、考虑使用连接池管理 Redis 连接

       连接池可以帮助在应用程序和 Redis 服务器之间维护一组可复用的连接，减少连接的创建和释放开销，提高连接的利用率。

4、最快速且方便的就是给不用的用户分配不同的索引库