Redis常見延遲問題怎麼解決

使用複雜度高的指令

如果在使用Redis時，發現存取延遲突然增大，如何進行排查？

首先，第一步，建議你去查看Redis的慢日誌。透過Redis的慢日誌命令統計功能，我們可以設定以下選項來查看哪些命令在執行時產生了較大的延遲。

先設定Redis的慢日誌閾值，只有超過閾值的命令才會被記錄，這裡的單位是微妙，例如設定慢日誌的閾值為5毫秒，同時設定只保留最近1000個慢日誌記錄：

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

設定完成之後，所有執行的指令如果延遲大於5毫秒，都會被Redis記錄下來，我們執行SLOWLOG get 5查詢最近5個慢日誌：

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间
   3) (integer) 5299        # 执行耗时(微妙)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list_2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "book_price_1000"
...

#透過查看慢日誌記錄，我們就可以知道在什麼時間執行哪些指令比較耗時，如果你的業務經常使用O(N)以上複雜度的指令，例如sort、sunion、zunionstore、keys、scan，或是在執行O(N )命令時操作的資料量比較大，這些情況下Redis處理資料時就會很耗時。

如果Redis實例的CPU使用率很高，但你的服務請求量並不大，很可能是因為使用了具有高複雜度的命令所導致的。

解決方案就是，不使用這些複雜度較高的命令，並且一次不要獲取太多的數據，每次盡量操作少量的數據，讓Redis可以及時處理返回。

儲存bigkey

如果查詢慢日誌發現，並不是複雜度較高的指令導致的，例如都是SET、DELETE操作出現在慢日誌記錄中，那麼你就要懷疑是否存在Redis寫入了bigkey的情況。

當Redis寫入新資料時，會為其分配記憶體空間，而當資料被從Redis中刪除時，對應的記憶體空間也會被釋放。

當一個鍵入的資料非常大時，Redis分配記憶體也會變得更加耗時。同樣的，當刪除這個key的資料時，釋放記憶體也會耗時比較久。

你需要檢查你的業務代碼，是否有寫入bigkey的情況，需要評估寫入資料量的大小，業務層應該避免一個key存入過大的資料量。

針對bigkey的問題，Redis官方在4.0版本推出了lazy-free的機制，用於非同步釋放bigkey的內存，降低對Redis效能的影響。即使這樣，我們也不建議使用bigkey，bigkey在叢集的遷移過程中，也會影響到遷移的效能，這個後面在介紹叢集相關的文章時，會再詳細介紹到。

集中過期

有時你會發現，平常在使用Redis時沒有延時比較大的情況，但在某個時間點突然出現一波延時，而且報慢的時間點很有規律，例如某個整點，或是間隔多久就會發生一次。

如果發生這種情況，就需要考慮是否存在大量key集中過期的情況。

如果有大量的key在某個固定時間點集中過期，在這個時間點訪問Redis時，就有可能導致延遲增加。

Redis的過期策略採用定期刪除惰性刪除兩種策略；

注意，Redis的定期刪除的定時任務，也是在Redis主執行緒中執行的，也就是說如果在執行主動過期的過程中，出現了需要大量刪除過期key的情況，那麼在業務訪問時，必須等這個過期任務執行結束，才可以處理業務請求。此時就會出現，業務訪問延遲增加的問題，最大延遲為25毫秒。

而且這個存取延遲的情況，不會記錄在慢日誌裡。慢日誌中只記錄真正執行某個指令的耗時，Redis主動過期策略執行在操作指令之前，如果操作指令耗時達不到慢日誌閾值，它是不會計算在慢日誌統計中的，但我們的業務卻感到了延遲增大。

解決方案是，在集中過期時增加一個隨機時間，把這些需要過期的key的時間打散即可。

實例記憶體達到上限

有時我們把Redis當作純粹快取使用，就會給實例設定一個記憶體上限maxmemory，然後開啟LRU淘汰策略。

當實例的記憶體達到了maxmemory後，你會發現之後的每次寫入新的數據，有可能變慢了。

導致變慢的原因是，當Redis記憶體達到maxmemory後，每次寫入新的數據之前，必須先踢出一部分數據，讓記憶體維持在maxmemory之下。

這個踢出舊資料的邏輯也是需要消耗時間的，而具體耗時的長短，要取決於配置的淘汰策略

fork耗時嚴重

#如果你的Redis開啟了自動產生RDB和AOF重寫功能，那麼有可能在背景產生RDB和AOF重寫時導致Redis的存取延遲增大，而等這些任務執行完畢後，延遲情況消失。

遇到這種情況，一般就是執行生成RDB和AOF重寫任務所導致的。

產生RDB和AOF都需要父進程fork出一個子進程進行資料的持久化，在fork執行過程中，父進程需要拷貝記憶體頁表給子進程，如果整個實例記憶體佔用很大，那麼需要拷貝的記憶體頁表會比較耗時，此過程會消耗大量的CPU資源，在完成fork之前，整個實例會被阻塞住，無法處理任何請求，如果此時CPU資源緊張，那麼fork的時間會更長，甚至達到秒級。這會嚴重影響Redis的效能。

綁定CPU

很多時候，我們在部署服務時，為了提高性能，降低程式在使用多個CPU時上下文切換的性能損耗，一般會採用進程綁定CPU的操作。

但在使用Redis時，我們不建議這麼乾，原因如下。

綁定CPU的Redis，在進行資料持久化時，fork出的子進程，子進程會繼承父進程的CPU使用偏好，而此時子進程會消耗大量的CPU資源進行資料持久化，子行程會與主行程發生CPU爭搶，這也會導致主行程的CPU資源不足存取延遲增加。

所以在部署Redis進程時，如果需要開啟RDB和AOF重寫機制，一定不能進行CPU綁定操作

使用Swap

如果你發現Redis突然變得非常慢，每次訪問的耗時都達到了幾百毫秒甚至秒級，那此時就檢查Redis是否使用到了Swap，這種情況下Redis基本上已經無法提供高性能的服務。

我們知道，作業系統提供了Swap機制，目的是為了當記憶體不足時，可以把一部分記憶體中的資料換到磁碟上，以達到對記憶體使用的緩衝。

但當記憶體中的資料被換到磁碟上後，存取這些資料就需要從磁碟中讀取，這個速度要比記憶體慢太多！

尤其是針對Redis這種高效能的記憶體資料庫來說，如果Redis中的記憶體被換到磁碟上，對於Redis這種效能極為敏感的資料庫，這個操作時間是無法接受的。可以暫時關閉作業系統Swap

網卡負載過高

#就是從某個時間點之後就開始變慢，一直持續。此時，你需要檢查一下機器的網路卡流量是否有被耗盡的情況。

高網路負載會導致在網路層和TCP層級上出現資料傳送延遲和資料遺失等問題。除了記憶體之外，Redis之所以具有高效能，是因為其網路IO表現出色。然而，隨著請求量不斷增加，網卡負載也會相應地增加。

如果發生這種情況，你需要排查這個機器上的哪個Redis實例的流量過大佔滿了網路頻寬，然後確認流量突增是否屬於業務正常情況，如果屬於那就需要及時擴充或遷移實例，避免這個機器的其他實例受到影響。

以上是Redis常見延遲問題怎麼解決的詳細內容。更多資訊請關注PHP中文網其他相關文章！