记一次Docker中Redis连接暴增的问题排查

周六生产服务器出现redis服务器不可用状态，错误信息为:

状态不可用，等待后台检查程序恢复方可使用。Unexpected end of stream; expected type 'Status'

如下图所示，下图6300就是我们redis服务器运行的端口。

头一次碰到此类问题，心想难道是redis挂掉了，随即通过telnet ip+端口。发现运行正常，然后就想着进入redis看下目前连接情况。一看发现竟然高达1903条这么多。

然后想着应该是代码创建redis连接过多导致的，查看代码。

发现redis创建只有这一个地方有，这里也是服务注册时才执行。也就是应用程序启动时才被执行一次。然后整个项目查找，没有其他地方再有调用redis初始化。

心有不甘，难道是每次在redis读写数据时都会创建连接吗？会和读写频繁有关系吗？总感觉不会啊，随即创建测试代码进行测试一番。

在本地搭建了一个redis环境，测试之前先看看接数多少，目前看只有1个，也就是目前的cmd连接客户端，这个属于正常的了。

开始测试，运行程序。代码是创建一个连接对象，并一共测试1000次写，和1000次读。

不管我怎么测试连接都是6个，那么也就是说我们程序最多创建了5个连接，当然主要有连接池在里面。

所以基本的存储读取这块代码肯定是没问题。

但代码这块也没算完全放弃排查，因为生产服务器通过docker运行着大约6个应用程序。都是连接的同一个redis,会不会是其他应用程序导致的？

然后就想直接通过redis 连接列表里中随便一个端口来查询对应的进程信息就可以知道是哪些应用程序了。

Linux 中通过查询网络端口号显示进程信息。

netstat -atunlp | grep 60852 //60852这个端口就是我在redis连接列表中随便选择的一个端口号，在redis命令中使用client list列出连接列表，ip后面的就是端口号。

首先看这端口对应的IP，比如这里第一个是172.17.0.1。熟悉docker的同学应该知道这个ip是docker网关IP。我们容器中的程序都是通过这个网关IP来和我们宿主主机来通讯的。我们通过ifconfig就能发现docker这个网关IP，第二个172.17.0.3:6379这个一看就是redis的容器IP，

这样一看确实无法找到具体对应哪个容器中的程序和我们建立连接的。

有一个最笨的办法就是挨个进入容器里面。即docker exec –it test /bin/bash 然后查看当前容器的网络连接情况。这样非常麻烦，并且需要安装很多组件才能执行一系列命令。

另外一个办法lsof命令,通过进程id来查找所有网络连接信息，此命令如果没有则需要安装。这样我们可以通过进程去找所有网络连接情况。

比如我们刚发现我们的进程主要是docker，他的pid是582251。

lsof -i |grep 582251或者 lsof -i -p 582251

结果如下图，右边其实出现了具体IP，这个IP就是docker容器具体的IP地址。