溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“Redis緩沖區機制實例分析”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“Redis緩沖區機制實例分析”文章能幫助大家解決問題。
Redis中的緩沖區機制就是為了平衡客戶端發送命令和服務端處理命令的速度差異，如果客戶端寫入過快或者服務端讀取過慢這就會導致緩沖區溢出，緩沖區一旦溢出將引發一系列的性能問題，下面我們詳細聊聊。
Redis為每一個客戶端都分配了一個輸入緩沖區和輸出緩沖區，輸入緩沖區會把客戶端的請求命令暫存起來，Redis主線程會從緩沖區中獲取命令，當Redis處理完命令后會將結果寫入到輸出緩沖區中，通過輸出緩沖區返回給客戶端，如下所示
輸入緩沖區溢出一般就是兩種情況
寫入數據過快，或者寫入bigkey的數據占滿數據緩沖區。
服務端處理數據過慢，一般是主線程被阻塞無法正常響應客戶端請求。
我們可以采用client list查看輸入緩沖區的具體信息
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
每連接上一個客戶端就會多一條輸入緩沖區信息，上面命令是我本地連接兩個客戶端的結果，我們查看緩沖區主要關注內存相關的兩個參數
qbuf：緩沖區已經使用的長度（字節為單位，0表示沒有分配緩沖區）。
qbuf-free：緩沖區剩余空閑空間（字節為單位），上面一個客戶端的qbuf=26，空閑緩沖區qbuf-free=32742，那么分配內存總大小為26+32742=32768字節也就是32KB。
如果輸入緩沖區信息中的qbuf-free很小并且qbuf很大時就需要注意了，這時輸入緩沖區可能已經快溢出了，如果此時還有大量請求寫入輸入緩沖區，Redis的解決辦法就是關閉和這個客戶端的連接，那么業務數據將無法正常存取。
而且還有一個問題就是輸入緩沖區是每一個客戶端都會存在，那么當所有客戶端的輸入緩沖區內存總和超過了maxmemory配置，那么將引發內存淘汰，部分淘汰的數據再次訪問需要從后臺數據庫獲取，獲取的耗時肯定比Redis直接讀取慢的多，所以這也是Redis產生延遲的一個原因。
輸入緩沖區溢出本質就是緩沖區的容量不夠，所以第一個思路就是擴大輸入緩沖區的大小，很不幸Redis沒有提供給我們修改輸入緩沖區大小的配置，Redis要求每個客戶端的輸入緩沖區最大不能超過1G，注意是每個客戶端！！！，如果客戶端的輸入緩沖區超過一個1G將關閉客戶端連接，所以這個是行不通的。
那就只能從客戶端發送數據的大小以及服務端處理命令的速度，客戶端需要避免bigkey的寫入bigkey的劣勢太多一般都需要拆分，第二服務端的命令處理速度這個一般依賴于主線程是否阻塞，需要盡量的避免一些阻塞操作如AOF文件重寫，鍵值刪除，fork線程等等。
對于服務端而言，客戶端的輸入信息通常都是不可預測的，但是輸出信息大多可以預測，如Set命令返回信息只是一個簡單的OK，又如一些報錯信息，Redis為這些不變的返回信息分配了16KB的固定緩沖空間，也就是說輸出緩沖區分為兩個部分一部分是輸出緩沖區固定返回信息，一部分是可變的返回信息。
輸出緩沖區溢出分為三種情況
輸出bigkey等容量大的鍵值。
客戶端執行Monitor命令，監控Redis執行。
緩沖區設置不合理。
bigkey是老生常談的一個問題，當服務端輸出一個bigkey或者keys這類命令，對輸出緩沖區的考驗是非常大的，因為查詢的一瞬間會占據輸入緩沖區大量的內存空間。
Monitor命令一般是一個debug命令，用來監控Redis的具體執行情況，能夠返回服務器處理的每一個命令。
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" ......
一直運行monitor將一直占據輸出緩沖區，也就是說占據時間越長，越容易造成輸出緩沖區的溢出，所以Monitor命令僅僅只適用于調試環境，不能在生產上執行這些命令。
輸入緩沖區的大小不能設置，但是輸出緩沖區的是可以設置的我們可以通過配置項client-output-buffer-limit來設置，設置的內容就是兩部分
緩沖區的內存大小，當超過緩沖區配置的大小，服務端會關閉和客戶端的連接。
持續寫入的時間限制和持續寫入的容量限制，當超過持續寫入時間限制和容量限制，服務端也會強制關閉和客戶端的連接。
客戶端種類
在聊緩沖區配置時，我們需要先了解下客戶端的種類，本文中強調的客戶端并不是單純指通過命令./redis-cli -c -h 127.0.0.1 -p 6379去連接Redis服務器這類客戶端稱為常規客戶端，我們還有通過消息訂閱Redis頻道的客戶端，還有一種最為特殊的主從同步，從節點也是一個特殊的客戶端稱為從節點客戶端。
配置項client-output-buffer-limit也是針對這三種，給出了不一樣的配置，如下所示
## 普通客戶端配置 client-output-buffer-limit normal 0 0 0 ## 從節點客戶端配置 client-output-buffer-limit replica 256mb 64mb 60 ## 消息訂閱頻道的客戶端 client-output-buffer-limit pubsub 32mb 8mb 60 ######################配置解釋###################### ## 第一個參數：代表分配給客戶端的緩存大小，為0代表沒有限制 ## 第二個參數：表示持續寫入的最大內存，為0代表沒有限制 ## 第三個參數：表示持續寫入的最長時間，為0代表沒有限制
普通客戶端設置
普通客戶端就是傳輸的一些普通的指令，一個指令發送完需要等待其返回后才會發送下一個指令，也就是說只要不是返回的bigkey數據，占用輸出緩沖區的內存就極少，能夠立即發送給客戶端響應，所以一般正常客戶端默認配置都是0，也就是不限制。
消息訂閱頻道客戶端
當訂閱頻道產生消息后，會將消息通過輸出緩沖區發送給客戶端，這種屬于非阻塞的方式，一瞬間可能有多個指令到達，所以需要指定緩沖區大小。
如何解決輸出緩沖區溢出
到這里其實我們已經能夠得到輸出緩沖區溢出的解決方案了
bigkey應當避免使用。
Monitor命令只在調試的時候使用，不能應用到生產。
合理設置輸出緩沖區上限、持續寫入時間上限以及持續寫入內存容量上限。
除了輸入緩沖區和輸出緩沖區外在主從集群場景下還存在兩種緩沖區，我們稱為復制緩沖區和復制積壓緩沖區，這兩個緩沖區的溢出和輸入輸出緩沖區稍有不同。
復制緩沖區這個名詞看著很陌生，但是我們之前在聊主從同步時講過，主從全量同步期間從節點會加載主節點的RDB文件，這時主節點同樣還能寫入數據，但是從節點在加載RDB文件沒辦法實時同步，所以Redis就為每一個從節點開辟了一片空間，用來存放主從全量同步期間產生的操作命令，這就是replication buffer，也就是復制緩沖區。
復制緩沖區什么時候會溢出呢？
當從節點在加載RDB文件這個過程中如果存在大量的寫操作就會造成復制緩沖區內存溢出。
從節點加載RDB文件的時間過長。
發生溢出后，主節點會關閉與從節點的連接，導致全量同步失敗。
解決復制緩沖區溢出
控制主節點實例的大小，減小生成的RDB文件，這樣就能減少從節點加載RDB文件的時間，減小復制緩沖區的壓力。
從節點其本質就是主節點的特殊客戶端，所以使用的是輸出緩沖區（也就是指replication buffer），可以設置client-output-buffer-limit replica 256mb 64mb 60擴大緩沖區大小。
注意：主節點上的復制緩沖區會為每一個從節點分配一個，那么從節點的數量過多即使每個從節點沒有達到maxmemory，但累加的結果也會給主節點帶來內存壓力。
復制積壓緩沖區溢出
主從集群在寫操作時會將操作寫入復制緩沖區和復制積壓緩沖區中，一旦網絡發送故障后恢復連接，在2.8版本之前主從節點會進行全量同步開銷非常大，所以2.8版本后還是采用了增量同步，僅僅將網絡斷開這段時間的操作同步給從節點，所以在網絡恢復連接后從節點會將自己的復制偏移量slave_repl_offset發送給主節點，主節點將自身的寫入偏移量master_repl_offset和slave_repl_offset在復制積壓緩沖區中做對比得到網絡斷連期間的操作。
復制積壓緩沖區又叫repl_backlog_buffer，是一個環形緩沖區，同步示意圖如下。
復制積壓緩沖區溢出其實也就是因為復制積壓緩沖區是一個有限環形結構，一般主節點寫入偏移量要大于從節點的讀取偏移量，但如果寫入偏移量覆蓋了從節點的讀取偏移量這就引發了復制積壓緩沖區溢出。
一般是調整repl_backlog_size這個參數的大小，擴大復制積壓緩沖區的大小，減小主節點寫入偏移量覆蓋從節點讀取偏移量的風險。
關于“Redis緩沖區機制實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
