这篇文章主要讲解了一次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