淺談Redis緩沖區(qū)機(jī)制
Redis緩沖區(qū)機(jī)制
Redis中的緩沖區(qū)機(jī)制就是為了平衡客戶端發(fā)送命令和服務(wù)端處理命令的速度差異，如果客戶端寫入過快或者服務(wù)端讀取過慢這就會導(dǎo)致緩沖區(qū)溢出，緩沖區(qū)一旦溢出將引發(fā)一系列的性能問題，下面我們詳細(xì)聊聊。
客戶端緩沖機(jī)制
Redis為每一個(gè)客戶端都分配了一個(gè)輸入緩沖區(qū)和輸出緩沖區(qū)，輸入緩沖區(qū)會把客戶端的請求命令暫存起來，Redis主線程會從緩沖區(qū)中獲取命令，當(dāng)Redis處理完命令后會將結(jié)果寫入到輸出緩沖區(qū)中，通過輸出緩沖區(qū)返回給客戶端，如下所示
應(yīng)對輸入緩沖區(qū)溢出
輸入緩沖區(qū)溢出一般就是兩種情況
- 寫入數(shù)據(jù)過快，或者寫入bigkey的數(shù)據(jù)占滿數(shù)據(jù)緩沖區(qū)。
- 服務(wù)端處理數(shù)據(jù)過慢，一般是主線程被阻塞無法正常響應(yīng)客戶端請求。
查看輸入緩沖區(qū)信息
我們可以采用client list查看輸入緩沖區(qū)的具體信息
127.0.0.1:6379> client list id=13 addr=127.0.0.1:50484 fd=7 name= age=1136 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client user=default id=14 addr=127.0.0.1:50486 fd=8 name= age=1114 idle=6 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=client user=default
每連接上一個(gè)客戶端就會多一條輸入緩沖區(qū)信息，上面命令是我本地連接兩個(gè)客戶端的結(jié)果，我們查看緩沖區(qū)主要關(guān)注內(nèi)存相關(guān)的兩個(gè)參數(shù)
- qbuf：緩沖區(qū)已經(jīng)使用的長度（字節(jié)為單位，0表示沒有分配緩沖區(qū)）。
- qbuf-free：緩沖區(qū)剩余空閑空間（字節(jié)為單位），上面一個(gè)客戶端的qbuf=26，空閑緩沖區(qū)qbuf-free=32742，那么分配內(nèi)存總大小為26+32742=32768字節(jié)也就是32KB。
如果輸入緩沖區(qū)信息中的qbuf-free很小并且qbuf很大時(shí)就需要注意了，這時(shí)輸入緩沖區(qū)可能已經(jīng)快溢出了，如果此時(shí)還有大量請求寫入輸入緩沖區(qū)，Redis的解決辦法就是關(guān)閉和這個(gè)客戶端的連接，那么業(yè)務(wù)數(shù)據(jù)將無法正常存取。
而且還有一個(gè)問題就是輸入緩沖區(qū)是每一個(gè)客戶端都會存在，那么當(dāng)所有客戶端的輸入緩沖區(qū)內(nèi)存總和超過了maxmemory配置，那么將引發(fā)內(nèi)存淘汰，部分淘汰的數(shù)據(jù)再次訪問需要從后臺數(shù)據(jù)庫獲取，獲取的耗時(shí)肯定比Redis直接讀取慢的多，所以這也是Redis產(chǎn)生延遲的一個(gè)原因。
如何解決輸入緩沖區(qū)溢出
輸入緩沖區(qū)溢出本質(zhì)就是緩沖區(qū)的容量不夠，所以第一個(gè)思路就是擴(kuò)大輸入緩沖區(qū)的大小，很不幸Redis沒有提供給我們修改輸入緩沖區(qū)大小的配置，Redis要求每個(gè)客戶端的輸入緩沖區(qū)最大不能超過1G，注意是每個(gè)客戶端！?。?/strong>，如果客戶端的輸入緩沖區(qū)超過一個(gè)1G將關(guān)閉客戶端連接，所以這個(gè)是行不通的。
那就只能從客戶端發(fā)送數(shù)據(jù)的大小以及服務(wù)端處理命令的速度，客戶端需要避免bigkey的寫入bigkey的劣勢太多一般都需要拆分，第二服務(wù)端的命令處理速度這個(gè)一般依賴于主線程是否阻塞，需要盡量的避免一些阻塞操作如AOF文件重寫，鍵值刪除，fork線程等等。
應(yīng)對輸出緩沖區(qū)溢出
對于服務(wù)端而言，客戶端的輸入信息通常都是不可預(yù)測的，但是輸出信息大多可以預(yù)測，如Set命令返回信息只是一個(gè)簡單的OK，又如一些報(bào)錯信息，Redis為這些不變的返回信息分配了16KB的固定緩沖空間，也就是說輸出緩沖區(qū)分為兩個(gè)部分一部分是輸出緩沖區(qū)固定返回信息，一部分是可變的返回信息。
輸出緩沖區(qū)溢出分為三種情況
- 輸出bigkey等容量大的鍵值。
- 客戶端執(zhí)行Monitor命令，監(jiān)控Redis執(zhí)行。
- 緩沖區(qū)設(shè)置不合理。
bigkey是老生常談的一個(gè)問題，當(dāng)服務(wù)端輸出一個(gè)bigkey或者keys這類命令，對輸出緩沖區(qū)的考驗(yàn)是非常大的，因?yàn)椴樵兊囊凰查g會占據(jù)輸入緩沖區(qū)大量的內(nèi)存空間。
Monitor命令的執(zhí)行
Monitor命令一般是一個(gè)debug命令，用來監(jiān)控Redis的具體執(zhí)行情況，能夠返回服務(wù)器處理的每一個(gè)命令。
127.0.0.1:6379> monitor OK 1652184977.609761 [0 127.0.0.1:50484] "get" "name" 1652185391.529292 [0 127.0.0.1:50484] "set" "test" "lisi" ......
一直運(yùn)行monitor將一直占據(jù)輸出緩沖區(qū)，也就是說占據(jù)時(shí)間越長，越容易造成輸出緩沖區(qū)的溢出，所以Monitor命令僅僅只適用于調(diào)試環(huán)境，不能在生產(chǎn)上執(zhí)行這些命令。
輸出緩沖區(qū)設(shè)置不合理
輸入緩沖區(qū)的大小不能設(shè)置，但是輸出緩沖區(qū)的是可以設(shè)置的我們可以通過配置項(xiàng)client-output-buffer-limit來設(shè)置，設(shè)置的內(nèi)容就是兩部分
- 緩沖區(qū)的內(nèi)存大小，當(dāng)超過緩沖區(qū)配置的大小，服務(wù)端會關(guān)閉和客戶端的連接。
- 持續(xù)寫入的時(shí)間限制和持續(xù)寫入的容量限制，當(dāng)超過持續(xù)寫入時(shí)間限制和容量限制，服務(wù)端也會強(qiáng)制關(guān)閉和客戶端的連接。
客戶端種類
在聊緩沖區(qū)配置時(shí)，我們需要先了解下客戶端的種類，本文中強(qiáng)調(diào)的客戶端并不是單純指通過命令./redis-cli -c -h 127.0.0.1 -p 6379去連接Redis服務(wù)器這類客戶端稱為常規(guī)客戶端，我們還有通過消息訂閱Redis頻道的客戶端，還有一種最為特殊的主從同步，從節(jié)點(diǎn)也是一個(gè)特殊的客戶端稱為從節(jié)點(diǎn)客戶端。
配置項(xiàng)client-output-buffer-limit也是針對這三種，給出了不一樣的配置，如下所示
## 普通客戶端配置 client-output-buffer-limit normal 0 0 0 ## 從節(jié)點(diǎn)客戶端配置 client-output-buffer-limit replica 256mb 64mb 60 ## 消息訂閱頻道的客戶端 client-output-buffer-limit pubsub 32mb 8mb 60 ######################配置解釋###################### ## 第一個(gè)參數(shù)：代表分配給客戶端的緩存大小，為0代表沒有限制 ## 第二個(gè)參數(shù)：表示持續(xù)寫入的最大內(nèi)存，為0代表沒有限制 ## 第三個(gè)參數(shù)：表示持續(xù)寫入的最長時(shí)間，為0代表沒有限制
普通客戶端設(shè)置
普通客戶端就是傳輸?shù)囊恍┢胀ǖ闹噶睿粋€(gè)指令發(fā)送完需要等待其返回后才會發(fā)送下一個(gè)指令，也就是說只要不是返回的bigkey數(shù)據(jù)，占用輸出緩沖區(qū)的內(nèi)存就極少，能夠立即發(fā)送給客戶端響應(yīng)，所以一般正常客戶端默認(rèn)配置都是0，也就是不限制。
消息訂閱頻道客戶端
當(dāng)訂閱頻道產(chǎn)生消息后，會將消息通過輸出緩沖區(qū)發(fā)送給客戶端，這種屬于非阻塞的方式，一瞬間可能有多個(gè)指令到達(dá)，所以需要指定緩沖區(qū)大小。
如何解決輸出緩沖區(qū)溢出
到這里其實(shí)我們已經(jīng)能夠得到輸出緩沖區(qū)溢出的解決方案了
- bigkey應(yīng)當(dāng)避免使用。
- Monitor命令只在調(diào)試的時(shí)候使用，不能應(yīng)用到生產(chǎn)。
- 合理設(shè)置輸出緩沖區(qū)上限、持續(xù)寫入時(shí)間上限以及持續(xù)寫入內(nèi)存容量上限。
主從集群中的緩沖區(qū)
除了輸入緩沖區(qū)和輸出緩沖區(qū)外在主從集群場景下還存在兩種緩沖區(qū)，我們稱為復(fù)制緩沖區(qū)和復(fù)制積壓緩沖區(qū)，這兩個(gè)緩沖區(qū)的溢出和輸入輸出緩沖區(qū)稍有不同。
復(fù)制緩沖區(qū)
復(fù)制緩沖區(qū)這個(gè)名詞看著很陌生，但是我們之前在聊主從同步時(shí)講過，主從全量同步期間從節(jié)點(diǎn)會加載主節(jié)點(diǎn)的RDB文件，這時(shí)主節(jié)點(diǎn)同樣還能寫入數(shù)據(jù)，但是從節(jié)點(diǎn)在加載RDB文件沒辦法實(shí)時(shí)同步，所以Redis就為每一個(gè)從節(jié)點(diǎn)開辟了一片空間，用來存放主從全量同步期間產(chǎn)生的操作命令，這就是replication buffer，也就是復(fù)制緩沖區(qū)。
復(fù)制緩沖區(qū)溢出
復(fù)制緩沖區(qū)什么時(shí)候會溢出呢？
- 當(dāng)從節(jié)點(diǎn)在加載RDB文件這個(gè)過程中如果存在大量的寫操作就會造成復(fù)制緩沖區(qū)內(nèi)存溢出。
- 從節(jié)點(diǎn)加載RDB文件的時(shí)間過長。
發(fā)生溢出后，主節(jié)點(diǎn)會關(guān)閉與從節(jié)點(diǎn)的連接，導(dǎo)致全量同步失敗。
解決復(fù)制緩沖區(qū)溢出
控制主節(jié)點(diǎn)實(shí)例的大小，減小生成的RDB文件，這樣就能減少從節(jié)點(diǎn)加載RDB文件的時(shí)間，減小復(fù)制緩沖區(qū)的壓力。
從節(jié)點(diǎn)其本質(zhì)就是主節(jié)點(diǎn)的特殊客戶端，所以使用的是輸出緩沖區(qū)（也就是指replication buffer），可以設(shè)置client-output-buffer-limit replica 256mb 64mb 60擴(kuò)大緩沖區(qū)大小。
注意：主節(jié)點(diǎn)上的復(fù)制緩沖區(qū)會為每一個(gè)從節(jié)點(diǎn)分配一個(gè)，那么從節(jié)點(diǎn)的數(shù)量過多即使每個(gè)從節(jié)點(diǎn)沒有達(dá)到maxmemory，但累加的結(jié)果也會給主節(jié)點(diǎn)帶來內(nèi)存壓力。
復(fù)制積壓緩沖區(qū)
復(fù)制積壓緩沖區(qū)溢出
主從集群在寫操作時(shí)會將操作寫入復(fù)制緩沖區(qū)和復(fù)制積壓緩沖區(qū)中，一旦網(wǎng)絡(luò)發(fā)送故障后恢復(fù)連接，在2.8版本之前主從節(jié)點(diǎn)會進(jìn)行全量同步開銷非常大，所以2.8版本后還是采用了增量同步，僅僅將網(wǎng)絡(luò)斷開這段時(shí)間的操作同步給從節(jié)點(diǎn)，所以在網(wǎng)絡(luò)恢復(fù)連接后從節(jié)點(diǎn)會將自己的復(fù)制偏移量slave_repl_offset發(fā)送給主節(jié)點(diǎn)，主節(jié)點(diǎn)將自身的寫入偏移量master_repl_offset和slave_repl_offset在復(fù)制積壓緩沖區(qū)中做對比得到網(wǎng)絡(luò)斷連期間的操作。
復(fù)制積壓緩沖區(qū)又叫repl_backlog_buffer，是一個(gè)環(huán)形緩沖區(qū)，同步示意圖如下。
復(fù)制積壓緩沖區(qū)溢出其實(shí)也就是因?yàn)閺?fù)制積壓緩沖區(qū)是一個(gè)有限環(huán)形結(jié)構(gòu)，一般主節(jié)點(diǎn)寫入偏移量要大于從節(jié)點(diǎn)的讀取偏移量，但如果寫入偏移量覆蓋了從節(jié)點(diǎn)的讀取偏移量這就引發(fā)了復(fù)制積壓緩沖區(qū)溢出。
解決復(fù)制積壓緩沖區(qū)溢出
一般是調(diào)整repl_backlog_size這個(gè)參數(shù)的大小，擴(kuò)大復(fù)制積壓緩沖區(qū)的大小，減小主節(jié)點(diǎn)寫入偏移量覆蓋從節(jié)點(diǎn)讀取偏移量的風(fēng)險(xiǎn)。
到此這篇關(guān)于淺談Redis緩沖區(qū)機(jī)制的文章就介紹到這了,更多相關(guān)Redis緩沖區(qū)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
早起的12306購票，剛被開發(fā)出來使用的時(shí)候，12306會經(jīng)常出現(xiàn)超賣 這種現(xiàn)象，也就是說車票只剩10張了，卻被20個(gè)人買到了，這種現(xiàn)象就是超賣，今天通過本文給大家介紹Redis高并發(fā)場景下秒殺超賣解決方案，感興趣的朋友一起看看吧2022-04-04
k8s部署redis cluster集群的實(shí)現(xiàn)
在Kubernetes中部署Redis集群面臨挑戰(zhàn)，因?yàn)槊總€(gè)Redis實(shí)例都依賴于一個(gè)配置文件，該文件可以跟蹤其他集群實(shí)例及其角色。需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-06-06
redisson滑動時(shí)間窗應(yīng)用場景解決方案
前10分鐘內(nèi)累計(jì)3次驗(yàn)證失敗后,增加圖形驗(yàn)證碼驗(yàn)證條件,前10分鐘內(nèi)累計(jì)6次驗(yàn)證失敗后,系統(tǒng)自動鎖定該賬號15分鐘,15分鐘后自動解鎖,本文給大家分享redisson滑動時(shí)間窗應(yīng)用場景解決方案,感興趣的朋友一起看看吧2024-01-01
解讀redis?slaveof命令執(zhí)行后為什么需要清庫重新同步
這篇文章主要介紹了redis?slaveof命令執(zhí)行后為什么需要清庫重新同步,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2025-04-04
這篇文章主要介紹了Redis安裝與使用方法,結(jié)合實(shí)例形式分析了Redis數(shù)據(jù)庫的下載、安裝、啟動、設(shè)置及相關(guān)使用操作注意事項(xiàng),需要的朋友可以參考下2018-04-04
?Redis?實(shí)現(xiàn)計(jì)數(shù)器和限速器的示例代碼
本文主要介紹了?Redis?實(shí)現(xiàn)計(jì)數(shù)器和限速器的示例代碼,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2025-02-02
Redis是一個(gè)key-value存儲系統(tǒng)，現(xiàn)在在各種系統(tǒng)中的使用越來越多，大部分情況下是因?yàn)槠涓咝阅艿奶匦?，被?dāng)做緩存使用，這里介紹下Redis經(jīng)常遇到的使用場景2021-06-06
Redis中LRU算法和LFU算法的區(qū)別小結(jié)
在Redis中,LRU算法和LFU算法是兩種常用的緩存淘汰算法,它們可以幫助我們優(yōu)化緩存性能,本文主要介紹了Redis中LRU算法和LFU算法的區(qū)別,感興趣的可以了解一下2023-12-12
Redis高級玩法之利用SortedSet實(shí)現(xiàn)多維度排序的方法
Redis的SortedSet是可以根據(jù)score進(jìn)行排序的，以手機(jī)應(yīng)用商店的熱門榜單排序?yàn)槔鶕?jù)下載量倒序排列。接下來通過本文給大家分享Redis高級玩法之利用SortedSet實(shí)現(xiàn)多維度排序的方法，一起看看吧2019-07-07
這篇文章主要介紹了Redis批量刪除key的命令詳解,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2023-03-03