首頁 > 軟體

淺談Redis緩衝區機制

2022-06-02 14:00:12

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命令的執行

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緩衝區機制的文章就介紹到這了,更多相關Redis緩衝區內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com!


IT145.com E-mail:sddin#qq.com