淺談Redis常見延遲問題定位與分析

更新時間：2022年06月09日 11:44:13 作者：知知之之

大部分時候,redis延遲很低，但是在某些時刻，有些redis實例會出現(xiàn)很高的響應延時，本文主要介紹了淺談Redis常見延遲問題定位與分析，具有一定的參考價值，感興趣的可以了解一下

使用復雜度高的命令

如果在使用Redis時，發(fā)現(xiàn)訪問延遲突然增大，如何進行排查？

首先，第一步，建議你去查看一下Redis的慢日志。Redis提供了慢日志命令的統(tǒng)計功能，我們通過以下設置，就可以查看有哪些命令在執(zhí)行時延遲比較大。

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

# 命令執(zhí)行超過5毫秒記錄慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000條慢日志
CONFIG SET slowlog-max-len 1000

設置完成之后，所有執(zhí)行的命令如果延遲大于5毫秒，都會被Redis記錄下來，我們執(zhí)行SLOWLOG get 5查詢最近5條慢日志：

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 執(zhí)行時間
   3) (integer) 5299        # 執(zhí)行耗時(微妙)
   4) 1) "LRANGE"           # 具體執(zhí)行的命令和參數(shù)
      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"
...

通過查看慢日志記錄，我們就可以知道在什么時間執(zhí)行哪些命令比較耗時，如果你的業(yè)務經(jīng)常使用O(N)以上復雜度的命令，例如sort、sunion、zunionstore、keys、scan，或者在執(zhí)行O(N)命令時操作的數(shù)據(jù)量比較大，這些情況下Redis處理數(shù)據(jù)時就會很耗時。

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

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

存儲bigkey

如果查詢慢日志發(fā)現(xiàn)，并不是復雜度較高的命令導致的，例如都是SET、DELETE操作出現(xiàn)在慢日志記錄中，那么你就要懷疑是否存在Redis寫入了bigkey的情況。

Redis在寫入數(shù)據(jù)時，需要為新的數(shù)據(jù)分配內存，當從Redis中刪除數(shù)據(jù)時，它會釋放對應的內存空間。

如果一個key寫入的數(shù)據(jù)非常大，Redis在分配內存時也會比較耗時。同樣的，當刪除這個key的數(shù)據(jù)時，釋放內存也會耗時比較久。

你需要檢查你的業(yè)務代碼，是否存在寫入bigkey的情況，需要評估寫入數(shù)據(jù)量的大小，業(yè)務層應該避免一個key存入過大的數(shù)據(jù)量。

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

集中過期

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

如果出現(xiàn)這種情況，就需要考慮是否存在大量key集中過期的情況。

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

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

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

而且這個訪問延遲的情況，不會記錄在慢日志里。慢日志中只記錄真正執(zhí)行某個命令的耗時，Redis主動過期策略執(zhí)行在操作命令之前，如果操作命令耗時達不到慢日志閾值，它是不會計算在慢日志統(tǒng)計中的，但我們的業(yè)務卻感到了延遲增大。

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

實例內存達到上限

有時我們把Redis當做純緩存使用，就會給實例設置一個內存上限maxmemory，然后開啟LRU淘汰策略。

當實例的內存達到了maxmemory后，你會發(fā)現(xiàn)之后的每次寫入新的數(shù)據(jù)，有可能變慢了。

導致變慢的原因是，當Redis內存達到maxmemory后，每次寫入新的數(shù)據(jù)之前，必須先踢出一部分數(shù)據(jù)，讓內存維持在maxmemory之下。

這個踢出舊數(shù)據(jù)的邏輯也是需要消耗時間的，而具體耗時的長短，要取決于配置的淘汰策略

fork耗時嚴重

如果你的Redis開啟了自動生成RDB和AOF重寫功能，那么有可能在后臺生成RDB和AOF重寫時導致Redis的訪問延遲增大，而等這些任務執(zhí)行完畢后，延遲情況消失。

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

生成RDB和AOF都需要父進程fork出一個子進程進行數(shù)據(jù)的持久化，在fork執(zhí)行過程中，父進程需要拷貝內存頁表給子進程，如果整個實例內存占用很大，那么需要拷貝的內存頁表會比較耗時，此過程會消耗大量的CPU資源，在完成fork之前，整個實例會被阻塞住，無法處理任何請求，如果此時CPU資源緊張，那么fork的時間會更長，甚至達到秒級。這會嚴重影響Redis的性能。