【95期】面試官：你遇到 Redis 線上連接超時一般如何處理？
閱讀本文大概需要 4.5 分鐘。
來自：cnblogs.com/niejunlei/p/12900578.html
一封報警郵件，大量服務(wù)節(jié)點(diǎn) redis 響應(yīng)超時。
又來，好煩。
redis 響應(yīng)變慢，查看日志，發(fā)現(xiàn)大量 TimeoutException。
大量TimeoutException，說明當(dāng)前redis服務(wù)節(jié)點(diǎn)上已經(jīng)堆積了大量的連接查詢，超出redis服務(wù)能力，再次嘗試連接的客戶端，redis 服務(wù)節(jié)點(diǎn)直接拒絕，拋出錯誤。
那到底是什么導(dǎo)致了這種情況的發(fā)生呢？
總結(jié)起來，我們可以從以下幾方面進(jìn)行關(guān)注：
一、redis 服務(wù)節(jié)點(diǎn)受到外部關(guān)聯(lián)影響
redis服務(wù)所在服務(wù)器，物理機(jī)的資源競爭及網(wǎng)絡(luò)狀況等。同一臺服務(wù)器上的服務(wù)必然面對著服務(wù)資源的競爭，CPU，內(nèi)存，固存等。
1、CPU資源競爭
redis屬于CPU密集型服務(wù)，對CPU資源依賴尤為緊密，當(dāng)所在服務(wù)器存在其它CPU密集型應(yīng)用時，必然會影響redis的服務(wù)能力，尤其是在其它服務(wù)對CPU資源消耗不穩(wěn)定的情況下。
因此，在實(shí)際規(guī)劃redis這種基礎(chǔ)性數(shù)據(jù)服務(wù)時應(yīng)該注意一下幾點(diǎn)：
一般不要和其它類型的服務(wù)進(jìn)行混部。
同類型的redis服務(wù)，也應(yīng)該針對所服務(wù)的不同上層應(yīng)用進(jìn)行資源隔離。
說到CPU關(guān)聯(lián)性，可能有人會問是否應(yīng)該對redis服務(wù)進(jìn)行CPU綁定，以降低由CPU上下文切換帶來的性能消耗及關(guān)聯(lián)影響？
簡單來說，是可以的，這種優(yōu)化可以針對任何CPU親和性要求比較高的服務(wù)，但是在此處，有一點(diǎn)我們也應(yīng)該特別注意：我們在 關(guān)于redis內(nèi)存分析，內(nèi)存優(yōu)化 中介紹內(nèi)存時，曾經(jīng)提到過子進(jìn)程內(nèi)存消耗，也就是redis持久化時會fork出子進(jìn)程進(jìn)行AOF/RDB持久化任務(wù)。
對于開啟了持久化配置的redis服務(wù)（一般情況下都會開啟），假如我們做了CPU親和性處理，那么redis fork出的子進(jìn)程則會和父進(jìn)程共享同一個CPU資源，我們知道，redis持久化進(jìn)程是一個非常耗資源的過程，這種自競爭必然會引發(fā)redis服務(wù)的極大不穩(wěn)定。
2、內(nèi)存不在內(nèi)存了
關(guān)于redis內(nèi)存分析，內(nèi)存優(yōu)化?開篇就講過，redis最重要的東西，內(nèi)存。
內(nèi)存穩(wěn)定性是redis提供穩(wěn)定，低延遲服務(wù)的最基本的要求。
然而，我們也知道操作系統(tǒng)有一個 swap 的東西，也就將內(nèi)存交換到硬盤。假如發(fā)生了redis內(nèi)存被交換到硬盤的情景發(fā)生，那么必然，redis服務(wù)能力會驟然下降。
swap發(fā)現(xiàn)及避免：
1）info memory：
關(guān)于redis內(nèi)存分析，內(nèi)存優(yōu)化?中我們也講過，swap這種情景，此時，查看redis的內(nèi)存信息，可以觀察到碎片率會小于1。這也可以作為監(jiān)控redis服務(wù)穩(wěn)定性的一個指標(biāo)。
2）通過redis進(jìn)程查看。
首先通過 info server 獲取進(jìn)程id：
查看 redis 進(jìn)程 swap 情況：cat /proc/1686/smaps
確定交換量都為0KB或者4KB。
3）redis服務(wù)maxmemory配置。
關(guān)于redis內(nèi)存分析，內(nèi)存優(yōu)化 中我們提到過，對redis服務(wù)必要的內(nèi)存上限配置，這是內(nèi)存隔離的一種必要。需要確定的是所有redis實(shí)例的分配內(nèi)存總額小于總的可用物理內(nèi)存。
4）系統(tǒng)優(yōu)化：
另外，在最初的基礎(chǔ)服務(wù)操作系統(tǒng)安裝部署時，也需要做一些必要的前置優(yōu)化，如關(guān)閉swap或配置系統(tǒng)盡量避免使用。
3、網(wǎng)絡(luò)問題
網(wǎng)絡(luò)問題，是一個普遍的影響因素。
1）網(wǎng)絡(luò)資源耗盡
簡單來說，就是帶寬不夠了，整個屬于基礎(chǔ)資源架構(gòu)的問題了，對網(wǎng)絡(luò)資源的預(yù)估不足，跨機(jī)房，異地部署等都會成為誘因。
2）連接數(shù)用完了
一個客戶端連接對應(yīng)著一個TCP連接，一個TCP連接在LINUX系統(tǒng)內(nèi)對應(yīng)著一個文件句柄，系統(tǒng)級別連接句柄用完了，也就無法再進(jìn)行連接了。
查看當(dāng)前系統(tǒng)限制：ulimit -n
設(shè)置：ulimit -n {num}
3）端口TCP backlog隊(duì)列滿了
linux系統(tǒng)對于每個端口使用backlog保存每一個TCP連接。
redis配置：tcp_backlog 默認(rèn)511
高并發(fā)情境下，可以適當(dāng)調(diào)整此配置，但需要注意的是，同時要調(diào)整系統(tǒng)相關(guān)設(shè)置。
系統(tǒng)修改命令：echo {num}>/proc/sys/net/core/somaxconn
查看因?yàn)殛?duì)列溢出導(dǎo)致的連接絕句：netstat -s | grep overflowed
4）網(wǎng)絡(luò)延遲
網(wǎng)絡(luò)質(zhì)量問題，可以使用 redis-cli 進(jìn)行網(wǎng)絡(luò)狀況的測試：
延遲測試：redis-cli -h {host} -p {port} --latency
采樣延遲測試：redis-cli -h {host} -p {port} --latency-history?默認(rèn)15s一次
圖形線上測試結(jié)果：redis-cli -h {host} -p {port} --latency-dist
4）網(wǎng)卡軟中斷
單個網(wǎng)卡隊(duì)列只能使用單個CPU資源問題。
二、redis 服務(wù)使用問題
1、慢查詢
如果你的查詢總是慢查詢，那么必然你的使用存在不合理。
1）你的key規(guī)劃是否合理
太長或太短都是不建議的，key需要設(shè)置的簡短而有意義。
2）值類型選擇是否合理。
hash還是string，set還是zset，避免大對象存儲。
線上可以通過scan命令進(jìn)行大對象發(fā)現(xiàn)治理。
3）是否能夠批查詢
get 還是 mget；是否應(yīng)該使用pipeline。
4）禁止線上大數(shù)據(jù)量操作
2、redis 服務(wù)運(yùn)行狀況
查看redis服務(wù)運(yùn)行狀況：redis-cli -h {host} -p {port} --stat
keys：當(dāng)前key總數(shù)；mem：內(nèi)存使用；clients：當(dāng)前連接client數(shù)；blocked：阻塞數(shù)；requests：累計請求數(shù)；connections：累計連接數(shù)
3、持久化操作影響
1）fork子進(jìn)程影響
redis 進(jìn)行持久化操作需要fork出子進(jìn)程。fork子進(jìn)程本身如果時間過長，則會產(chǎn)生一定的影響。
查看命令最近一次fork耗時：info stats
單位微妙，確保不要超過1s。
2）AOF刷盤阻塞
AOF持久化開啟，后臺每秒進(jìn)行AOF文件刷盤操作，系統(tǒng)fsync操作將AOF文件同步到硬盤，如果主線程發(fā)現(xiàn)距離上一次成功fsync超過2s，則會阻塞后臺線程等待fsync完成以保障數(shù)據(jù)安全性。
3）THP問題
關(guān)于redis內(nèi)存分析，內(nèi)存優(yōu)化 中我們講過透明大頁問題，linux系統(tǒng)的寫時復(fù)制機(jī)制會使得每次寫操作引起的頁復(fù)制由4KB提升至2M從而導(dǎo)致寫慢查詢。如果慢查詢堆積必然導(dǎo)致后續(xù)連接問題。
推薦閱讀：
【94期】面試官：熟悉Redis嗎，項(xiàng)目中你是如何對Redis內(nèi)存進(jìn)行優(yōu)化的
【93期】經(jīng)典面試題：Redis 內(nèi)存滿了怎么辦？
【92期】面試官：你說你精通Java并發(fā)，那給我講講J.U.C吧
微信掃描二維碼，關(guān)注我的公眾號
朕已閱?