Redis 性能優化_ZenDei技術網路在線

概述當我們操作 Redis 發現耗時較長時，原因可能有兩個：服務間存在網路延遲 Redis 服務本身存在問題如果是第一種情況，那麼所有服務都會發生網路延遲，只需要聯繫運維處理即可，這裡主要討論第二種情況 Redis 基準性能測試基準性能指 Redis 在一臺負載正常的機器上的最大響應延遲和平 ...

概述

當我們操作 Redis 發現耗時較長時，原因可能有兩個：

服務間存在網路延遲
Redis 服務本身存在問題

如果是第一種情況，那麼所有服務都會發生網路延遲，只需要聯繫運維處理即可，這裡主要討論第二種情況

Redis 基準性能測試

基準性能指 Redis 在一臺負載正常的機器上的最大響應延遲和平均響應延遲，我們可以找一臺同配置的機器，與原機器比較基準性能，看看 Redis 是不是真的變慢了

從 Redis 2.8.7 開始，redis-cli 命令可以追加 –intrinsic-latency 選項，用於監測和統計某個時間段內 Redis 的最大延遲

# 60 指的是測試時長為 60s，可以任意指定
redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60
Max latency so far: 1 microseconds.
Max latency so far: 157 microseconds.
Max latency so far: 173 microseconds.
Max latency so far: 323 microseconds.
Max latency so far: 324 microseconds.
Max latency so far: 325 microseconds.
Max latency so far: 334 microseconds.
Max latency so far: 520 microseconds.
Max latency so far: 527 microseconds.
Max latency so far: 591 microseconds.
Max latency so far: 1178 microseconds.
Max latency so far: 2299 microseconds.
Max latency so far: 2881 microseconds.
Max latency so far: 4113 microseconds.

597018388 total runs (avg latency: 0.1005 microseconds / 100.50 nanoseconds per run).
Worst run took 40926x longer than the average latency.

從輸出結果可以看出 60s 內最大延遲是 4113 微秒

使用以下命令，查看 Redis 的最小、最大、平均訪問延遲

``shell
redis-cli -h 127.0.0.1 -p 6379 --latency
min: 0, max: 6, avg: 0.24 (6064 samples)

按 ctrl + c 結束命令，可見平均延遲為0.24ms，共統計了 6064 個樣本數據

還可以使用以下命令，查看一段時間內 Redis 的最小、最大、平均訪問延遲

