周六生產(chǎn)服務(wù)器出現(xiàn)redis服務(wù)器不可用狀態(tài)，錯(cuò)誤信息為:
狀態(tài)不可用，等待后臺檢查程序恢復(fù)方可使用。Unexpected end of stream; expected type 'Status'
如下圖所示，下圖6300就是我們r(jià)edis服務(wù)器運(yùn)行的端口。
頭一次碰到此類問題，心想難道是redis掛掉了，隨即通過telnet ip+端口。發(fā)現(xiàn)運(yùn)行正常，然后就想著進(jìn)入redis看下目前連接情況。一看發(fā)現(xiàn)竟然高達(dá)1903條這么多。
然后想著應(yīng)該是代碼創(chuàng)建redis連接過多導(dǎo)致的，查看代碼。
發(fā)現(xiàn)redis創(chuàng)建只有這一個(gè)地方有，這里也是服務(wù)注冊時(shí)才執(zhí)行。也就是應(yīng)用程序啟動時(shí)才被執(zhí)行一次。然后整個(gè)項(xiàng)目查找，沒有其他地方再有調(diào)用redis初始化。
心有不甘，難道是每次在redis讀寫數(shù)據(jù)時(shí)都會創(chuàng)建連接嗎？會和讀寫頻繁有關(guān)系嗎？總感覺不會啊，隨即創(chuàng)建測試代碼進(jìn)行測試一番。
在本地搭建了一個(gè)redis環(huán)境，測試之前先看看接數(shù)多少，目前看只有1個(gè)，也就是目前的cmd連接客戶端，這個(gè)屬于正常的了。
開始測試，運(yùn)行程序。代碼是創(chuàng)建一個(gè)連接對象，并一共測試1000次寫，和1000次讀。
不管我怎么測試連接都是6個(gè)，那么也就是說我們程序最多創(chuàng)建了5個(gè)連接，當(dāng)然主要有線程池在里面。
所以基本的存儲讀取這塊代碼肯定是沒問題。
但代碼這塊也沒算完全放棄排查，因?yàn)樯a(chǎn)服務(wù)器通過docker運(yùn)行著大約6個(gè)應(yīng)用程序。都是連接的同一個(gè)redis,會不會是其他應(yīng)用程序?qū)е碌模?/p>
然后就想直接通過redis 連接列表里的中隨便一個(gè)端口來查詢對應(yīng)的進(jìn)程信息就可以知道是哪些應(yīng)用程序了。
Linux 中通過查詢網(wǎng)絡(luò)端口號顯示進(jìn)程信息。
netstat -atunlp | grep 60852
首先看這端口對應(yīng)的IP，比如這里第一個(gè)是172.17.0.1。熟悉docker的同學(xué)應(yīng)該知道這個(gè)ip是docker網(wǎng)關(guān)IP。我們?nèi)萜髦械某绦蚨际峭ㄟ^這個(gè)網(wǎng)關(guān)IP來和我們宿主主機(jī)來通訊的。我們通過ifconfig就能發(fā)現(xiàn)docker這個(gè)網(wǎng)關(guān)IP，第二個(gè)172.17.0.3:6379這個(gè)一看就是redis的容器IP，
這樣一看確實(shí)無法找到具體對應(yīng)哪個(gè)容器中的程序和我們建立連接的。
有一個(gè)最笨的辦法就是挨個(gè)進(jìn)入容器里面。即docker exec –it test /bin/bash 然后查看當(dāng)前容器的網(wǎng)絡(luò)連接情況。這樣非常麻煩，并且需要安裝很多組件才能執(zhí)行一系列命令。
另外一個(gè)辦法lsof命令,如果沒有則需要安裝。我們可以通過進(jìn)程去找所有網(wǎng)絡(luò)連接情況。
比如我們剛發(fā)現(xiàn)我們的進(jìn)程主要是docker，他的pid是582251。
lsof -i |grep 582251或者 lsof -i -p 582251
結(jié)果如下圖，右邊其實(shí)出現(xiàn)了具體IP，這個(gè)IP就是docker容器具體的IP地址。
現(xiàn)在知道所有IP和端口了，我們將命令執(zhí)行結(jié)果下載下來。
首先找到自己每個(gè)容器對應(yīng)的IP。
docker inspect name |grep IPAddress //name 容器名稱或者id
找到每個(gè)ip后然后根據(jù)剛下載的所有網(wǎng)絡(luò)連接信息進(jìn)行統(tǒng)計(jì)，看哪個(gè)IP連接最多，最多的一個(gè)肯定有問題。
然后我就找到這個(gè)IP對應(yīng)的容器部署的程序，然后看redis配置。發(fā)現(xiàn)線程池設(shè)為200。
另外我通過github,發(fā)現(xiàn)CSRedisCore還有個(gè)預(yù)熱機(jī)制，也就是preheat，他默認(rèn)值就是5個(gè)預(yù)熱連接。
我們線程池設(shè)置的是200加上本身有個(gè)預(yù)熱機(jī)制5個(gè)連接，我不知道是不是會創(chuàng)建200*5=1000個(gè)。這個(gè)有時(shí)間再好好研究下源代碼，目前只是猜測。
我現(xiàn)在已經(jīng)將redis修改為poolsize=5, preheat=false。線程池5個(gè)，并且關(guān)閉預(yù)熱機(jī)制。
修改我們連接配置，并重啟應(yīng)用服務(wù)器和redis服務(wù)器(為了徹底清除已建立的連接)后發(fā)現(xiàn)連接數(shù)有減少，但沒有很多。后來查詢發(fā)現(xiàn)，是redis的idle空閑時(shí)長太長，導(dǎo)致連接池維持太多連接，沒有被釋放。
我們設(shè)置下超時(shí)為30s
執(zhí)行CONFIG SET timeout 30 (單位是秒，此種方式只是臨時(shí)修改，針對當(dāng)前運(yùn)行有效。長效記得修改redis配置文件)
然后再看下連接數(shù)多少，這樣一下子就減少了很多。
總結(jié)：
1、 redis連接暴增，首先從自身應(yīng)用程序出發(fā)去尋找問題，比如我這邊發(fā)現(xiàn)的連接池設(shè)置過大，加上默認(rèn)的預(yù)熱機(jī)制等。還有盡可能的看代碼層面在創(chuàng)建連接是否會被多次觸發(fā)，如果有就必須要改正?，F(xiàn)在都是通過注入的方式創(chuàng)建實(shí)例，要看該地方是存在被多次調(diào)用。
2、修改redis服務(wù)器配置，比如連接空閑超時(shí)時(shí)間。包括也可也看下最大連接數(shù)多少，默認(rèn)值。
到此這篇關(guān)于Docker中Redis連接暴增的問題排查的文章就介紹到這了,更多相關(guān)Docker中Redis連接暴增問題排查內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
