深入了解Redis連接數(shù)問(wèn)題的現(xiàn)象和解法
1. 前言
一般情況 Redis 連接數(shù)問(wèn)題并不常見(jiàn),但是當(dāng)你業(yè)務(wù)服務(wù)增加、對(duì) Redis 的依賴持續(xù)增強(qiáng)的過(guò)程中,可能會(huì)遇到很多 Redis 的問(wèn)題,這個(gè)時(shí)候,Redis 連接數(shù)可能就成了一個(gè)常見(jiàn)的問(wèn)題。
簡(jiǎn)單定義
:因各種原因,程序?qū)edis的連接數(shù)激增,超過(guò)Redis服務(wù)器能夠承受的上線,從而程序無(wú)法正常訪問(wèn)Redis進(jìn)而引發(fā)功能異常的問(wèn)題。
Redis連接數(shù)問(wèn)題并不常見(jiàn),但現(xiàn)在系統(tǒng)對(duì) Redis 依賴較強(qiáng),并且也是解決各系統(tǒng)性能的利器,連接數(shù)打爆造成的Redis暫時(shí)不可用會(huì)影響正常功能,至少系統(tǒng)性能急劇下降,影響較大。
在本章節(jié),希望能夠帶大家了解Redis連接數(shù)問(wèn)題的現(xiàn)象和解法。
2. 背景知識(shí)
Redis原生支持長(zhǎng)短連接,但與我們使用數(shù)據(jù)庫(kù)類似,大多數(shù)Redis客戶端/中間件都使用了連接池來(lái)管理對(duì)Redis服務(wù)器的連接,從而達(dá)到連接復(fù)用、提高IO效率的效果(連接池的概念與作用不再贅述)。
無(wú)論是Jedis還是Lettuce,都默認(rèn)支持了連接池的配置,池中連接都是長(zhǎng)連接。
通常我們使用Redis可能有幾種場(chǎng)景:
1)用作緩存
,若丟失,程序可以自動(dòng)或手動(dòng)重建,不影響業(yè)務(wù)正確性,但極有可能影響性能;
2)用作存儲(chǔ),若丟失即是業(yè)務(wù)數(shù)據(jù)的丟失,較難恢復(fù),一般為不重要的數(shù)據(jù),業(yè)務(wù)上應(yīng)有預(yù)案;
3)用作分布式鎖
,若丟失則可能造成數(shù)據(jù)一致性問(wèn)題;
4)用作阻塞隊(duì)列,若丟失則可能造成業(yè)務(wù)數(shù)據(jù)的丟失,需要有相應(yīng)的校驗(yàn)與補(bǔ)償措施。
提倡使用1、3,不提倡使用2、4。
特別是4阻塞隊(duì)列,雖不禁止,但對(duì)Redis連接占用極為嚴(yán)重
,應(yīng)作為最后之舉,之前應(yīng)該尋求使用其他消息隊(duì)列中間件、內(nèi)存處理等方案。
3. 問(wèn)題處理
3.1 如何感知連接數(shù)過(guò)多
1)使用INFO命令:Redis提供了 INFO 命令來(lái)獲取Redis服務(wù)器的各種信息和統(tǒng)計(jì)。其中,connected_clients字段表示當(dāng)前已連接的客戶端數(shù)量。
redis-cli info | grep connected_clients
2)使用CLIENT LIST命令:這個(gè)命令可以列出所有連接到Redis服務(wù)器的客戶端信息。
redis-cli client list
3)使用CONFIG GET maxclients命令:可以獲取Redis服務(wù)器允許的最大客戶端連接數(shù)。
redis-cli config get maxclients
4)監(jiān)控工具:搭建監(jiān)控工具,通過(guò)圖像走勢(shì)更能直觀的展現(xiàn)連接數(shù)使用情況。如Prometheus、Grafana、Redis exporter等,來(lái)實(shí)時(shí)監(jiān)控Redis的連接數(shù),大致流程是:
- 在Redis服務(wù)端部署 如Prometheus,用來(lái)抓取數(shù)據(jù) redis 服務(wù)端數(shù)據(jù),還是主要通過(guò) INFO 等指令抓取
- 配置 Prometheus 從 Redis exporter 抓取數(shù)據(jù)
- 配置 Grafana 的數(shù)據(jù)源 Prometheus,用來(lái)展示數(shù)據(jù)
如果你發(fā)現(xiàn)Redis的連接數(shù)過(guò)多,可能需要檢查你的應(yīng)用是否正確地關(guān)閉了不再使用的連接,或者是否有必要增加Redis服務(wù)器的最大連接數(shù)。
3.2 常見(jiàn)原因
1)生產(chǎn)容量規(guī)劃不合理,較多數(shù)量的應(yīng)用機(jī)器但沒(méi)有申請(qǐng)匹配容量的Redis服務(wù)器;
2)正常發(fā)布時(shí),舊節(jié)點(diǎn)摘流后一段時(shí)間內(nèi),其連接池尚未完全斷開(kāi),而同時(shí)新的節(jié)點(diǎn)又啟動(dòng)開(kāi)始連接,使得Redis服務(wù)器面對(duì)了成倍的連接請(qǐng)求;
3)碰到某種連接異常時(shí),程序反復(fù)重試,連接激增;
4)過(guò)度使用阻塞隊(duì)列;
5)使用第三方工具連上Redis,工具本身設(shè)計(jì)不完善(例如scan所有key)引起生產(chǎn)問(wèn)題。
3.3 如何止損
問(wèn)題發(fā)生時(shí)首先可以考慮采取如下措施進(jìn)行止損:
1)若判斷為上述第1、2種原因,首先考慮應(yīng)用縮容
2)若判斷為上述第3、4種原因,首先考慮重啟應(yīng)用(且避免進(jìn)入原因2,參照下方解決方案2)
3)若判斷為上述第5種原因,立即停止工具的使用
4)與此同時(shí),服務(wù)器端請(qǐng)運(yùn)維幫忙清理連接、Redis擴(kuò)容、切從等
3.4 長(zhǎng)效解決方案
1)新功能上線、新活動(dòng)應(yīng)對(duì)時(shí),合理規(guī)劃生產(chǎn)容量,一定數(shù)量的應(yīng)用機(jī)器應(yīng)該匹配相應(yīng)容量的Redis服務(wù)器
2)正常發(fā)布時(shí),舊節(jié)點(diǎn)摘流、新節(jié)點(diǎn)啟動(dòng)兩者的時(shí)間間隔需要適當(dāng)控制,不宜太快,以免依賴資源打滿
3)應(yīng)用代碼中謹(jǐn)慎重試
4)慎重將Redis用作阻塞隊(duì)列,應(yīng)作為最后之舉,之前應(yīng)該尋求使用其他消息隊(duì)列中間件、內(nèi)存處理等方案
5)禁止使用第三方工具連上Redis
以上就是深入了解Redis連接數(shù)問(wèn)題的現(xiàn)象和解法的詳細(xì)內(nèi)容,更多關(guān)于Redis連接數(shù)問(wèn)題的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
RedisTemplate序列化設(shè)置的流程和具體步驟
在使用 Redis 作為緩存數(shù)據(jù)庫(kù)時(shí),我們通常會(huì)使用 RedisTemplate 來(lái)簡(jiǎn)化與 Redis 進(jìn)行交互的操作,而其中一個(gè)重要的配置項(xiàng)就是序列化設(shè)置,它決定了數(shù)據(jù)在存儲(chǔ)到 Redis 中時(shí)的格式,本文將介紹如何進(jìn)行 RedisTemplate 的序列化設(shè)置,以及一些常見(jiàn)的序列化方案2024-11-11Redis中Redisson布隆過(guò)濾器的學(xué)習(xí)
布隆過(guò)濾器是一個(gè)非常長(zhǎng)的二進(jìn)制向量和一系列隨機(jī)哈希函數(shù)的組合,可用于檢索一個(gè)元素是否存在,本文就詳細(xì)的介紹一下Redisson布隆過(guò)濾器,具有一定的參考價(jià)值,感興趣的可以了解一下2022-05-05Redis處理高并發(fā)機(jī)制原理及實(shí)例解析
這篇文章主要介紹了Redis處理高并發(fā)機(jī)制原理及實(shí)例解,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值析,需要的朋友可以參考下2020-08-08redis 過(guò)期策略及內(nèi)存回收機(jī)制解析
這篇文章主要介紹了redis 過(guò)期策略及內(nèi)存回收機(jī)制,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-11-11redis緩存一致性延時(shí)雙刪代碼實(shí)現(xiàn)方式
這篇文章主要介紹了redis緩存一致性延時(shí)雙刪代碼實(shí)現(xiàn)方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-08-08