首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

从Redis连接池获取连接失败的原因说起(3)

从Redis连接池获取连接失败的原因说起(3)

对RST包的理解

但是我还有一个问题,那就是为什么会有一个RST包呢?如果没有那个RST包,其实问题还不好发现,虽然按照错误日志的时间,挨个查找Redis数据包的信息,能够查询出来,但是RST无疑从一开始就吸引了我的注意,让我能够更加快速的定位问题。
初识RST

那现在问题来了,为什么会有RST包呢?
首先了解一下RST。(可参考TCP/IP详解 卷1 , 18.7 复位报文段)
归纳起来,当以下任一情况发生时,会产生RST包:

    到不存在的端口的连接请求
    异常终止一个连接
    检测半打开连接

jedis与redis的关闭机制

观察RST之前的几个包
931112-ebd5fc72398ace00.png
ws_3.png

使用wireshark的专家信息查看多个RST包,发现RST之前都会有QUIT,OK的交互。那看来应该是框架层面的问题。
再翻看上面GenericObjectPool的相关代码,在borrowObject时如果发生异常,会调用destroyObject()方法,这个destroyObject是延迟到子类实现的,也就是上面说到的JedisPool。

    public void destroyObject(final Object obj) throws Exception {
        if (obj instanceof Jedis) {
            final Jedis jedis = (Jedis) obj;
            if (jedis.isConnected()) {
                try {
                    try {
                        jedis.quit();
                    } catch (Exception e) {
                    }
                    jedis.disconnect();
                } catch (Exception e) {
     
                }
            }
        }
    }

最终调用redis.clients.jedis.Connection的disconnect,关闭输入输出流。

    public void disconnect() {
        if (isConnected()) {
            try {
                inputStream.close();
                outputStream.close();
                if (!socket.isClosed()) {
                    socket.close();
                }
            } catch (IOException ex) {
                throw new JedisConnectionException(ex);
            }
        }
    }
     

这也就解释了为什么会出现RST包:
客户端请求QUIT,服务端返回OK。(此时客户端在接收完quit返回后,调用了disconnect方法,导致连接断开)紧接着服务端发起TCP挥手,发送FIN包到之前交互的客户端51311端口,但调用完disconnect的客户端已经断开了和服务端的连接。客户端只能通过发送RST,通知服务端“你发送了一个到不存在的端口的关闭请求”。

翻看新版的jedis代码,除了将之前JedisPool中实现的代码挪到了JedisFactory中实现,大致逻辑依然没有改变()

    // 2.10 JedisFactory
    @Override
      public void destroyObject(PooledObject<Jedis> pooledJedis) throws Exception {
        final BinaryJedis jedis = pooledJedis.getObject();
        if (jedis.isConnected()) {
          try {
            try {
              jedis.quit();
            } catch (Exception e) {
            }
            jedis.disconnect();
          } catch (Exception e) {
     
          }
        }
      }
     
    @Override
    public boolean validateObject(PooledObject<Jedis> pooledJedis) {
      final BinaryJedis jedis = pooledJedis.getObject();
      try {
        HostAndPort hostAndPort = this.hostAndPort.get();
     
        String connectionHost = jedis.getClient().getHost();
        int connectionPort = jedis.getClient().getPort();
     
        return hostAndPort.getHost().equals(connectionHost)
            && hostAndPort.getPort() == connectionPort && jedis.isConnected()
            && jedis.ping().equals("PONG");
      } catch (final Exception e) {
        return false;
      }
    }
     

而disconnect最终调用的Connection有变化。

    public void disconnect() {
      if (isConnected()) {
        try {
          outputStream.flush();
          socket.close();
        } catch (IOException ex) {
          broken = true;
          throw new JedisConnectionException(ex);
        } finally {
          IOUtils.closeQuietly(socket);
        }
      }
    }
     

由之前的inpusStream.close()和outputStream.close()改成了outputStream.flush()。原因是jedis自定义了带缓冲的RedisOutputStream,在socket.close前要确保缓冲内容写到流中。
客户端使用disconnect确实能够快速释放资源,在调用disconnect时关闭了客户端端口,回收了文件句柄资源。
试想如果在quit后,服务端就已经释放了文件句柄,关闭了socket连接,而客户端不调用disconnect释放资源,就会一直占用资源,在进程结束才会释放。
返回列表