周六生產服務器出現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
首先看這端口對應的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命令,如果沒有則需要安裝。我們可以通過進程去找所有網絡連接情況。
比如我們剛發現我們的進程主要是docker，他的pid是582251。
lsof -i |grep 582251或者 lsof -i -p 582251
結果如下圖，右邊其實出現了具體IP，這個IP就是docker容器具體的IP地址。
現在知道所有IP和端口了，我們將命令執行結果下載下來。
首先找到自己每個容器對應的IP。
docker inspect name |grep IPAddress //name 容器名稱或者id
找到每個ip后然后根據剛下載的所有網絡連接信息進行統計，看哪個IP連接最多，最多的一個肯定有問題。
然后我就找到這個IP對應的容器部署的程序，然后看redis配置。發現線程池設為200。
另外我通過github,發現CSRedisCore還有個預熱機制，也就是preheat，他默認值就是5個預熱連接。
我們線程池設置的是200加上本身有個預熱機制5個連接，我不知道是不是會創建200*5=1000個。這個有時間再好好研究下源代碼，目前只是猜測。
我現在已經將redis修改為poolsize=5, preheat=false。線程池5個，并且關閉預熱機制。
修改我們連接配置，并重啟應用服務器和redis服務器(為了徹底清除已建立的連接)后發現連接數有減少，但沒有很多。后來查詢發現，是redis的idle空閑時長太長，導致連接池維持太多連接，沒有被釋放。
我們設置下超時為30s
執行CONFIG SET timeout 30 (單位是秒，此種方式只是臨時修改，針對當前運行有效。長效記得修改redis配置文件)
然后再看下連接數多少，這樣一下子就減少了很多。
總結：
1、 redis連接暴增，首先從自身應用程序出發去尋找問題，比如我這邊發現的連接池設置過大，加上默認的預熱機制等。還有盡可能的看代碼層面在創建連接是否會被多次觸發，如果有就必須要改正。現在都是通過注入的方式創建實例，要看該地方是存在被多次調用。
2、修改redis服務器配置，比如連接空閑超時時間。包括也可也看下最大連接數多少，默認值。
到此這篇關于Docker中Redis連接暴增的問題排查的文章就介紹到這了,更多相關Docker中Redis連接暴增問題排查內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！
