redis 服务端连接断开问题诊断

问题现象

前段时间，由于线上 redis 服务器的内存使用率达到了机器总内存的 50% 以上，导致内存数据的 dump 持久化一直失败。扩展到多台 redis 后，应用系统访问 redis 时，在业务量较少时，时不时会出现以下异常，当业务量较大，redis 访问频率很高时，却不会发生这个异常，一时觉得很诡异。

redis.clients.jedis.exceptions.JedisConnectionException: It seems like server has closed the connection.
at redis.clients.util.RedisInputStream.readLine(RedisInputStream.java:90) ~[jedis-2.1.0.jar:na]
at redis.clients.jedis.Protocol.processInteger(Protocol.java:110) ~[jedis-2.1.0.jar:na]
at redis.clients.jedis.Protocol.process(Protocol.java:70) ~[jedis-2.1.0.jar:na]
at redis.clients.jedis.Protocol.read(Protocol.java:131) ~[jedis-2.1.0.jar:na]
at redis.clients.jedis.Connection.getIntegerReply(Connection.java:188) ~[jedis-2.1.0.jar:na]
at redis.clients.jedis.Jedis.sismember(Jedis.java:1266) ~[jedis-2.1.0.jar:na]

看提示，应该是服务端主动关闭了连接。查看了新上线的 redis 服务器的配置，有这么一项：

# Close the connection after a client is idle for N seconds (0 to disable)
timeout 120

这项配置指的是客户端连接空闲超过多少秒后，服务端主动关闭连接，默认值 0 表示服务端永远不主动关闭。而 op 人员把服务器端的超时时间设置为了 120 秒。

这就解释了发生这个异常的原因。客户端使用了一个连接池管理访问 redis 的所有连接，这些连接是长连接，当业务量较小时，客户端部分连接使用率较低，当两次使用之间的间隔超过 120 秒时，redis 服务端就主动关闭了这个连接，而等客户端下次再使用这个连接对象时，发现服务端已经关闭了连接，进而报错。

于是，再查看访问 redis 的系统（客户端）的配置：

客户端使用的是 jedis 内置的连接池，看其源码本质上是基于 apache commons-pool 实现的，其中有一个 eviction 线程，用于回收 idle 对象，对于 redis 连接池来说，也就是回收空闲连接。

JedisPoolConfig 类继承自 GenericObjectPoolConfig 并覆盖了几项关于 eviction 线程的配置，具体如下：

_timeBetweenEvictionRunsMillis：eviction 线程的运行周期。默认是 - 1，表示不启动 eviction 线程。这里设置为 30 秒。

_minEvictableIdleTimeMillis：对象处于 idle 状态的最长时间，默认是 30 分钟，这里设置为 60 秒。

通过客户端的默认配置看，对象的最大空闲时长是小于服务端的配置的，应该不是配置上的问题了。

于是，继续看是不是客户端代码使用上的问题。追踪到客户端代码如下：

可见，客户端首先尝试从本线程的 ThreadLocal 对象中获取 jedis 对象，若获取不到，再从 masterJedisPool 中取得 jedis 对象并放入 ThreadLocal 对象以便下次使用，并且 jedis 对象使用完毕后，没有从 ThreadLocal 中清除，也没有 returnResource 给 masterJedisPool。

因此，问题产生的原因就在于此。ThreadLocal 中的这个 jedis 对象被取出后没有 return，对于对象池来说是处于非 idle 状态，因此不会被对象池 evict。当业务量大时，这个 jedis 会被频繁使用，服务端认为这个 jedis 对应的连接是非空闲的，或者空闲时间达不到 120 秒，不会主动关闭，所以没什么问题。然而当业务量小时，这个 jedis 使用频率很低，当两次之间的使用间隔超出 120 秒时，服务端会主动把这个 jedis 的连接关闭，第二次调用时，就会出现上面的报错。

从代码开发者的角度来说，这么做的目的是避免频繁从 pool 中获取 jedis 对象和 return jedis 对象以提高性能。

解决方案有两个：

1. 在 redis-cli 下在线修改 redis 的配置，把 timeout 改回为 0，无需重启 redis 即可直接生效，但 redis 若重启，配置会恢复。

2. 修改客户端代码，使用完 jedis 对象后，从 ThreadLocal 中清除，再返回给连接池。

出于改动成本考虑，先采用了第一种方案，在线修改 redis 配置后，报错不再出现。