機(jī)制詳解：輸入輸出與復(fù)制緩沖區(qū)調(diào)優(yōu)實(shí)戰(zhàn))
1. 從一次緩存雪崩說起Redis緩沖區(qū)到底在緩沖什么很多人第一次接觸Redis的“緩沖區(qū)”是在一次線上告警之后。某個(gè)晚上監(jiān)控突然顯示Redis內(nèi)存暴漲緊接著大量請求超時(shí)業(yè)務(wù)側(cè)開始報(bào)錯(cuò)。排查下來發(fā)現(xiàn)問題并不在Redis本身而在于客戶端輸出緩沖區(qū)堆積了大量數(shù)據(jù)——某個(gè)消費(fèi)者處理速度跟不上Redis卻還在拼命往里塞數(shù)據(jù)最終把內(nèi)存撐爆了。這個(gè)場景里提到的“緩沖區(qū)”就是Redis里一個(gè)容易被忽視、但關(guān)鍵時(shí)刻能救命的設(shè)計(jì)。它不像String、Hash、List這些數(shù)據(jù)類型那樣天天被掛在嘴邊但只要你用Redis做消息隊(duì)列、做發(fā)布訂閱、做數(shù)據(jù)同步就一定會和它打交道。所謂緩沖區(qū)本質(zhì)上是Redis在內(nèi)存中劃出的一塊臨時(shí)存儲區(qū)域用來協(xié)調(diào)“生產(chǎn)速度”和“消費(fèi)速度”之間的不平衡。生產(chǎn)者寫得快消費(fèi)者讀得慢中間就需要一個(gè)地方先把數(shù)據(jù)存起來等消費(fèi)者慢慢取。這個(gè)“中間的地方”就是緩沖區(qū)。Redis里的緩沖區(qū)不是一個(gè)單一概念它至少包含三類客戶端輸入緩沖區(qū)、客戶端輸出緩沖區(qū)、復(fù)制緩沖區(qū)。這三者服務(wù)的目標(biāo)不同觸發(fā)條件不同出問題時(shí)的表現(xiàn)也完全不同。很多人把它們混為一談結(jié)果排查問題時(shí)方向就跑偏了。這篇文章會從實(shí)際使用角度出發(fā)把這三類緩沖區(qū)的機(jī)制、配置、監(jiān)控和調(diào)優(yōu)講清楚。不管你是剛接觸Redis的新手還是已經(jīng)用過一段時(shí)間但沒深究過緩沖區(qū)的開發(fā)者都能從中找到可以直接落地的操作方法和避坑經(jīng)驗(yàn)。2. 客戶端輸入緩沖區(qū)那條容易被忽略的“接收管道”2.1 輸入緩沖區(qū)的工作機(jī)制與內(nèi)存上限客戶端輸入緩沖區(qū)英文叫query buffer是Redis用來暫存客戶端發(fā)過來的命令的地方。當(dāng)客戶端通過TCP連接把命令發(fā)給Redis時(shí)Redis不會立刻執(zhí)行而是先把命令讀進(jìn)輸入緩沖區(qū)然后由命令解析器逐條取出執(zhí)行。這個(gè)緩沖區(qū)的大小是動(dòng)態(tài)變化的。如果客戶端發(fā)送的命令很大比如一個(gè)包含幾萬個(gè)元素的批量寫入命令輸入緩沖區(qū)就會臨時(shí)膨脹。Redis默認(rèn)對輸入緩沖區(qū)沒有硬性大小限制但它受client-query-buffer-limit參數(shù)約束默認(rèn)值是1GB。# 查看當(dāng)前輸入緩沖區(qū)限制 redis-cli config get client-query-buffer-limit # 輸出client-query-buffer-limit 1073741824這個(gè)1GB的限制意味著如果某個(gè)客戶端發(fā)送了一個(gè)超過1GB的命令Redis會直接斷開這個(gè)連接并在日志里記錄一條警告。這個(gè)設(shè)計(jì)是為了防止單個(gè)客戶端用超大命令把Redis內(nèi)存打滿。2.2 什么情況下輸入緩沖區(qū)會出問題最常見的輸入緩沖區(qū)問題來自“大key”操作。比如有人用DEL命令刪除一個(gè)包含幾百萬個(gè)元素的Hash或者用HGETALL一次性拉取一個(gè)巨大的Hash。這些命令本身可能不大但Redis在執(zhí)行時(shí)產(chǎn)生的中間數(shù)據(jù)會占用大量內(nèi)存。更隱蔽的情況是客戶端在短時(shí)間內(nèi)發(fā)送了大量命令而Redis處理速度跟不上。這時(shí)候輸入緩沖區(qū)會持續(xù)增長直到觸及上限。一旦觸及上限Redis會強(qiáng)制斷開連接客戶端會收到一個(gè)“connection reset by peer”的錯(cuò)誤。我遇到過這樣一個(gè)案例某業(yè)務(wù)用Redis做批量數(shù)據(jù)導(dǎo)入客戶端一次性發(fā)送了包含50萬條SET命令的pipeline。雖然每條命令都不大但50萬條命令疊加起來輸入緩沖區(qū)瞬間超過了1GBRedis直接斷開了連接。后來改成每批1萬條分50批發(fā)送問題就解決了。提示使用pipeline時(shí)不要一次性塞入過多命令。建議每批控制在5000到10000條之間具體數(shù)量根據(jù)命令大小調(diào)整。2.3 監(jiān)控輸入緩沖區(qū)的實(shí)用方法Redis提供了CLIENT LIST命令可以查看每個(gè)客戶端的輸入緩沖區(qū)使用情況。輸出里的qbuf字段表示輸入緩沖區(qū)當(dāng)前大小qbuf-free表示剩余空間。redis-cli client list # 輸出示例 # id3 addr127.0.0.1:52344 fd8 name age0 idle0 flagsN db0 sub0 psub0 multi-1 qbuf26 qbuf-free20474 obl0 oll0 omem0 eventsr cmdclient如果發(fā)現(xiàn)某個(gè)客戶端的qbuf持續(xù)增長說明這個(gè)客戶端發(fā)送命令的速度超過了Redis的處理速度。這時(shí)候可以考慮在客戶端側(cè)做限流或者優(yōu)化命令結(jié)構(gòu)減少單次發(fā)送的數(shù)據(jù)量。另外可以通過INFO clients查看整體情況redis-cli info clients # 輸出示例 # connected_clients:10 # client_recent_max_input_buffer:20480 # client_recent_max_output_buffer:0 # blocked_clients:0client_recent_max_input_buffer表示最近一段時(shí)間內(nèi)輸入緩沖區(qū)的最大使用量。如果這個(gè)值經(jīng)常接近1GB就需要警惕了。3. 客戶端輸出緩沖區(qū)消費(fèi)者太慢時(shí)的那顆定時(shí)炸彈3.1 輸出緩沖區(qū)的分類與觸發(fā)條件輸出緩沖區(qū)是Redis用來暫存“準(zhǔn)備發(fā)給客戶端但還沒發(fā)出去”的數(shù)據(jù)的地方。它比輸入緩沖區(qū)更容易出問題因?yàn)檩敵鼍彌_區(qū)的增長往往是被動(dòng)的——Redis無法控制客戶端什么時(shí)候來讀數(shù)據(jù)。輸出緩沖區(qū)分為三類對應(yīng)不同的客戶端類型類型對應(yīng)客戶端默認(rèn)限制說明normal普通客戶端0不限制執(zhí)行常規(guī)命令的客戶端slave從節(jié)點(diǎn)客戶端256MB主從復(fù)制時(shí)從節(jié)點(diǎn)連接pubsub發(fā)布訂閱客戶端32MB訂閱了頻道或模式的客戶端普通客戶端的輸出緩沖區(qū)默認(rèn)不限制這是最危險(xiǎn)的地方。如果某個(gè)客戶端執(zhí)行了HGETALL拉取大量數(shù)據(jù)但網(wǎng)絡(luò)很慢或者客戶端處理很慢數(shù)據(jù)就會堆積在輸出緩沖區(qū)里直到把Redis內(nèi)存撐爆。從節(jié)點(diǎn)和發(fā)布訂閱客戶端的輸出緩沖區(qū)有默認(rèn)限制超過限制后Redis會強(qiáng)制斷開連接。這個(gè)設(shè)計(jì)是為了保護(hù)Redis本身避免被慢消費(fèi)者拖垮。3.2 一個(gè)真實(shí)的內(nèi)存暴漲排查過程某次線上告警Redis實(shí)例內(nèi)存從2GB突然漲到8GB持續(xù)了大約10分鐘后回落。排查過程如下第一步查看INFO memory確認(rèn)內(nèi)存確實(shí)異常增長且used_memory_peak遠(yuǎn)高于正常水平。第二步查看INFO clients發(fā)現(xiàn)client_recent_max_output_buffer數(shù)值很大說明有客戶端的輸出緩沖區(qū)在膨脹。第三步執(zhí)行CLIENT LIST按omem字段排序找到輸出緩沖區(qū)占用最大的客戶端。發(fā)現(xiàn)是一個(gè)訂閱了某個(gè)頻道的客戶端omem達(dá)到了200MB。第四步檢查這個(gè)客戶端的消費(fèi)邏輯發(fā)現(xiàn)它在收到消息后做了一段耗時(shí)的數(shù)據(jù)庫寫入操作導(dǎo)致消息在輸出緩沖區(qū)里越積越多。第五步確認(rèn)這個(gè)客戶端訂閱的頻道消息量很大生產(chǎn)端每秒推送幾千條消息而消費(fèi)端每秒只能處理幾百條。問題根因清楚了生產(chǎn)速度遠(yuǎn)大于消費(fèi)速度輸出緩沖區(qū)成了“堰塞湖”。解決方案有兩個(gè)方向一是限制生產(chǎn)端的推送速度二是在消費(fèi)端做異步處理先把消息存到本地隊(duì)列再慢慢消費(fèi)。3.3 輸出緩沖區(qū)的配置與調(diào)優(yōu)針對不同類型的客戶端可以通過以下參數(shù)調(diào)整輸出緩沖區(qū)限制# 普通客戶端輸出緩沖區(qū)限制0表示不限制單位是字節(jié) redis-cli config set client-output-buffer-limit normal 0 0 0 # 從節(jié)點(diǎn)輸出緩沖區(qū)限制硬限制256MB軟限制64MB/60秒 redis-cli config set client-output-buffer-limit slave 268435456 67108864 60 # 發(fā)布訂閱客戶端輸出緩沖區(qū)限制硬限制32MB軟限制8MB/60秒 redis-cli config set client-output-buffer-limit pubsub 33554432 8388608 60硬限制和軟限制的區(qū)別硬限制是“一旦超過就立刻斷開”軟限制是“超過后持續(xù)N秒才斷開”。軟限制給了客戶端一個(gè)緩沖期避免因?yàn)樗矔r(shí)峰值被誤殺。對于普通客戶端我建議不要設(shè)置為0不限制而是設(shè)置一個(gè)合理的硬限制比如512MB。這樣即使某個(gè)客戶端出了問題也不會把整個(gè)Redis實(shí)例拖垮。注意修改client-output-buffer-limit后新連接會立即生效但已有連接需要重新建立才會應(yīng)用新配置。3.4 發(fā)布訂閱場景下的緩沖區(qū)陷阱發(fā)布訂閱是輸出緩沖區(qū)最容易出問題的場景。因?yàn)榘l(fā)布訂閱是“推模式”Redis會主動(dòng)把消息推給訂閱者不管訂閱者能不能處理得過來。假設(shè)一個(gè)頻道每秒產(chǎn)生1萬條消息每條消息1KB那么每秒就是10MB的數(shù)據(jù)。如果訂閱者每秒只能處理1000條那么每秒就有9MB的數(shù)據(jù)堆積在輸出緩沖區(qū)里。32MB的默認(rèn)限制不到4秒就會被突破然后Redis就會斷開這個(gè)訂閱者。更麻煩的是斷開后訂閱者如果自動(dòng)重連又會重新訂閱然后再次被斷開形成“斷開-重連-斷開”的循環(huán)。這個(gè)循環(huán)會消耗大量CPU和網(wǎng)絡(luò)資源。解決這個(gè)問題的思路有幾個(gè)在訂閱者側(cè)做限流控制消息處理速度確保不會堆積。使用Redis Stream代替發(fā)布訂閱Stream支持消費(fèi)者組和ACK機(jī)制可以更好地控制消費(fèi)進(jìn)度。如果消息量確實(shí)很大考慮用消息隊(duì)列中間件替代Redis的發(fā)布訂閱功能。4. 復(fù)制緩沖區(qū)主從同步背后的“蓄水池”4.1 復(fù)制緩沖區(qū)的工作原理復(fù)制緩沖區(qū)是主節(jié)點(diǎn)用來暫存“待發(fā)送給從節(jié)點(diǎn)”的寫命令的地方。當(dāng)主節(jié)點(diǎn)執(zhí)行一個(gè)寫命令后除了寫入自己的數(shù)據(jù)集還會把命令寫入復(fù)制緩沖區(qū)然后由復(fù)制線程發(fā)送給各個(gè)從節(jié)點(diǎn)。復(fù)制緩沖區(qū)分為兩部分固定緩沖區(qū)和動(dòng)態(tài)緩沖區(qū)。固定緩沖區(qū)是一塊固定大小的內(nèi)存默認(rèn)1MB。當(dāng)主從連接正常時(shí)寫命令會先寫入固定緩沖區(qū)然后盡快發(fā)送給從節(jié)點(diǎn)。如果從節(jié)點(diǎn)網(wǎng)絡(luò)延遲較大固定緩沖區(qū)滿了后續(xù)命令就會寫入動(dòng)態(tài)緩沖區(qū)。動(dòng)態(tài)緩沖區(qū)是按需分配的可以動(dòng)態(tài)擴(kuò)展。如果從節(jié)點(diǎn)長時(shí)間無法接收數(shù)據(jù)動(dòng)態(tài)緩沖區(qū)會持續(xù)增長直到觸及client-output-buffer-limit slave的限制然后主節(jié)點(diǎn)會斷開這個(gè)從節(jié)點(diǎn)。4.2 主從延遲導(dǎo)致的緩沖區(qū)膨脹主從延遲是復(fù)制緩沖區(qū)膨脹的常見原因。當(dāng)從節(jié)點(diǎn)處理速度跟不上主節(jié)點(diǎn)時(shí)復(fù)制緩沖區(qū)就會堆積?？梢酝ㄟ^INFO replication查看主從延遲情況redis-cli info replication # 輸出示例 # role:master # connected_slaves:1 # slave0:ip127.0.0.1,port6380,stateonline,offset123456,lag0 # master_repl_offset:123456 # repl_backlog_active:1 # repl_backlog_size:1048576 # repl_backlog_first_byte_offset:1 # repl_backlog_histlen:123456lag字段表示從節(jié)點(diǎn)的延遲秒數(shù)。如果這個(gè)值持續(xù)大于0說明從節(jié)點(diǎn)處理不過來。repl_backlog_size是復(fù)制積壓緩沖區(qū)的大小默認(rèn)1MB。如果從節(jié)點(diǎn)斷開后重連主節(jié)點(diǎn)會嘗試從積壓緩沖區(qū)里補(bǔ)發(fā)數(shù)據(jù)。如果積壓緩沖區(qū)不夠大就需要做全量同步。4.3 復(fù)制緩沖區(qū)的調(diào)優(yōu)參數(shù)# 設(shè)置復(fù)制積壓緩沖區(qū)大小默認(rèn)1MB redis-cli config set repl-backlog-size 64mb # 設(shè)置從節(jié)點(diǎn)輸出緩沖區(qū)限制 redis-cli config set client-output-buffer-limit slave 536870912 134217728 60repl-backlog-size的設(shè)置需要根據(jù)實(shí)際情況調(diào)整。如果主節(jié)點(diǎn)寫入量很大從節(jié)點(diǎn)經(jīng)常斷開重連建議把這個(gè)值調(diào)大比如64MB或128MB。這樣可以避免頻繁的全量同步。從節(jié)點(diǎn)輸出緩沖區(qū)的硬限制建議設(shè)置為512MB軟限制設(shè)置為128MB/60秒。這樣既能容忍一定的網(wǎng)絡(luò)抖動(dòng)又不會讓緩沖區(qū)無限增長。4.4 全量同步與增量同步的緩沖區(qū)差異全量同步時(shí)主節(jié)點(diǎn)會生成RDB文件發(fā)送給從節(jié)點(diǎn)。這個(gè)過程中主節(jié)點(diǎn)會把新產(chǎn)生的寫命令寫入復(fù)制緩沖區(qū)等RDB發(fā)送完成后再把緩沖區(qū)里的命令發(fā)給從節(jié)點(diǎn)。如果RDB文件很大傳輸時(shí)間很長復(fù)制緩沖區(qū)就會堆積大量命令。如果堆積超過限制從節(jié)點(diǎn)會被斷開然后重新嘗試全量同步形成惡性循環(huán)。增量同步時(shí)主節(jié)點(diǎn)只需要把積壓緩沖區(qū)里的命令發(fā)給從節(jié)點(diǎn)數(shù)據(jù)量小得多緩沖區(qū)壓力也小。所以保持主從連接穩(wěn)定、避免頻繁斷開是減少復(fù)制緩沖區(qū)壓力的關(guān)鍵。5. 緩沖區(qū)監(jiān)控與告警把問題扼殺在爆發(fā)之前5.1 需要重點(diǎn)監(jiān)控的指標(biāo)緩沖區(qū)問題往往不是突然出現(xiàn)的而是有一個(gè)漸進(jìn)的過程。通過監(jiān)控以下指標(biāo)可以在問題爆發(fā)前發(fā)現(xiàn)苗頭指標(biāo)來源告警閾值建議說明client_recent_max_input_bufferINFO clients 100MB輸入緩沖區(qū)最大值client_recent_max_output_bufferINFO clients 50MB輸出緩沖區(qū)最大值blocked_clientsINFO clients 0 持續(xù)5分鐘被阻塞的客戶端數(shù)mem_fragmentation_ratioINFO memory 1.5內(nèi)存碎片率used_memory_peakINFO memory接近maxmemory內(nèi)存峰值slave lagINFO replication 10秒從節(jié)點(diǎn)延遲這些指標(biāo)可以通過Redis的INFO命令獲取然后接入監(jiān)控系統(tǒng)。建議設(shè)置兩級告警警告級別和嚴(yán)重級別。警告級別用于提前介入嚴(yán)重級別用于緊急處理。5.2 用CLIENT LIST做實(shí)時(shí)排查當(dāng)告警觸發(fā)后第一步應(yīng)該是執(zhí)行CLIENT LIST查看當(dāng)前所有客戶端的緩沖區(qū)使用情況。# 按輸出緩沖區(qū)大小排序找出占用最大的客戶端 redis-cli client list | awk {print $0} | sort -t -k7 -rn | head -10更精確的做法是用--bigkeys或者寫腳本解析CLIENT LIST輸出提取qbuf、qbuf-free、omem等字段按大小排序。import redis r redis.Redis(hostlocalhost, port6379) clients r.client_list() # 按輸出緩沖區(qū)內(nèi)存排序 sorted_clients sorted(clients, keylambda x: int(x[omem]), reverseTrue) for c in sorted_clients[:10]: print(faddr{c[addr]} name{c[name]} omem{c[omem]} qbuf{c[qbuf]} cmd{c[cmd]})這個(gè)腳本可以快速定位到問題客戶端。拿到客戶端地址后就可以去對應(yīng)的業(yè)務(wù)側(cè)排查消費(fèi)邏輯了。5.3 慢查詢?nèi)罩九c緩沖區(qū)的關(guān)聯(lián)慢查詢?nèi)罩居涗浀氖菆?zhí)行時(shí)間超過閾值的命令。雖然慢查詢本身不直接等于緩沖區(qū)問題但兩者經(jīng)常同時(shí)出現(xiàn)。比如一個(gè)HGETALL命令執(zhí)行了500毫秒返回了10MB數(shù)據(jù)。這500毫秒內(nèi)數(shù)據(jù)會先寫入輸出緩沖區(qū)然后才發(fā)送給客戶端。如果客戶端網(wǎng)絡(luò)慢這10MB數(shù)據(jù)就會在輸出緩沖區(qū)里停留更久。所以分析慢查詢?nèi)罩緯r(shí)不僅要關(guān)注執(zhí)行時(shí)間還要關(guān)注返回?cái)?shù)據(jù)量。返回?cái)?shù)據(jù)量大的命令即使執(zhí)行時(shí)間不長也可能導(dǎo)致輸出緩沖區(qū)膨脹。# 查看慢查詢?nèi)罩?redis-cli slowlog get 10 # 輸出示例 # 1) 1) (integer) 14 # 2) (integer) 1634567890 # 3) (integer) 500000 # 4) 1) HGETALL # 2) big_hash_key # 5) 127.0.0.1:52344 # 6) 慢查詢?nèi)罩纠锏牡?項(xiàng)是命令參數(shù)第5項(xiàng)是客戶端地址。如果發(fā)現(xiàn)某個(gè)客戶端頻繁出現(xiàn)在慢查詢?nèi)罩纠锴颐罘祷財(cái)?shù)據(jù)量大就需要重點(diǎn)檢查這個(gè)客戶端的輸出緩沖區(qū)。6. 實(shí)戰(zhàn)調(diào)優(yōu)不同業(yè)務(wù)場景下的緩沖區(qū)配置策略6.1 緩存場景普通客戶端緩沖區(qū)配置緩存場景下客戶端通常是執(zhí)行GET、SET這類簡單命令返回?cái)?shù)據(jù)量小緩沖區(qū)壓力不大。但也不能完全不管因?yàn)榭倳幸馔馇闆r。建議配置# 普通客戶端輸出緩沖區(qū)硬限制256MB軟限制64MB/60秒 redis-cli config set client-output-buffer-limit normal 268435456 67108864 60 # 輸入緩沖區(qū)限制保持默認(rèn)1GB即可這個(gè)配置下單個(gè)客戶端最多占用256MB輸出緩沖區(qū)。即使出問題也不會把整個(gè)實(shí)例拖垮。6.2 消息隊(duì)列場景發(fā)布訂閱緩沖區(qū)配置用發(fā)布訂閱做消息隊(duì)列時(shí)緩沖區(qū)配置需要更謹(jǐn)慎。因?yàn)榘l(fā)布訂閱是推模式消費(fèi)端一旦跟不上緩沖區(qū)就會快速膨脹。建議配置# 發(fā)布訂閱客戶端輸出緩沖區(qū)硬限制64MB軟限制16MB/30秒 redis-cli config set client-output-buffer-limit pubsub 67108864 16777216 30同時(shí)在消費(fèi)端做限流和異步處理。收到消息后先寫入本地內(nèi)存隊(duì)列然后由獨(dú)立的線程池慢慢消費(fèi)。這樣即使Redis推送速度很快消費(fèi)端也不會因?yàn)樘幚砺鴮?dǎo)致緩沖區(qū)堆積。如果消息量確實(shí)很大建議改用Redis Stream。Stream支持消費(fèi)者組可以控制每個(gè)消費(fèi)者的消費(fèi)進(jìn)度不會因?yàn)閱蝹€(gè)消費(fèi)者慢而影響整個(gè)隊(duì)列。6.3 主從復(fù)制場景復(fù)制緩沖區(qū)配置主從復(fù)制場景下復(fù)制緩沖區(qū)的配置直接影響主從同步的穩(wěn)定性。建議配置# 復(fù)制積壓緩沖區(qū)大小64MB redis-cli config set repl-backlog-size 64mb # 從節(jié)點(diǎn)輸出緩沖區(qū)硬限制512MB軟限制128MB/60秒 redis-cli config set client-output-buffer-limit slave 536870912 134217728 60如果主節(jié)點(diǎn)寫入量很大比如每秒幾十MB建議把repl-backlog-size調(diào)到128MB甚至256MB。這樣可以容忍從節(jié)點(diǎn)更長時(shí)間的斷開避免全量同步。另外建議開啟repl-backlog-ttl設(shè)置一個(gè)合理的過期時(shí)間比如3600秒。這樣當(dāng)所有從節(jié)點(diǎn)都斷開后積壓緩沖區(qū)會在1小時(shí)后自動(dòng)釋放不會一直占用內(nèi)存。6.4 大key場景如何避免緩沖區(qū)被單個(gè)命令打爆大key是緩沖區(qū)問題的常見誘因。一個(gè)包含幾百萬元素的Hash執(zhí)行HGETALL會返回幾十MB數(shù)據(jù)直接寫入輸出緩沖區(qū)。避免大key緩沖區(qū)問題的策略拆分大key。把一個(gè)包含100萬元素的Hash拆成100個(gè)包含1萬元素的Hash用HGETALL時(shí)只拉取需要的那部分。使用HSCAN代替HGETALL。HSCAN是漸進(jìn)式遍歷每次只返回少量數(shù)據(jù)不會一次性把整個(gè)Hash拉出來。在客戶端做分頁。比如用HMGET每次只取100個(gè)字段分多次取完。# 不推薦一次性拉取整個(gè)Hash HGETALL big_hash_key # 推薦用HSCAN漸進(jìn)式遍歷 HSCAN big_hash_key 0 COUNT 100HSCAN的COUNT參數(shù)控制每次返回的元素?cái)?shù)量默認(rèn)是10?？梢愿鶕?jù)實(shí)際情況調(diào)整比如設(shè)置為100或1000。這樣每次只返回少量數(shù)據(jù)輸出緩沖區(qū)不會瞬間膨脹。7. 幾個(gè)容易踩的坑和我的個(gè)人經(jīng)驗(yàn)7.1 不要忽略普通客戶端的輸出緩沖區(qū)限制很多人只關(guān)注從節(jié)點(diǎn)和發(fā)布訂閱的緩沖區(qū)限制覺得普通客戶端不會出問題。但實(shí)際上普通客戶端的輸出緩沖區(qū)默認(rèn)不限制一旦出問題就是大問題。我見過一個(gè)案例某業(yè)務(wù)用LRANGE拉取一個(gè)包含100萬元素的List每次拉取10萬個(gè)元素。客戶端網(wǎng)絡(luò)帶寬有限10萬個(gè)元素的數(shù)據(jù)在輸出緩沖區(qū)里堆積最終把Redis內(nèi)存撐爆了。如果提前設(shè)置了普通客戶端的輸出緩沖區(qū)限制Redis會在這個(gè)客戶端占用過多內(nèi)存時(shí)主動(dòng)斷開它保護(hù)整個(gè)實(shí)例。7.2 軟限制比硬限制更實(shí)用硬限制是“超過就殺”軟限制是“超過后持續(xù)N秒才殺”。在實(shí)際使用中軟限制往往更實(shí)用。因?yàn)榫W(wǎng)絡(luò)抖動(dòng)是常態(tài)瞬時(shí)峰值不應(yīng)該導(dǎo)致連接被斷開。比如發(fā)布訂閱場景設(shè)置硬限制64MB、軟限制16MB/30秒。如果某個(gè)瞬間消息量突增輸出緩沖區(qū)從10MB漲到20MB超過了軟限制但沒超過硬限制。如果30秒內(nèi)回落到16MB以下連接就不會被斷開。如果持續(xù)超過16MB超過30秒才會被斷開。這個(gè)設(shè)計(jì)給了系統(tǒng)一個(gè)緩沖期避免因?yàn)樗矔r(shí)峰值誤殺正常連接。7.3 定期檢查緩沖區(qū)配置是否生效修改緩沖區(qū)配置后一定要驗(yàn)證是否生效。可以通過CONFIG GET查看當(dāng)前配置redis-cli config get client-output-buffer-limit # 輸出示例 # 1) client-output-buffer-limit # 2) normal 268435456 67108864 60 slave 536870912 134217728 60 pubsub 67108864 16777216 30如果配置沒有生效可能是修改方式不對。比如用CONFIG SET修改的配置在Redis重啟后會丟失需要寫入配置文件才能持久化。# 寫入配置文件 redis-cli config rewrite這個(gè)命令會把當(dāng)前配置寫入Redis的配置文件確保重啟后配置不丟失。7.4 緩沖區(qū)問題往往不是Redis的問題最后分享一個(gè)心得緩沖區(qū)問題表面上出在Redis但根因往往在客戶端。消費(fèi)速度慢、網(wǎng)絡(luò)帶寬不足、命令使用不當(dāng)這些才是緩沖區(qū)膨脹的真正原因。所以排查緩沖區(qū)問題時(shí)不要只盯著Redis看要去客戶端側(cè)找原因?？纯聪M(fèi)邏輯是不是有性能瓶頸網(wǎng)絡(luò)是不是有丟包或延遲命令是不是用錯(cuò)了。解決了客戶端的問題緩沖區(qū)問題自然就消失了。我在實(shí)際使用中發(fā)現(xiàn)大部分緩沖區(qū)告警都可以通過優(yōu)化客戶端邏輯來解決。真正需要調(diào)整Redis配置的情況反而不多。所以遇到緩沖區(qū)問題時(shí)先查客戶端再查Redis這個(gè)順序能幫你更快定位問題。 Redis緩沖區(qū)機(jī)制詳解：輸入輸出與復(fù)制緩沖區(qū)調(diào)優(yōu)實(shí)戰(zhàn)
1. 從一次緩存雪崩說起Redis緩沖區(qū)到底在緩沖什么很多人第一次接觸Redis的“緩沖區(qū)”是在一次線上告警之后。某個(gè)晚上監(jiān)控突然顯示Redis內(nèi)存暴漲緊接著大量請求超時(shí)業(yè)務(wù)側(cè)開始報(bào)錯(cuò)。排查下來發(fā)現(xiàn)問題并不在Redis本身而在于客戶端輸出緩沖區(qū)堆積了大量數(shù)據(jù)——某個(gè)消費(fèi)者處理速度跟不上Redis卻還在拼命往里塞數(shù)據(jù)最終把內(nèi)存撐爆了。這個(gè)場景里提到的“緩沖區(qū)”就是Redis里一個(gè)容易被忽視、但關(guān)鍵時(shí)刻能救命的設(shè)計(jì)。它不像String、Hash、List這些數(shù)據(jù)類型那樣天天被掛在嘴邊但只要你用Redis做消息隊(duì)列、做發(fā)布訂閱、做數(shù)據(jù)同步就一定會和它打交道。所謂緩沖區(qū)本質(zhì)上是Redis在內(nèi)存中劃出的一塊臨時(shí)存儲區(qū)域用來協(xié)調(diào)“生產(chǎn)速度”和“消費(fèi)速度”之間的不平衡。生產(chǎn)者寫得快消費(fèi)者讀得慢中間就需要一個(gè)地方先把數(shù)據(jù)存起來等消費(fèi)者慢慢取。這個(gè)“中間的地方”就是緩沖區(qū)。Redis里的緩沖區(qū)不是一個(gè)單一概念它至少包含三類客戶端輸入緩沖區(qū)、客戶端輸出緩沖區(qū)、復(fù)制緩沖區(qū)。這三者服務(wù)的目標(biāo)不同觸發(fā)條件不同出問題時(shí)的表現(xiàn)也完全不同。很多人把它們混為一談結(jié)果排查問題時(shí)方向就跑偏了。這篇文章會從實(shí)際使用角度出發(fā)把這三類緩沖區(qū)的機(jī)制、配置、監(jiān)控和調(diào)優(yōu)講清楚。不管你是剛接觸Redis的新手還是已經(jīng)用過一段時(shí)間但沒深究過緩沖區(qū)的開發(fā)者都能從中找到可以直接落地的操作方法和避坑經(jīng)驗(yàn)。2. 客戶端輸入緩沖區(qū)那條容易被忽略的“接收管道”2.1 輸入緩沖區(qū)的工作機(jī)制與內(nèi)存上限客戶端輸入緩沖區(qū)英文叫query buffer是Redis用來暫存客戶端發(fā)過來的命令的地方。當(dāng)客戶端通過TCP連接把命令發(fā)給Redis時(shí)Redis不會立刻執(zhí)行而是先把命令讀進(jìn)輸入緩沖區(qū)然后由命令解析器逐條取出執(zhí)行。這個(gè)緩沖區(qū)的大小是動(dòng)態(tài)變化的。如果客戶端發(fā)送的命令很大比如一個(gè)包含幾萬個(gè)元素的批量寫入命令輸入緩沖區(qū)就會臨時(shí)膨脹。Redis默認(rèn)對輸入緩沖區(qū)沒有硬性大小限制但它受client-query-buffer-limit參數(shù)約束默認(rèn)值是1GB。# 查看當(dāng)前輸入緩沖區(qū)限制 redis-cli config get client-query-buffer-limit # 輸出client-query-buffer-limit 1073741824這個(gè)1GB的限制意味著如果某個(gè)客戶端發(fā)送了一個(gè)超過1GB的命令Redis會直接斷開這個(gè)連接并在日志里記錄一條警告。這個(gè)設(shè)計(jì)是為了防止單個(gè)客戶端用超大命令把Redis內(nèi)存打滿。2.2 什么情況下輸入緩沖區(qū)會出問題最常見的輸入緩沖區(qū)問題來自“大key”操作。比如有人用DEL命令刪除一個(gè)包含幾百萬個(gè)元素的Hash或者用HGETALL一次性拉取一個(gè)巨大的Hash。這些命令本身可能不大但Redis在執(zhí)行時(shí)產(chǎn)生的中間數(shù)據(jù)會占用大量內(nèi)存。更隱蔽的情況是客戶端在短時(shí)間內(nèi)發(fā)送了大量命令而Redis處理速度跟不上。這時(shí)候輸入緩沖區(qū)會持續(xù)增長直到觸及上限。一旦觸及上限Redis會強(qiáng)制斷開連接客戶端會收到一個(gè)“connection reset by peer”的錯(cuò)誤。我遇到過這樣一個(gè)案例某業(yè)務(wù)用Redis做批量數(shù)據(jù)導(dǎo)入客戶端一次性發(fā)送了包含50萬條SET命令的pipeline。雖然每條命令都不大但50萬條命令疊加起來輸入緩沖區(qū)瞬間超過了1GBRedis直接斷開了連接。后來改成每批1萬條分50批發(fā)送問題就解決了。提示使用pipeline時(shí)不要一次性塞入過多命令。建議每批控制在5000到10000條之間具體數(shù)量根據(jù)命令大小調(diào)整。2.3 監(jiān)控輸入緩沖區(qū)的實(shí)用方法Redis提供了CLIENT LIST命令可以查看每個(gè)客戶端的輸入緩沖區(qū)使用情況。輸出里的qbuf字段表示輸入緩沖區(qū)當(dāng)前大小qbuf-free表示剩余空間。redis-cli client list # 輸出示例 # id3 addr127.0.0.1:52344 fd8 name age0 idle0 flagsN db0 sub0 psub0 multi-1 qbuf26 qbuf-free20474 obl0 oll0 omem0 eventsr cmdclient如果發(fā)現(xiàn)某個(gè)客戶端的qbuf持續(xù)增長說明這個(gè)客戶端發(fā)送命令的速度超過了Redis的處理速度。這時(shí)候可以考慮在客戶端側(cè)做限流或者優(yōu)化命令結(jié)構(gòu)減少單次發(fā)送的數(shù)據(jù)量。另外可以通過INFO clients查看整體情況redis-cli info clients # 輸出示例 # connected_clients:10 # client_recent_max_input_buffer:20480 # client_recent_max_output_buffer:0 # blocked_clients:0client_recent_max_input_buffer表示最近一段時(shí)間內(nèi)輸入緩沖區(qū)的最大使用量。如果這個(gè)值經(jīng)常接近1GB就需要警惕了。3. 客戶端輸出緩沖區(qū)消費(fèi)者太慢時(shí)的那顆定時(shí)炸彈3.1 輸出緩沖區(qū)的分類與觸發(fā)條件輸出緩沖區(qū)是Redis用來暫存“準(zhǔn)備發(fā)給客戶端但還沒發(fā)出去”的數(shù)據(jù)的地方。它比輸入緩沖區(qū)更容易出問題因?yàn)檩敵鼍彌_區(qū)的增長往往是被動(dòng)的——Redis無法控制客戶端什么時(shí)候來讀數(shù)據(jù)。輸出緩沖區(qū)分為三類對應(yīng)不同的客戶端類型類型對應(yīng)客戶端默認(rèn)限制說明normal普通客戶端0不限制執(zhí)行常規(guī)命令的客戶端slave從節(jié)點(diǎn)客戶端256MB主從復(fù)制時(shí)從節(jié)點(diǎn)連接pubsub發(fā)布訂閱客戶端32MB訂閱了頻道或模式的客戶端普通客戶端的輸出緩沖區(qū)默認(rèn)不限制這是最危險(xiǎn)的地方。如果某個(gè)客戶端執(zhí)行了HGETALL拉取大量數(shù)據(jù)但網(wǎng)絡(luò)很慢或者客戶端處理很慢數(shù)據(jù)就會堆積在輸出緩沖區(qū)里直到把Redis內(nèi)存撐爆。從節(jié)點(diǎn)和發(fā)布訂閱客戶端的輸出緩沖區(qū)有默認(rèn)限制超過限制后Redis會強(qiáng)制斷開連接。這個(gè)設(shè)計(jì)是為了保護(hù)Redis本身避免被慢消費(fèi)者拖垮。3.2 一個(gè)真實(shí)的內(nèi)存暴漲排查過程某次線上告警Redis實(shí)例內(nèi)存從2GB突然漲到8GB持續(xù)了大約10分鐘后回落。排查過程如下第一步查看INFO memory確認(rèn)內(nèi)存確實(shí)異常增長且used_memory_peak遠(yuǎn)高于正常水平。第二步查看INFO clients發(fā)現(xiàn)client_recent_max_output_buffer數(shù)值很大說明有客戶端的輸出緩沖區(qū)在膨脹。第三步執(zhí)行CLIENT LIST按omem字段排序找到輸出緩沖區(qū)占用最大的客戶端。發(fā)現(xiàn)是一個(gè)訂閱了某個(gè)頻道的客戶端omem達(dá)到了200MB。第四步檢查這個(gè)客戶端的消費(fèi)邏輯發(fā)現(xiàn)它在收到消息后做了一段耗時(shí)的數(shù)據(jù)庫寫入操作導(dǎo)致消息在輸出緩沖區(qū)里越積越多。第五步確認(rèn)這個(gè)客戶端訂閱的頻道消息量很大生產(chǎn)端每秒推送幾千條消息而消費(fèi)端每秒只能處理幾百條。問題根因清楚了生產(chǎn)速度遠(yuǎn)大于消費(fèi)速度輸出緩沖區(qū)成了“堰塞湖”。解決方案有兩個(gè)方向一是限制生產(chǎn)端的推送速度二是在消費(fèi)端做異步處理先把消息存到本地隊(duì)列再慢慢消費(fèi)。3.3 輸出緩沖區(qū)的配置與調(diào)優(yōu)針對不同類型的客戶端可以通過以下參數(shù)調(diào)整輸出緩沖區(qū)限制# 普通客戶端輸出緩沖區(qū)限制0表示不限制單位是字節(jié) redis-cli config set client-output-buffer-limit normal 0 0 0 # 從節(jié)點(diǎn)輸出緩沖區(qū)限制硬限制256MB軟限制64MB/60秒 redis-cli config set client-output-buffer-limit slave 268435456 67108864 60 # 發(fā)布訂閱客戶端輸出緩沖區(qū)限制硬限制32MB軟限制8MB/60秒 redis-cli config set client-output-buffer-limit pubsub 33554432 8388608 60硬限制和軟限制的區(qū)別硬限制是“一旦超過就立刻斷開”軟限制是“超過后持續(xù)N秒才斷開”。軟限制給了客戶端一個(gè)緩沖期避免因?yàn)樗矔r(shí)峰值被誤殺。對于普通客戶端我建議不要設(shè)置為0不限制而是設(shè)置一個(gè)合理的硬限制比如512MB。這樣即使某個(gè)客戶端出了問題也不會把整個(gè)Redis實(shí)例拖垮。注意修改client-output-buffer-limit后新連接會立即生效但已有連接需要重新建立才會應(yīng)用新配置。3.4 發(fā)布訂閱場景下的緩沖區(qū)陷阱發(fā)布訂閱是輸出緩沖區(qū)最容易出問題的場景。因?yàn)榘l(fā)布訂閱是“推模式”Redis會主動(dòng)把消息推給訂閱者不管訂閱者能不能處理得過來。假設(shè)一個(gè)頻道每秒產(chǎn)生1萬條消息每條消息1KB那么每秒就是10MB的數(shù)據(jù)。如果訂閱者每秒只能處理1000條那么每秒就有9MB的數(shù)據(jù)堆積在輸出緩沖區(qū)里。32MB的默認(rèn)限制不到4秒就會被突破然后Redis就會斷開這個(gè)訂閱者。更麻煩的是斷開后訂閱者如果自動(dòng)重連又會重新訂閱然后再次被斷開形成“斷開-重連-斷開”的循環(huán)。這個(gè)循環(huán)會消耗大量CPU和網(wǎng)絡(luò)資源。解決這個(gè)問題的思路有幾個(gè)在訂閱者側(cè)做限流控制消息處理速度確保不會堆積。使用Redis Stream代替發(fā)布訂閱Stream支持消費(fèi)者組和ACK機(jī)制可以更好地控制消費(fèi)進(jìn)度。如果消息量確實(shí)很大考慮用消息隊(duì)列中間件替代Redis的發(fā)布訂閱功能。4. 復(fù)制緩沖區(qū)主從同步背后的“蓄水池”4.1 復(fù)制緩沖區(qū)的工作原理復(fù)制緩沖區(qū)是主節(jié)點(diǎn)用來暫存“待發(fā)送給從節(jié)點(diǎn)”的寫命令的地方。當(dāng)主節(jié)點(diǎn)執(zhí)行一個(gè)寫命令后除了寫入自己的數(shù)據(jù)集還會把命令寫入復(fù)制緩沖區(qū)然后由復(fù)制線程發(fā)送給各個(gè)從節(jié)點(diǎn)。復(fù)制緩沖區(qū)分為兩部分固定緩沖區(qū)和動(dòng)態(tài)緩沖區(qū)。固定緩沖區(qū)是一塊固定大小的內(nèi)存默認(rèn)1MB。當(dāng)主從連接正常時(shí)寫命令會先寫入固定緩沖區(qū)然后盡快發(fā)送給從節(jié)點(diǎn)。如果從節(jié)點(diǎn)網(wǎng)絡(luò)延遲較大固定緩沖區(qū)滿了后續(xù)命令就會寫入動(dòng)態(tài)緩沖區(qū)。動(dòng)態(tài)緩沖區(qū)是按需分配的可以動(dòng)態(tài)擴(kuò)展。如果從節(jié)點(diǎn)長時(shí)間無法接收數(shù)據(jù)動(dòng)態(tài)緩沖區(qū)會持續(xù)增長直到觸及client-output-buffer-limit slave的限制然后主節(jié)點(diǎn)會斷開這個(gè)從節(jié)點(diǎn)。4.2 主從延遲導(dǎo)致的緩沖區(qū)膨脹主從延遲是復(fù)制緩沖區(qū)膨脹的常見原因。當(dāng)從節(jié)點(diǎn)處理速度跟不上主節(jié)點(diǎn)時(shí)復(fù)制緩沖區(qū)就會堆積?？梢酝ㄟ^INFO replication查看主從延遲情況redis-cli info replication # 輸出示例 # role:master # connected_slaves:1 # slave0:ip127.0.0.1,port6380,stateonline,offset123456,lag0 # master_repl_offset:123456 # repl_backlog_active:1 # repl_backlog_size:1048576 # repl_backlog_first_byte_offset:1 # repl_backlog_histlen:123456lag字段表示從節(jié)點(diǎn)的延遲秒數(shù)。如果這個(gè)值持續(xù)大于0說明從節(jié)點(diǎn)處理不過來。repl_backlog_size是復(fù)制積壓緩沖區(qū)的大小默認(rèn)1MB。如果從節(jié)點(diǎn)斷開后重連主節(jié)點(diǎn)會嘗試從積壓緩沖區(qū)里補(bǔ)發(fā)數(shù)據(jù)。如果積壓緩沖區(qū)不夠大就需要做全量同步。4.3 復(fù)制緩沖區(qū)的調(diào)優(yōu)參數(shù)# 設(shè)置復(fù)制積壓緩沖區(qū)大小默認(rèn)1MB redis-cli config set repl-backlog-size 64mb # 設(shè)置從節(jié)點(diǎn)輸出緩沖區(qū)限制 redis-cli config set client-output-buffer-limit slave 536870912 134217728 60repl-backlog-size的設(shè)置需要根據(jù)實(shí)際情況調(diào)整。如果主節(jié)點(diǎn)寫入量很大從節(jié)點(diǎn)經(jīng)常斷開重連建議把這個(gè)值調(diào)大比如64MB或128MB。這樣可以避免頻繁的全量同步。從節(jié)點(diǎn)輸出緩沖區(qū)的硬限制建議設(shè)置為512MB軟限制設(shè)置為128MB/60秒。這樣既能容忍一定的網(wǎng)絡(luò)抖動(dòng)又不會讓緩沖區(qū)無限增長。4.4 全量同步與增量同步的緩沖區(qū)差異全量同步時(shí)主節(jié)點(diǎn)會生成RDB文件發(fā)送給從節(jié)點(diǎn)。這個(gè)過程中主節(jié)點(diǎn)會把新產(chǎn)生的寫命令寫入復(fù)制緩沖區(qū)等RDB發(fā)送完成后再把緩沖區(qū)里的命令發(fā)給從節(jié)點(diǎn)。如果RDB文件很大傳輸時(shí)間很長復(fù)制緩沖區(qū)就會堆積大量命令。如果堆積超過限制從節(jié)點(diǎn)會被斷開然后重新嘗試全量同步形成惡性循環(huán)。增量同步時(shí)主節(jié)點(diǎn)只需要把積壓緩沖區(qū)里的命令發(fā)給從節(jié)點(diǎn)數(shù)據(jù)量小得多緩沖區(qū)壓力也小。所以保持主從連接穩(wěn)定、避免頻繁斷開是減少復(fù)制緩沖區(qū)壓力的關(guān)鍵。5. 緩沖區(qū)監(jiān)控與告警把問題扼殺在爆發(fā)之前5.1 需要重點(diǎn)監(jiān)控的指標(biāo)緩沖區(qū)問題往往不是突然出現(xiàn)的而是有一個(gè)漸進(jìn)的過程。通過監(jiān)控以下指標(biāo)可以在問題爆發(fā)前發(fā)現(xiàn)苗頭指標(biāo)來源告警閾值建議說明client_recent_max_input_bufferINFO clients 100MB輸入緩沖區(qū)最大值client_recent_max_output_bufferINFO clients 50MB輸出緩沖區(qū)最大值blocked_clientsINFO clients 0 持續(xù)5分鐘被阻塞的客戶端數(shù)mem_fragmentation_ratioINFO memory 1.5內(nèi)存碎片率used_memory_peakINFO memory接近maxmemory內(nèi)存峰值slave lagINFO replication 10秒從節(jié)點(diǎn)延遲這些指標(biāo)可以通過Redis的INFO命令獲取然后接入監(jiān)控系統(tǒng)。建議設(shè)置兩級告警警告級別和嚴(yán)重級別。警告級別用于提前介入嚴(yán)重級別用于緊急處理。5.2 用CLIENT LIST做實(shí)時(shí)排查當(dāng)告警觸發(fā)后第一步應(yīng)該是執(zhí)行CLIENT LIST查看當(dāng)前所有客戶端的緩沖區(qū)使用情況。# 按輸出緩沖區(qū)大小排序找出占用最大的客戶端 redis-cli client list | awk {print $0} | sort -t -k7 -rn | head -10更精確的做法是用--bigkeys或者寫腳本解析CLIENT LIST輸出提取qbuf、qbuf-free、omem等字段按大小排序。import redis r redis.Redis(hostlocalhost, port6379) clients r.client_list() # 按輸出緩沖區(qū)內(nèi)存排序 sorted_clients sorted(clients, keylambda x: int(x[omem]), reverseTrue) for c in sorted_clients[:10]: print(faddr{c[addr]} name{c[name]} omem{c[omem]} qbuf{c[qbuf]} cmd{c[cmd]})這個(gè)腳本可以快速定位到問題客戶端。拿到客戶端地址后就可以去對應(yīng)的業(yè)務(wù)側(cè)排查消費(fèi)邏輯了。5.3 慢查詢?nèi)罩九c緩沖區(qū)的關(guān)聯(lián)慢查詢?nèi)罩居涗浀氖菆?zhí)行時(shí)間超過閾值的命令。雖然慢查詢本身不直接等于緩沖區(qū)問題但兩者經(jīng)常同時(shí)出現(xiàn)。比如一個(gè)HGETALL命令執(zhí)行了500毫秒返回了10MB數(shù)據(jù)。這500毫秒內(nèi)數(shù)據(jù)會先寫入輸出緩沖區(qū)然后才發(fā)送給客戶端。如果客戶端網(wǎng)絡(luò)慢這10MB數(shù)據(jù)就會在輸出緩沖區(qū)里停留更久。所以分析慢查詢?nèi)罩緯r(shí)不僅要關(guān)注執(zhí)行時(shí)間還要關(guān)注返回?cái)?shù)據(jù)量。返回?cái)?shù)據(jù)量大的命令即使執(zhí)行時(shí)間不長也可能導(dǎo)致輸出緩沖區(qū)膨脹。# 查看慢查詢?nèi)罩?redis-cli slowlog get 10 # 輸出示例 # 1) 1) (integer) 14 # 2) (integer) 1634567890 # 3) (integer) 500000 # 4) 1) HGETALL # 2) big_hash_key # 5) 127.0.0.1:52344 # 6) 慢查詢?nèi)罩纠锏牡?項(xiàng)是命令參數(shù)第5項(xiàng)是客戶端地址。如果發(fā)現(xiàn)某個(gè)客戶端頻繁出現(xiàn)在慢查詢?nèi)罩纠锴颐罘祷財(cái)?shù)據(jù)量大就需要重點(diǎn)檢查這個(gè)客戶端的輸出緩沖區(qū)。6. 實(shí)戰(zhàn)調(diào)優(yōu)不同業(yè)務(wù)場景下的緩沖區(qū)配置策略6.1 緩存場景普通客戶端緩沖區(qū)配置緩存場景下客戶端通常是執(zhí)行GET、SET這類簡單命令返回?cái)?shù)據(jù)量小緩沖區(qū)壓力不大。但也不能完全不管因?yàn)榭倳幸馔馇闆r。建議配置# 普通客戶端輸出緩沖區(qū)硬限制256MB軟限制64MB/60秒 redis-cli config set client-output-buffer-limit normal 268435456 67108864 60 # 輸入緩沖區(qū)限制保持默認(rèn)1GB即可這個(gè)配置下單個(gè)客戶端最多占用256MB輸出緩沖區(qū)。即使出問題也不會把整個(gè)實(shí)例拖垮。6.2 消息隊(duì)列場景發(fā)布訂閱緩沖區(qū)配置用發(fā)布訂閱做消息隊(duì)列時(shí)緩沖區(qū)配置需要更謹(jǐn)慎。因?yàn)榘l(fā)布訂閱是推模式消費(fèi)端一旦跟不上緩沖區(qū)就會快速膨脹。建議配置# 發(fā)布訂閱客戶端輸出緩沖區(qū)硬限制64MB軟限制16MB/30秒 redis-cli config set client-output-buffer-limit pubsub 67108864 16777216 30同時(shí)在消費(fèi)端做限流和異步處理。收到消息后先寫入本地內(nèi)存隊(duì)列然后由獨(dú)立的線程池慢慢消費(fèi)。這樣即使Redis推送速度很快消費(fèi)端也不會因?yàn)樘幚砺鴮?dǎo)致緩沖區(qū)堆積。如果消息量確實(shí)很大建議改用Redis Stream。Stream支持消費(fèi)者組可以控制每個(gè)消費(fèi)者的消費(fèi)進(jìn)度不會因?yàn)閱蝹€(gè)消費(fèi)者慢而影響整個(gè)隊(duì)列。6.3 主從復(fù)制場景復(fù)制緩沖區(qū)配置主從復(fù)制場景下復(fù)制緩沖區(qū)的配置直接影響主從同步的穩(wěn)定性。建議配置# 復(fù)制積壓緩沖區(qū)大小64MB redis-cli config set repl-backlog-size 64mb # 從節(jié)點(diǎn)輸出緩沖區(qū)硬限制512MB軟限制128MB/60秒 redis-cli config set client-output-buffer-limit slave 536870912 134217728 60如果主節(jié)點(diǎn)寫入量很大比如每秒幾十MB建議把repl-backlog-size調(diào)到128MB甚至256MB。這樣可以容忍從節(jié)點(diǎn)更長時(shí)間的斷開避免全量同步。另外建議開啟repl-backlog-ttl設(shè)置一個(gè)合理的過期時(shí)間比如3600秒。這樣當(dāng)所有從節(jié)點(diǎn)都斷開后積壓緩沖區(qū)會在1小時(shí)后自動(dòng)釋放不會一直占用內(nèi)存。6.4 大key場景如何避免緩沖區(qū)被單個(gè)命令打爆大key是緩沖區(qū)問題的常見誘因。一個(gè)包含幾百萬元素的Hash執(zhí)行HGETALL會返回幾十MB數(shù)據(jù)直接寫入輸出緩沖區(qū)。避免大key緩沖區(qū)問題的策略拆分大key。把一個(gè)包含100萬元素的Hash拆成100個(gè)包含1萬元素的Hash用HGETALL時(shí)只拉取需要的那部分。使用HSCAN代替HGETALL。HSCAN是漸進(jìn)式遍歷每次只返回少量數(shù)據(jù)不會一次性把整個(gè)Hash拉出來。在客戶端做分頁。比如用HMGET每次只取100個(gè)字段分多次取完。# 不推薦一次性拉取整個(gè)Hash HGETALL big_hash_key # 推薦用HSCAN漸進(jìn)式遍歷 HSCAN big_hash_key 0 COUNT 100HSCAN的COUNT參數(shù)控制每次返回的元素?cái)?shù)量默認(rèn)是10?？梢愿鶕?jù)實(shí)際情況調(diào)整比如設(shè)置為100或1000。這樣每次只返回少量數(shù)據(jù)輸出緩沖區(qū)不會瞬間膨脹。7. 幾個(gè)容易踩的坑和我的個(gè)人經(jīng)驗(yàn)7.1 不要忽略普通客戶端的輸出緩沖區(qū)限制很多人只關(guān)注從節(jié)點(diǎn)和發(fā)布訂閱的緩沖區(qū)限制覺得普通客戶端不會出問題。但實(shí)際上普通客戶端的輸出緩沖區(qū)默認(rèn)不限制一旦出問題就是大問題。我見過一個(gè)案例某業(yè)務(wù)用LRANGE拉取一個(gè)包含100萬元素的List每次拉取10萬個(gè)元素。客戶端網(wǎng)絡(luò)帶寬有限10萬個(gè)元素的數(shù)據(jù)在輸出緩沖區(qū)里堆積最終把Redis內(nèi)存撐爆了。如果提前設(shè)置了普通客戶端的輸出緩沖區(qū)限制Redis會在這個(gè)客戶端占用過多內(nèi)存時(shí)主動(dòng)斷開它保護(hù)整個(gè)實(shí)例。7.2 軟限制比硬限制更實(shí)用硬限制是“超過就殺”軟限制是“超過后持續(xù)N秒才殺”。在實(shí)際使用中軟限制往往更實(shí)用。因?yàn)榫W(wǎng)絡(luò)抖動(dòng)是常態(tài)瞬時(shí)峰值不應(yīng)該導(dǎo)致連接被斷開。比如發(fā)布訂閱場景設(shè)置硬限制64MB、軟限制16MB/30秒。如果某個(gè)瞬間消息量突增輸出緩沖區(qū)從10MB漲到20MB超過了軟限制但沒超過硬限制。如果30秒內(nèi)回落到16MB以下連接就不會被斷開。如果持續(xù)超過16MB超過30秒才會被斷開。這個(gè)設(shè)計(jì)給了系統(tǒng)一個(gè)緩沖期避免因?yàn)樗矔r(shí)峰值誤殺正常連接。7.3 定期檢查緩沖區(qū)配置是否生效修改緩沖區(qū)配置后一定要驗(yàn)證是否生效。可以通過CONFIG GET查看當(dāng)前配置redis-cli config get client-output-buffer-limit # 輸出示例 # 1) client-output-buffer-limit # 2) normal 268435456 67108864 60 slave 536870912 134217728 60 pubsub 67108864 16777216 30如果配置沒有生效可能是修改方式不對。比如用CONFIG SET修改的配置在Redis重啟后會丟失需要寫入配置文件才能持久化。# 寫入配置文件 redis-cli config rewrite這個(gè)命令會把當(dāng)前配置寫入Redis的配置文件確保重啟后配置不丟失。7.4 緩沖區(qū)問題往往不是Redis的問題最后分享一個(gè)心得緩沖區(qū)問題表面上出在Redis但根因往往在客戶端。消費(fèi)速度慢、網(wǎng)絡(luò)帶寬不足、命令使用不當(dāng)這些才是緩沖區(qū)膨脹的真正原因。所以排查緩沖區(qū)問題時(shí)不要只盯著Redis看要去客戶端側(cè)找原因?？纯聪M(fèi)邏輯是不是有性能瓶頸網(wǎng)絡(luò)是不是有丟包或延遲命令是不是用錯(cuò)了。解決了客戶端的問題緩沖區(qū)問題自然就消失了。我在實(shí)際使用中發(fā)現(xiàn)大部分緩沖區(qū)告警都可以通過優(yōu)化客戶端邏輯來解決。真正需要調(diào)整Redis配置的情況反而不多。所以遇到緩沖區(qū)問題時(shí)先查客戶端再查Redis這個(gè)順序能幫你更快定位問題。