```shell
redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
min: 0, max: 1, avg: 0.29 (98 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.25 (96 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.28 (96 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.26 (96 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.27 (97 samples) -- 1.00 seconds range
...

以上輸出結果是，每隔 1 秒採樣 Redis 的平均操作耗時，其結果分佈在 0.25 ~ 0.29ms 之間

通過以上命令，我們可以在相同配置的伺服器上測試比較 Redis 的基準性能，找到可能變慢了的 Redis 實例

原因分析

找到目標，接下來分析可能導致 Redis 變慢的因素

1. 使用慢日誌查詢耗時命令

Redis 提供了慢日誌命令的統計功能，它記錄了有哪些命令在執行時耗時比較久

查看 Redis 慢日誌之前，你需要設置慢日誌的閾值，例如，設置慢日誌的閾值為 10ms，並且保留最近 128 條慢日誌記錄

在 redis.conf 中設置，重啟 Redis 實例來生效

slowlog-log-slower-than 10000
slowlog-max-len 128

也通過 CONFIG SET 命令動態設置

CONFIG SET slowlog-log-slower-than 10000
CONFIG SET slowlog-max-len 128

執行 slowlog get 命令查詢最近記錄的慢日誌，可以指定返回條數，不指定預設十條

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) "user_info:1000"
.....

通過查看慢日誌，我們就可以知道在什麼時間點，執行了哪些命令比較耗時，一般原因有以下兩個：

使用複雜度過高的命令，如 SORT、SUNION、ZUNIONSTORE 等聚合類命令，
查詢返回數據量過大

2. 操作 bigkey

如果你查詢慢日誌發現，並不是複雜度過高的命令導致的，而都是 SET / DEL 這種簡單命令出現在慢日誌中，那麼你就要考慮你的實例否寫入了 bigkey

Redis 在寫入數據時，需要為新的數據分配記憶體，相對應的，當從 Redis 中刪除數據時，它會釋放對應的記憶體空間。如果一個 key 寫入的 value 非常大，那麼 Redis 在分配記憶體時就會比較耗時。同樣的，當刪除這個 key 時，釋放記憶體也會比較耗時，這種類型的 key 我們一般稱之為 bigkey

Redis 提供了掃描 bigkey 的命令，用於掃描一個實例 bigkey 的分佈情況

redis-cli -h 127.0.0.1 -p 6379 --bigkeys

...
-------- summary -------

Sampled 829675 keys in the keyspace!
Total key length in bytes is 10059825 (avg len 12.13)

Biggest string found 'key:291880' has 10 bytes
Biggest   list found 'mylist:004' has 40 items
Biggest    set found 'myset:2386' has 38 members
Biggest   hash found 'myhash:3574' has 37 fields
Biggest   zset found 'myzset:2704' has 42 members

36313 strings with 363130 bytes (04.38% of keys, avg size 10.00)
787393 lists with 896540 items (94.90% of keys, avg size 1.14)
1994 sets with 40052 members (00.24% of keys, avg size 20.09)
1990 hashs with 39632 fields (00.24% of keys, avg size 19.92)
1985 zsets with 39750 members (00.24% of keys, avg size 20.03)

該命令使用 scan 方式對 key 進行統計，所以無需擔心造成阻塞，但可能會對 Redis 實例造成一定的負擔
輸出大概分為兩部分，summary 之上的部分只是顯示了掃描的過程，summary 部分給出了每種數據結構中最大的 Key
統計的 bigkey 只有 string 類型是以位元組長度來衡量，list、set、zset 等都是以元素個數作為衡量，不能說明其占用記憶體就一定多

針對 bigkey 導致延遲的問題，有兩點可以優化：

將 bigkey 拆分成多個小的 key，需要修改應用程式的代碼
使用壓縮演算法來減小對象的大小
如果你使用的 Redis 是 4.0 以上版本，用 unlink 命令替代 del 命令非同步刪除
如果你使用的 Redis 是 6.0 以上版本，可以開啟 lazy-free 機制（lazyfree-lazy-user-del = yes），在執行 del 命令時，釋放記憶體也會放到後臺線程中執行

3. 集中過期

如果有大量的 key 在某個固定時間點集中過期，在這個時間點訪問 Redis 時，就有可能導致延時變大，如果此時需要過期刪除的是一個 bigkey，那麼這個耗時會更久

解決辦法是分散過期時間，可以為集中過期 key 增加一個隨機過期時間。如果你使用的 Redis 是 4.0 以上版本，可以開啟 lazy-free 機制（lazyfree-lazy-expire yes），當刪除過期 key 時，把釋放記憶體的操作放到後臺線程中執行，避免阻塞主線程

4. 可用記憶體達到上限

Redis 可以設置最大可用記憶體（maxmemory），預設是實例記憶體。當 Redis 達到 maxmemory 時，Redis 必須清除部分數據，從而造成延遲。如果存儲了 bigkey，那麼耗時會更久

使用 info memory 命令查看 Redis 記憶體占用情況，比較 used_memory 和 maxmemory

localhost:6379> info memory
used_memory:692264  # redis 伺服器分配的記憶體總量，也就是內部存儲數據的記憶體占用量
used_memory_human:676.04K  # 以可讀形式返回 used_memory
used_memory_rss:655336  # 從操作系統的角度返回 redis 進程占用的物理記憶體總量
.....
maxmemory:0  # redis 能使用的最大記憶體上限，0 表示沒有上限
maxmemory_human:0B  # 以可讀形式返回 maxmemory

可以調整 Redis 的記憶體淘汰策略，比如改為隨機淘汰，隨機淘汰速度要快很多，儘可能減少耗時。如果使用的是 Redis 4.0 以上版本，開啟 layz-free 機制，把淘汰 key 釋放記憶體的操作放到後臺線程中執行（lazyfree-lazy-eviction = yes）

5. fork 耗時

當 Redis 開啟了後臺 RDB 和 AOF rewrite 後，需要主進程創建出一個子進程進行數據的持久化。主進程創建子進程，會調用操作系統提供的 fork 函數。而 fork 在執行過程中，主進程需要拷貝自己的記憶體頁表給子進程，如果這個實例很大，那麼這個拷貝的過程也會比較耗時

可以執行 info stats 命令獲取到 latest_fork_usec 指標，表示 Redis 最近一次 fork 操作耗時，如果耗時很大，比如超過1秒，則需要做出優化調整

localhost:6379> info stats
...
latest_fork_usec:59477  # 上一次 fork 耗時，單位微秒
...

推薦在低峰期進行備份，而對於丟失數據不敏感的業務（例如把 Redis 當做純緩存使用）可以關閉持久化