一、问题分析： TCP是可靠协议，断开是需要经过4次挥手，既然服务端的连接未释放，那十之八九是客户端没有发送断开请求； 即使客户端没有主动断开连接，但是这个连接实际上已经失效了，但是redis超
一、问题分析：
- TCP是可靠协议，断开是需要经过4次挥手，既然服务端的连接未释放，那十之八九是客户端没有发送断开请求；
- 即使客户端没有主动断开连接，但是这个连接实际上已经失效了，但是redis超时时间为比较长（业务为长连接故比较长）
二、临时解决
其情况紧急业务重要，第一步进行了迁移恢复服务，保留一个现场，进行排查问题
三、问题排查
- 查看业务方连接池，连接数状态 ：状态正常
- 查看服务端，连接数状态：连接数已上w，异常，导致cpu很高
问题来了，为什么服务端连接数会这么高？
- 服务端没有主动释放，按照业务方的数据显示，正常释放时候不会出现这种状态的（timeout=3600s）
- 怀疑网络丢包，当时ping确实出现丢包，一旦丢包，RedisServer就SB了，Client端私自把连接关闭了，然Server端却不知道，所以连接一直保持
- 这位同学跟我遇到的状态是一样的，大家可以看看这个详细分析过程，很给力http://www.yanmingming.net/?p=1609
四、结论
- 客户端与服务端之间的连接问题，可能存在客户端断开了连接服务端不知晓、服务端断开了连接客户端不知晓，为了解决这两个问题，需要做的就是服务端和客户端定期检查，客户端通过setTestWhileIdle(Boolean.True)、setTimeBetweenEvictionRunsMillis(xxx) 来定期检查方式死链；服务端通过设置超时时间来做到检查连接的问题
- 网络延迟多关注，一个令人头痛的问题。
