Redis鏈接數異常

1、問題分析：

•  TCP是可靠協議，斷開是須要通過4次揮手，既然服務端的鏈接未釋放，那十之八九是客戶端沒有發送斷開請求；
• 即便客戶端沒有主動斷開鏈接，可是這個鏈接實際上已經失效了，可是redis超時時間爲比較長（業務爲長鏈接故比較長）

2、臨時解決

    其狀況緊急業務重要，第一步進行了遷移恢復服務，保留一個現場，進行排查問題

3、問題排查

1. 查看業務方鏈接池，鏈接數狀態 ：狀態正常
2. 查看服務端，鏈接數狀態：鏈接數已上w，異常，致使cpu很高

    問題來了，爲何服務端鏈接數會這麼高？

1. 服務端沒有主動釋放，按照業務方的數據顯示，正常釋放時候不會出現這種狀態的（timeout=3600s）
2. 懷疑網絡丟包，當時ping確實出現丟包，一旦丟包，RedisServer就SB了，Client端私自把鏈接關閉了，然Server端殊不知道，因此鏈接一直保持
3. 這位同窗跟我遇到的狀態是同樣的，你們能夠看看這個詳細分析過程，很給力http://www.yanmingming.net/?p=1609

4、結論

•  客戶端與服務端之間的鏈接問題，可能存在客戶端斷開了鏈接服務端不知曉、服務端斷開了鏈接客戶端不知曉，爲了解決這兩個問題，須要作的就是服務端和客戶端按期檢查，客戶端經過setTestWhileIdle(Boolean.True)、setTimeBetweenEvictionRunsMillis(xxx) 來按期檢查方式死鏈；服務端經過設置超時時間來作到檢查鏈接的問題
• 網絡延遲多關注，一個使人頭痛的問題。