场景

redis服务器端连接产生太多的TIME_WAIT，使用下方的命令统计，高达20000+个状态连接，

netstat -na | grep 6379 | grep TIME_WAIT | wc -l

排查

去查看应用代码中连接redis的方式，发现每次操作都会重新获取一次连接，在操作完毕后则进行close，并没有使用线程池：

这种方式肯定会造成大量的连接被创建，但是TIME_WAIT是由发起关闭请求的一方才会有的状态，每次close都是由客户端发起的，怎么会在服务器方呢？

通过demo + Wireshark确认是由客户端发起的关闭(FIN)请求

通过抓包工具，确认了当使用close方法时，是由客户端发起的关闭请求，TIME_WAIT在客户端这边，

解决方法

既然如此为什么服务端会积压大量的TIME_WAIT，最后下的定论是因为，服务端k8s的网络比较复杂，中间经过了一些代理，大量的连接有一些FIN报文可能因为经过代理时丢失了，

所以最后的解决方案是，使用连接池对redis进行连接，而不是每访问一次就创建一个连接，这个方式本身就会造成很多的资源浪费，使用连接池后，可以确保一个客户端只会有固定的连接到服务端，即使后续发生报文丢失也不会出现大量的TIME_WAIT浪费服务器资源。

telnet与redis

使用telnet连接redis，发送quit命令退出时，发现了一个有意思的现象：

telnet发送一个quit给服务端时，是由redis服务端发起的fin关闭连接命令，此时TIME_WAIT在服务端。