如何判斷redis慢了

來自

https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247532967&idx=1&sn=19790c981aa33502aa1e3a8abe9cd064&chksm=e92a7ca8de5df5befc6cc534cbabdb847eff41d0b7cef373191e49df38211e74f8064bd5b62f&from=industrynews&version=4.1.3.6112&platform=win#rd

、Redis為什么變慢了

1.Redis真的變慢了嗎？

對 Redis 進行基準性能測驗例如，我的機器配置比較低，當延遲為 2ms 時，我就認為 Redis 變慢了，但是如果你的硬體配置比較高，那么在你的運行環境下，可能延遲是 0.5ms 時就可以認為 Redis 變慢了，所以，你只有了解了你的 Redis 在生產環境服務器上的基準性能，才能進一步評估，當其延遲達到什么程度時，才認為 Redis 確實變慢了，為了避免業務服務器到 Redis 服務器之間的網路延遲，你需要直接在 Redis 服務器上測驗實體的回應延遲情況，執行以下命令，就可以測驗出這個實體 60 秒內的最大回應延遲：

./redis-cli --intrinsic-latency 120Max latency so far: 17 microseconds.Max latency so far: 44 microseconds.Max latency so far: 94 microseconds.Max latency so far: 110 microseconds.Max latency so far: 119 microseconds.
36481658 total runs (avg latency: 3.2893 microseconds / 3289.32 nanoseconds per run).Worst run took 36x longer than the average latency.

從輸出結果可以看到，這 60 秒內的最大回應延遲為 119 微秒（0.119毫秒），你還可以使用以下命令，查看一段時間內 Redis 的最小、最大、平均訪問延遲

$ redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1min: 0, max: 1, avg: 0.13 (100 samples) -- 1.01 seconds rangemin: 0, max: 1, avg: 0.12 (99 samples) -- 1.01 seconds rangemin: 0, max: 1, avg: 0.13 (99 samples) -- 1.01 seconds rangemin: 0, max: 1, avg: 0.10 (99 samples) -- 1.01 seconds rangemin: 0, max: 1, avg: 0.13 (98 samples) -- 1.00 seconds rangemin: 0, max: 1, avg: 0.08 (99 samples) -- 1.01 seconds range

如果你觀察到的 Redis 運行時延遲是其基線性能的 2 倍及以上，就可以認定 Redis 變慢了，

網路對 Redis 性能的影響，一個簡單的方法是用 iPerf 這樣的工具測驗網路極限帶寬，

服務器端
# iperf -s -p 12345 -i 1 -Miperf: option requires an argument -- M------------------------------------------------------------Server listening on TCP port 12345TCP window size: 4.00 MByte (default)------------------------------------------------------------[  4] local 172.20.0.113 port 12345 connected with 172.20.0.114 port 56796[ ID] Interval       Transfer     Bandwidth[  4]  0.0- 1.0 sec   614 MBytes  5.15 Gbits/sec[  4]  1.0- 2.0 sec   622 MBytes  5.21 Gbits/sec[  4]  2.0- 3.0 sec   647 MBytes  5.42 Gbits/sec[  4]  3.0- 4.0 sec   644 MBytes  5.40 Gbits/sec[  4]  4.0- 5.0 sec   651 MBytes  5.46 Gbits/sec[  4]  5.0- 6.0 sec   652 MBytes  5.47 Gbits/sec[  4]  6.0- 7.0 sec   669 MBytes  5.61 Gbits/sec[  4]  7.0- 8.0 sec   670 MBytes  5.62 Gbits/sec[  4]  8.0- 9.0 sec   667 MBytes  5.59 Gbits/sec[  4]  9.0-10.0 sec   667 MBytes  5.60 Gbits/sec[  4]  0.0-10.0 sec  6.35 GBytes  5.45 Gbits/sec客戶端
# iperf -c 服務器端IP -p 12345 -i 1 -t 10 -w 20K------------------------------------------------------------Client connecting to 172.20.0.113, TCP port 12345TCP window size: 40.0 KByte (WARNING: requested 20.0 KByte)------------------------------------------------------------[  3] local 172.20.0.114 port 56796 connected with 172.20.0.113 port 12345[ ID] Interval       Transfer     Bandwidth[  3]  0.0- 1.0 sec   614 MBytes  5.15 Gbits/sec[  3]  1.0- 2.0 sec   622 MBytes  5.21 Gbits/sec[  3]  2.0- 3.0 sec   646 MBytes  5.42 Gbits/sec[  3]  3.0- 4.0 sec   644 MBytes  5.40 Gbits/sec[  3]  4.0- 5.0 sec   651 MBytes  5.46 Gbits/sec[  3]  5.0- 6.0 sec   652 MBytes  5.47 Gbits/sec[  3]  6.0- 7.0 sec   669 MBytes  5.61 Gbits/sec[  3]  7.0- 8.0 sec   670 MBytes  5.62 Gbits/sec[  3]  8.0- 9.0 sec   667 MBytes  5.59 Gbits/sec[  3]  9.0-10.0 sec   668 MBytes  5.60 Gbits/sec[  3]  0.0-10.0 sec  6.35 GBytes  5.45 Gbits/sec

2.使用復雜度過高的命令首先，第一步，你需要去查看一下 Redis 的慢日志（slowlog），Redis 提供了慢日志命令的統計功能，它記錄了有哪些命令在執行時耗時比較久，查看 Redis 慢日志之前，你需要設定慢日志的閾值，例如，設定慢日志的閾值為 5 毫秒，并且保留最近 500 條慢日志記錄：

# 命令執行耗時超過 5 毫秒，記錄慢日志CONFIG SET slowlog-log-slower-than 5000# 只保留最近 500 條慢日志CONFIG SET slowlog-max-len 500

1.經常使用 O(N) 以上復雜度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合類命令2.使用 O(N) 復雜度的命令，但 N 的值非常大第一種情況導致變慢的原因在于，Redis 在操作記憶體資料時，時間復雜度過高，要花費更多的 CPU 資源，第二種情況導致變慢的原因在于，Redis 一次需要回傳給客戶端的資料過多，更多時間花費在資料協議的組裝和網路傳輸程序中，另外，我們還可以從資源使用率層面來分析，如果你的應用程式操作 Redis 的 OPS 不是很大，但 Redis 實體的 CPU 使用率卻很高，那么很有可能是使用了復雜度過高的命令導致的，

3.操作bigkey

如果你查詢慢日志發現，并不是復雜度過高的命令導致的，而都是 SET / DEL 這種簡單命令出現在慢日志中，那么你就要懷疑你的實體否寫入了 bigkey，

redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 1-------- 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 bytesBiggest   list found 'mylist:004' has 40 itemsBiggest    set found 'myset:2386' has 38 membersBiggest   hash found 'myhash:3574' has 37 fieldsBiggest   zset found 'myzset:2704' has 42 members36313 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)

這里我需要提醒你的是，當執行這個命令時，要注意 2 個問題：

1.對線上實體進行 bigkey 掃描時，Redis 的 OPS 會突增，為了降低掃描程序中對 Redis 的影響，最好控制一下掃描的頻率，指定 -i 引數即可，它表示掃描程序中每次掃描后休息的時間間隔，單位是秒2.掃描結果中，對于容器型別（List、Hash、Set、ZSet）的 key，只能掃描出元素最多的 key，但一個 key 的元素多，不一定表示占用記憶體也多，你還需要根據業務情況，進一步評估記憶體占用情況，

4.集中過期

如果你發現，平時在操作 Redis 時，并沒有延遲很大的情況發生，但在某個時間點突然出現一波延時，其現象表現為：變慢的時間點很有規律，例如某個整點，或者每間隔多久就會發生一波延遲，如果是出現這種情況，那么你需要排查一下，業務代碼中是否存在設定大量 key 集中過期的情況，如果有大量的 key 在某個固定時間點集中過期，在這個時間點訪問 Redis 時，就有可能導致延時變大，Redis 的過期資料采用被動過期 + 主動過期兩種策略：1.被動過期：只有當訪問某個 key 時，才判斷這個 key 是否已過期，如果已過期，則從實體中洗掉2.主動過期：Redis 內部維護了一個定時任務，默認每隔 100 毫秒（1秒10次）就會從全域的過期哈希表中隨機取出 20 個 key，然后洗掉其中過期的 key，如果過期 key 的比例超過了 25%，則繼續重復此程序，直到過期 key 的比例下降到 25% 以下，或者這次任務的執行耗時超過了 25 毫秒，才會退出回圈注意，這個主動過期 key 的定時任務，是在 Redis 主執行緒中執行的，也就是說如果在執行主動過期的程序中，出現了需要大量洗掉過期 key 的情況，那么此時應用程式在訪問 Redis 時，必須要等待這個過期任務執行結束，Redis 才可以服務這個客戶端請求，如果此時需要過期洗掉的是一個 bigkey，那么這個耗時會更久，而且，這個操作延遲的命令并不會記錄在慢日志中，因為慢日志中只記錄一個命令真正操作記憶體資料的耗時，而 Redis 主動洗掉過期 key 的邏輯，是在命令真正執行之前執行的，

5.實體記憶體達到上限

當我們把 Redis 當做純快取使用時，通常會給這個實體設定一個記憶體上限 maxmemory，然后設定一個資料淘汰策略，當 Redis 記憶體達到 maxmemory 后，每次寫入新的資料之前，Redis 必須先從實體中踢出一部分資料，讓整個實體的記憶體維持在 maxmemory 之下，然后才能把新資料寫進來，這個踢出舊資料的邏輯也是需要消耗時間的，而具體耗時的長短，要取決于你配置的淘汰策略：

• allkeys-lru：不管 key 是否設定了過期，淘汰最近最少訪問的 key
• volatile-lru：只淘汰最近最少訪問、并設定了過期時間的 key
• allkeys-random：不管 key 是否設定了過期，隨機淘汰 key
• volatile-random：只隨機淘汰設定了過期時間的 key
• allkeys-ttl：不管 key 是否設定了過期，淘汰即將過期的 key
• noeviction：不淘汰任何 key，實體記憶體達到 maxmeory 后，再寫入新資料直接回傳錯誤
• allkeys-lfu：不管 key 是否設定了過期，淘汰訪問頻率最低的 key（4.0+版本支持）
• volatile-lfu：只淘汰訪問頻率最低、并設定了過期時間 key（4.0+版本支持）

一般最常使用的是 allkeys-lru / volatile-lru 淘汰策略，它們的處理邏輯是，每次從實體中隨機取出一批 key（這個數量可配置），然后淘汰一個最少訪問的 key，之后把剩下的 key 暫存到一個池子中，繼續隨機取一批 key，并與之前池子中的 key 比較，再淘汰一個最少訪問的 key，以此往復，直到實體記憶體降到 maxmemory 之下，

需要注意的是，Redis 的淘汰資料的邏輯與洗掉過期 key 的一樣，也是在命令真正執行之前執行的，也就是說它也會增加我們操作 Redis 的延遲，而且，寫 OPS 越高，延遲也會越明顯，

如果此時你的 Redis 實體中還存盤了 bigkey，那么在淘汰洗掉 bigkey 釋放記憶體時，也會耗時比較久，

6.fork耗時嚴重

當 Redis 開啟了后臺 RDB 和 AOF rewrite 后，在執行時，它們都需要主行程創建出一個子行程進行資料的持久化，

主行程創建子行程，會呼叫作業系統提供的 fork 函式，

而 fork 在執行程序中，主行程需要拷貝自己的記憶體頁表給子行程，如果這個實體很大，那么這個拷貝的程序也會比較耗時，

而且這個 fork 程序會消耗大量的 CPU 資源，在完成 fork 之前，整個 Redis 實體會被阻塞住，無法處理任何客戶端請求，

如果此時你的 CPU 資源本來就很緊張，那么 fork 的耗時會更長，甚至達到秒級，這會嚴重影響 Redis 的性能，

那如何確認確實是因為 fork 耗時導致的 Redis 延遲變大呢？

你可以在 Redis 上執行 INFO 命令，查看 latest_fork_usec 項，單位微秒，

# 上一次 fork 耗時，單位微秒latest_fork_usec:59477

這個時間就是主行程在 fork 子行程期間，整個實體阻塞無法處理客戶端請求的時間，

如果你發現這個耗時很久，就要警惕起來了，這意味在這期間，你的整個 Redis 實體都處于不可用的狀態，

除了資料持久化會生成 RDB 之外，當主從節點第一次建立資料同步時，主節點也創建子行程生成 RDB，然后發給從節點進行一次全量同步，所以，這個程序也會對 Redis 產生性能影響，

7.開啟記憶體大頁

除了上面講到的子行程 RDB 和 AOF rewrite 期間，fork 耗時導致的延時變大之外，這里還有一個方面也會導致性能問題，這就是作業系統是否開啟了記憶體大頁機制，

什么是記憶體大頁？

我們都知道，應用程式向作業系統申請記憶體時，是按記憶體頁進行申請的，而常規的記憶體頁大小是 4KB，

Linux 內核從 2.6.38 開始，支持了記憶體大頁機制，該機制允許應用程式以 2MB 大小為單位，向作業系統申請記憶體，

應用程式每次向作業系統申請的記憶體單位變大了，但這也意味著申請記憶體的耗時變長，

這對 Redis 會有什么影響呢？

當 Redis 在執行后臺 RDB，采用 fork 子行程的方式來處理，但主行程 fork 子行程后，此時的主行程依舊是可以接收寫請求的，而進來的寫請求，會采用 Copy On Write（寫時復制）的方式操作記憶體資料，

也就是說，主行程一旦有資料需要修改，Redis 并不會直接修改現有記憶體中的資料，而是先將這塊記憶體資料拷貝出來，再修改這塊新記憶體的資料，這就是所謂的「寫時復制」，

寫時復制你也可以理解成，誰需要發生寫操作，誰就需要先拷貝，再修改，

這樣做的好處是，父行程有任何寫操作，并不會影響子行程的資料持久化（子行程只持久化 fork 這一瞬間整個實體中的所有資料即可，不關心新的資料變更，因為子行程只需要一份記憶體快照，然后持久化到磁盤上），

但是請注意，主行程在拷貝記憶體資料時，這個階段就涉及到新記憶體的申請，如果此時作業系統開啟了記憶體大頁，那么在此期間，客戶端即便只修改 10B 的資料，Redis 在申請記憶體時也會以 2MB 為單位向作業系統申請，申請記憶體的耗時變長，進而導致每個寫請求的延遲增加，影響到 Redis 性能，

同樣地，如果這個寫請求操作的是一個 bigkey，那主行程在拷貝這個 bigkey 記憶體塊時，一次申請的記憶體會更大，時間也會更久，可見，bigkey 在這里又一次影響到了性能，

8.開啟AOF

前面我們分析了 RDB 和 AOF rewrite 對 Redis 性能的影響，主要關注點在 fork 上，

其實，關于資料持久化方面，還有影響 Redis 性能的因素，這次我們重點來看 AOF 資料持久化，

如果你的 AOF 配置不合理，還是有可能會導致性能問題，

當 Redis 開啟 AOF 后，其作業原理如下：

1.Redis 執行寫命令后，把這個命令寫入到 AOF 檔案記憶體中（write 系統呼叫）

2.Redis 根據配置的 AOF 刷盤策略，把 AOF 記憶體資料刷到磁盤上（fsync 系統呼叫）

為了保證 AOF 檔案資料的安全性，Redis 提供了 3 種刷盤機制：

1.appendfsync always：主執行緒每次執行寫操作后立即刷盤，此方案會占用比較大的磁盤 IO 資源，但資料安全性最高

2.appendfsync no：主執行緒每次寫操作只寫記憶體就回傳，記憶體資料什么時候刷到磁盤，交由作業系統決定，此方案對性能影響最小，但資料安全性也最低，Redis 宕機時丟失的資料取決于作業系統刷盤時機

3.appendfsync everysec：主執行緒每次寫操作只寫記憶體就回傳，然后由后臺執行緒每隔 1 秒執行一次刷盤操作（觸發fsync系統呼叫），此方案對性能影響相對較小，但當 Redis 宕機時會丟失 1 秒的資料

看到這里，我猜你肯定和大多數人的想法一樣，選比較折中的方案 appendfsync everysec 就沒問題了吧？

這個方案優勢在于，Redis 主執行緒寫完記憶體后就回傳，具體的刷盤操作是放到后臺執行緒中執行的，后臺執行緒每隔 1 秒把記憶體中的資料刷到磁盤中，

這種方案既兼顧了性能，又盡可能地保證了資料安全，是不是覺得很完美？

但是，這里我要給你潑一盆冷水了，采用這種方案你也要警惕一下，因為這種方案還是存在導致 Redis 延遲變大的情況發生，甚至會阻塞整個 Redis，

你試想這樣一種情況：當 Redis 后臺執行緒在執行 AOF 檔案刷盤時，如果此時磁盤的 IO 負載很高，那這個后臺執行緒在執行刷盤操作（fsync系統呼叫）時就會被阻塞住，

此時的主執行緒依舊會接收寫請求，緊接著，主執行緒又需要把資料寫到檔案記憶體中（write 系統呼叫），當主執行緒使用后臺子執行緒執行了一次 fsync，需要再次把新接收的操作記錄寫回磁盤時，如果主執行緒發現上一次的 fsync 還沒有執行完，那么它就會阻塞，所以，如果后臺子執行緒執行的 fsync 頻繁阻塞的話（比如 AOF 重寫占用了大量的磁盤 IO 帶寬），主執行緒也會阻塞，導致 Redis 性能變慢，

看到了么？在這個程序中，主執行緒依舊有阻塞的風險，

所以，盡管你的 AOF 配置為 appendfsync everysec，也不能掉以輕心，要警惕磁盤壓力過大導致的 Redis 有性能問題，

那什么情況下會導致磁盤 IO 負載過大？以及如何解決這個問題呢？

我總結了以下幾種情況，你可以參考進行問題排查：

1.子行程正在執行 AOF rewrite，這個程序會占用大量的磁盤 IO 資源

2.有其他應用程式在執行大量的寫檔案操作，也會占用磁盤 IO 資源

對于情況1，說白了就是，Redis 的 AOF 后臺子執行緒刷盤操作，撞上了子行程 AOF rewrite！

9.系結CPU

很多時候，我們在部署服務時，為了提高服務性能，降低應用程式在多個 CPU 核心之間的背景關系切換帶來的性能損耗，通常采用的方案是行程系結 CPU 的方式提高性能，

我們都知道，一般現代的服務器會有多個 CPU，而每個 CPU 又包含多個物理核心，每個物理核心又分為多個邏輯核心，每個物理核下的邏輯核共用 L1/L2 Cache，

而 Redis Server 除了主執行緒服務客戶端請求之外，還會創建子行程、子執行緒，

其中子行程用于資料持久化，而子執行緒用于執行一些比較耗時操作，例如異步釋放 fd、異步 AOF 刷盤、異步 lazy-free 等等，

如果你把 Redis 行程只系結了一個 CPU 邏輯核心上，那么當 Redis 在進行資料持久化時，fork 出的子行程會繼承父行程的 CPU 使用偏好，

而此時的子行程會消耗大量的 CPU 資源進行資料持久化（把實體資料全部掃描出來需要耗費CPU），這就會導致子行程會與主行程發生 CPU 爭搶，進而影響到主行程服務客戶端請求，訪問延遲變大，

這就是 Redis 系結 CPU 帶來的性能問題，

10.使用Swap

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

什么是 Swap？為什么使用 Swap 會導致 Redis 的性能下降？

如果你對作業系統有些了解，就會知道作業系統為了緩解記憶體不足對應用程式的影響，允許把一部分記憶體中的資料換到磁盤上，以達到應用程式對記憶體使用的緩沖，這些記憶體資料被換到磁盤上的區域，就是 Swap，

問題就在于，當記憶體中的資料被換到磁盤上后，Redis 再訪問這些資料時，就需要從磁盤上讀取，訪問磁盤的速度要比訪問記憶體慢幾百倍！

尤其是針對 Redis 這種對性能要求極高、性能極其敏感的資料庫來說，這個操作延時是無法接受的，

此時，你需要檢查 Redis 機器的記憶體使用情況，確認是否存在使用了 Swap，

你可以通過以下方式來查看 Redis 行程是否使用到了 Swap：

# 先找到 Redis 的行程 ID$ ps -aux | grep redis-server# 查看 Redis Swap 使用情況$ cat /proc/$pid/smaps | egrep '^(Swap|Size)'

輸出結果如下：

Size:               1256 kBSwap:                  0 kBSize:                  4 kBSwap:                  0 kBSize:                132 kBSwap:                  0 kBSize:              63488 kBSwap:                  0 kBSize:                132 kBSwap:                  0 kBSize:              65404 kBSwap:                  0 kBSize:            1921024 kBSwap:                  0 kB

每一行 Size 表示 Redis 所用的一塊記憶體大小，Size 下面的 Swap 就表示這塊 Size 大小的記憶體，有多少資料已經被換到磁盤上了，如果這兩個值相等，說明這塊記憶體的資料都已經完全被換到磁盤上了，

如果只是少量資料被換到磁盤上，例如每一塊 Swap 占對應 Size 的比例很小，那影響并不是很大，如果是幾百兆甚至上 GB 的記憶體被換到了磁盤上，那么你就需要警惕了，這種情況 Redis 的性能肯定會急劇下降，

11.碎片整理

Redis 的資料都存盤在記憶體中，當我們的應用程式頻繁修改 Redis 中的資料時，就有可能會導致 Redis 產生記憶體碎片，

記憶體碎片會降低 Redis 的記憶體使用率，我們可以通過執行 INFO 命令，得到這個實體的記憶體碎片率：

# Memoryused_memory:5709194824used_memory_human:5.32Gused_memory_rss:8264855552used_memory_rss_human:7.70G...mem_fragmentation_ratio:1.45

這個記憶體碎片率是怎么計算的？

很簡單，mem_fragmentation_ratio = used_memory_rss / used_memory，

其中 used_memory 表示 Redis 存盤資料的記憶體大小，而 used_memory_rss 表示作業系統實際分配給 Redis 行程的大小，

如果 mem_fragmentation_ratio > 1.5，說明記憶體碎片率已經超過了 50%，這時我們就需要采取一些措施來降低記憶體碎片了，

解決的方案一般如下：

1.如果你使用的是 Redis 4.0 以下版本，只能通過重啟實體來解決

2.如果你使用的是 Redis 4.0 版本，它正好提供了自動碎片整理的功能，可以通過配置開啟碎片自動整理，

但是，開啟記憶體碎片整理，它也有可能會導致 Redis 性能下降，

原因在于，Redis 的碎片整理作業是也在主執行緒中執行的，當其進行碎片整理時，必然會消耗 CPU 資源，產生更多的耗時，從而影響到客戶端的請求，

所以，當你需要開啟這個功能時，最好提前測驗評估它對 Redis 的影響，

Redis 碎片整理的引數配置如下：

# 開啟自動記憶體碎片整理（總開關）activedefrag yes
# 記憶體使用 100MB 以下，不進行碎片整理active-defrag-ignore-bytes 100mb
# 記憶體碎片率超過 10%，開始碎片整理active-defrag-threshold-lower 10# 記憶體碎片率超過 100%，盡最大努力碎片整理active-defrag-threshold-upper 100
# 記憶體碎片整理占用 CPU 資源最小百分比active-defrag-cycle-min 1# 記憶體碎片整理占用 CPU 資源最大百分比active-defrag-cycle-max 25
# 碎片整理期間，對于 List/Set/Hash/ZSet 型別元素一次 Scan 的數量active-defrag-max-scan-fields 1000

二、Redis如何優化

1.慢查詢優化

1.盡量不使用 O(N) 以上復雜度過高的命令，對于資料的聚合操作，放在客戶端做

2.執行 O(N) 命令，保證 N 盡量的小（推薦 N <= 300），每次獲取盡量少的資料，讓 Redis 可以及時處理回傳

2.集中過期優化

一般有兩種方案來規避這個問題：

1.集中過期 key 增加一個隨機過期時間，把集中過期的時間打散，降低 Redis 清理過期 key 的壓力

2.如果你使用的 Redis 是 4.0 以上版本，可以開啟 lazy-free 機制，當洗掉過期 key 時，把釋放記憶體的操作放到后臺執行緒中執行，避免阻塞主執行緒，

第一種方案，在設定 key 的過期時間時，增加一個隨機時間，偽代碼可以這么寫：

# 在過期時間點之后的 5 分鐘內隨機過期掉redis.expireat(key, expire_time + random(300))

第二種方案，Redis 4.0 以上版本，開啟 lazy-free 機制：

# 釋放過期 key 的記憶體，放到后臺執行緒執行lazyfree-lazy-expire yes

運維層面，你需要把 Redis 的各項運行狀態資料監控起來，在 Redis 上執行 INFO 命令就可以拿到這個實體所有的運行狀態資料，

在這里我們需要重點關注 expired_keys 這一項，它代表整個實體到目前為止，累計洗掉過期 key 的數量，

你需要把這個指標監控起來，當這個指標在很短時間內出現了突增，需要及時報警出來，然后與業務應用報慢的時間點進行對比分析，確認時間是否一致，如果一致，則可以確認確實是因為集中過期 key 導致的延遲變大，

3.實體記憶體達到上限優化

1.避免存盤 bigkey，降低釋放記憶體的耗時

2.淘汰策略改為隨機淘汰，隨機淘汰比 LRU 要快很多（視業務情況調整）

3.拆分實體，把淘汰 key 的壓力分攤到多個實體上

4.如果使用的是 Redis 4.0 以上版本，開啟 layz-free 機制，把淘汰 key 釋放記憶體的操作放到后臺執行緒中執行（配置 lazyfree-lazy-eviction = yes）

4.fork耗時嚴重優化

1.控制 Redis 實體的記憶體：盡量在 10G 以下，執行 fork 的耗時與實體大小有關，實體越大，耗時越久，

2.合理配置資料持久化策略：在 slave 節點執行 RDB 備份，推薦在低峰期執行，而對于丟失資料不敏感的業務（例如把 Redis 當做純快取使用），可以關閉 AOF 和 AOF rewrite，

3.Redis 實體不要部署在虛擬機上：fork 的耗時也與系統也有關，虛擬機比物理機耗時更久，

4.降低主從庫全量同步的概率：適當調大 repl-backlog-size 引數，避免主從全量同步，

從建立同步時，優先檢測是否可以嘗試只同步部分資料，這種情況就是針對于之前已經建立好了復制鏈路，只是因為故障導致臨時斷開，故障恢復后重新建立同步時，為了避免全量同步的資源消耗，Redis會優先嘗試部分資料同步，如果條件不符合，才會觸發全量同步，這個判斷依據就是在master上維護的復制緩沖區大小，如果這個緩沖區配置的過小，很有可能在主從斷開復制的這段時間內，master產生的寫入導致復制緩沖區的資料被覆寫，重新建立同步時的slave需要同步的offset位置在master的緩沖區中找不到，那么此時就會觸發全量同步，如何避免這種情況？解決方案就是適當調大復制緩沖區repl-backlog-size的大小，這個緩沖區的大小默認為1MB，如果實體寫入量比較大，可以針對性調大此配置，

5.多核CPU優化

那如何解決這個問題呢？

如果你確實想要系結 CPU，可以優化的方案是，不要讓 Redis 行程只系結在一個 CPU 邏輯核上，而是系結在多個邏輯核心上，而且，系結的多個邏輯核心最好是同一個物理核心，這樣它們還可以共用 L1/L2 Cache，

當然，即便我們把 Redis 系結在多個邏輯核心上，也只能在一定程度上緩解主執行緒、子行程、后臺執行緒在 CPU 資源上的競爭，

因為這些子行程、子執行緒還是會在這多個邏輯核心上進行切換，存在性能損耗，

如何再進一步優化？

可能你已經想到了，我們是否可以讓主執行緒、子行程、后臺執行緒，分別系結在固定的 CPU 核心上，不讓它們來回切換，這樣一來，他們各自使用的 CPU 資源互不影響，

其實，這個方案 Redis 官方已經想到了，

Redis 在 6.0 版本已經推出了這個功能，我們可以通過以下配置，對主執行緒、后臺執行緒、后臺 RDB 行程、AOF rewrite 行程，系結固定的 CPU 邏輯核心：

Redis6.0 前系結CPU核

taskset -c 0 ./redis-server

Redis6.0 后系結CPU核

# Redis Server 和 IO 執行緒系結到 CPU核心 0,2,4,6server_cpulist 0-7:2# 后臺子執行緒系結到 CPU核心 1,3bio_cpulist 1,3# 后臺 AOF rewrite 行程系結到 CPU 核心 8,9,10,11aof_rewrite_cpulist 8-11# 后臺 RDB 行程系結到 CPU 核心 1,10,11# bgsave_cpulist 1,10-1

如果你使用的正好是 Redis 6.0 版本，就可以通過以上配置，來進一步提高 Redis 性能，

這里我需要提醒你的是，一般來說，Redis 的性能已經足夠優秀，除非你對 Redis 的性能有更加嚴苛的要求，否則不建議你系結 CPU，

6.查看Redis記憶體是否發生Swap

$ redis-cli info | grep process_idprocess_id: 5332

然后，進入 Redis 所在機器的 /proc 目錄下的該行程目錄中：

$ cd /proc/5332

最后，運行下面的命令，查看該 Redis 行程的使用情況，在這兒，我只截取了部分結果：

$cat smaps | egrep '^(Swap|Size)'Size: 584 kBSwap: 0 kBSize: 4 kBSwap: 4 kBSize: 4 kBSwap: 0 kBSize: 462044 kBSwap: 462008 kBSize: 21392 kBSwap: 0 kB

一旦發生記憶體 swap，最直接的解決方法就是增加機器記憶體，如果該實體在一個 Redis 切片集群中，可以增加 Redis 集群的實體個數，來分攤每個實體服務的資料量，進而減少每個實體所需的記憶體量，

7.記憶體大頁

如果采用了記憶體大頁，那么，即使客戶端請求只修改 100B 的資料，Redis 也需要拷貝 2MB 的大頁，相反，如果是常規記憶體頁機制，只用拷貝 4KB，兩者相比，你可以看到，當客戶端請求修改或新寫入資料較多時，記憶體大頁機制將導致大量的拷貝，這就會影響 Redis 正常的訪存操作，最終導致性能變慢，

首先，我們要先排查下記憶體大頁，方法是：在 Redis 實體運行的機器上執行如下命令:

$ cat /sys/kernel/mm/transparent_hugepage/enabled[always] madvise never

如果執行結果是 always，就表明記憶體大頁機制被啟動了；如果是 never，就表示，記憶體大頁機制被禁止，

在實際生產環境中部署時，我建議你不要使用記憶體大頁機制，操作也很簡單，只需要執行下面的命令就可以了：

echo never /sys/kernel/mm/transparent_hugepage/enabled

其實，作業系統提供的記憶體大頁機制，其優勢是，可以在一定程式上降低應用程式申請記憶體的次數，

但是對于 Redis 這種對性能和延遲極其敏感的資料庫來說，我們希望 Redis 在每次申請記憶體時，耗時盡量短，所以我不建議你在 Redis 機器上開啟這個機制，

8.洗掉使用Lazy Free

支持版本：Redis 4.0+

8.1 主動洗掉鍵使用lazy free

UNLINK命令

127.0.0.1:7000> LLEN mylist(integer) 2000000127.0.0.1:7000> UNLINK mylist(integer) 1127.0.0.1:7000> SLOWLOG get1) 1) (integer) 1   2) (integer) 1505465188   3) (integer) 30   4) 1) "UNLINK"      2) "mylist"   5) "127.0.0.1:17015"   6) ""

注意：DEL命令，還是并發阻塞的洗掉操作

FLUSHALL/FLUSHDB ASYNC

127.0.0.1:7000> DBSIZE(integer) 1812295127.0.0.1:7000> flushall  //同步清理實體資料，180萬個key耗時1020毫秒OK(1.02s)127.0.0.1:7000> DBSIZE(integer) 1812637127.0.0.1:7000> flushall async  //異步清理實體資料，180萬個key耗時約9毫秒OK127.0.0.1:7000> SLOWLOG get 1) 1) (integer) 2996109    2) (integer) 1505465989    3) (integer) 9274       //指令運行耗時9.2毫秒    4) 1) "flushall"       2) "async"    5) "127.0.0.1:20110"    6) ""

8.2 被動洗掉鍵使用lazy free

lazy free應用于被動洗掉中，目前有4種場景，每種場景對應一個配置引數；默認都是關閉，

lazyfree-lazy-eviction nolazyfree-lazy-expire nolazyfree-lazy-server-del noslave-lazy-flush no

lazyfree-lazy-eviction

針對redis記憶體使用達到maxmeory，并設定有淘汰策略時；在被動淘汰鍵時，是否采用lazy free機制；因為此場景開啟lazy free, 可能使用淘汰鍵的記憶體釋放不及時，導致redis記憶體超用，超過maxmemory的限制，此場景使用時，請結合業務測驗，（生產環境不建議設定yes）

lazyfree-lazy-expire

針對設定有TTL的鍵，達到過期后，被redis清理洗掉時是否采用lazy free機制；此場景建議開啟，因TTL本身是自適應調整的速度，

lazyfree-lazy-server-del

針對有些指令在處理已存在的鍵時，會帶有一個隱式的DEL鍵的操作，如rename命令，當目標鍵已存在,redis會先洗掉目標鍵，如果這些目標鍵是一個big key,那就會引入阻塞洗掉的性能問題，此引數設定就是解決這類問題，建議可開啟，

slave-lazy-flush

針對slave進行全量資料同步，slave在加載master的RDB檔案前，會運行flushall來清理自己的資料場景， 引數設定決定是否采用例外flush機制，如果記憶體變動不大，建議可開啟，可減少全量同步耗時，從而減少主庫因輸出緩沖區爆漲引起的記憶體使用增長，

8.3 lazy free的監控

lazy free能監控的資料指標，只有一個值：lazyfree_pending_objects，表示redis執行lazy free操作，在等待被實際回收內容的鍵個數，并不能體現單個大鍵的元素個數或等待lazy free回收的記憶體大小，所以此值有一定參考值，可監測redis lazy free的效率或堆積鍵數量；比如在flushall async場景下會有少量的堆積，

# info memory
# Memorylazyfree_pending_objects:0

注意事項：unlink命令入口函式unlinkCommand()和del呼叫相同函式delGenericCommand()進行洗掉KEY操作，使用lazy標識是否為lazyfree呼叫，如果是lazyfree,則呼叫dbAsyncDelete()函式，但并非每次unlink命令就一定啟用lazy free，redis會先判斷釋放KEY的代價(cost),當cost大于LAZYFREE_THRESHOLD（64）才進行lazy free.釋放key代價計算函式lazyfreeGetFreeEffort()，集合型別鍵，且滿足對應編碼，cost就是集合鍵的元數個數，否則cost就是1. 舉例：1 一個包含100元素的list key, 它的free cost就是100 2 一個512MB的string key, 它的free cost是1 所以可以看出，redis的lazy free的cost計算主要時間復雜度相關，

9.AOF優化

Redis 提供了一個配置項，當子行程在 AOF rewrite 期間，可以讓后臺子執行緒不執行刷盤（不觸發 fsync 系統呼叫）操作，

這相當于在 AOF rewrite 期間，臨時把 appendfsync 設定為了 none，配置如下：

# AOF rewrite 期間，AOF 后臺子執行緒不進行刷盤操作# 相當于在這期間，臨時把 appendfsync 設定為了 noneno-appendfsync-on-rewrite yes

當然，開啟這個配置項，在 AOF rewrite 期間，如果實體發生宕機，那么此時會丟失更多的資料，性能和資料安全性，你需要權衡后進行選擇，

如果占用磁盤資源的是其他應用程式，那就比較簡單了，你需要定位到是哪個應用程式在大量寫磁盤，然后把這個應用程式遷移到其他機器上執行就好了，避免對 Redis 產生影響，

當然，如果你對 Redis 的性能和資料安全都有很高的要求，那么建議從硬體層面來優化，更換為 SSD 磁盤，提高磁盤的 IO 能力，保證 AOF 期間有充足的磁盤資源可以使用，同時盡可能讓Redis運行在獨立的機器上，

10.Swap優化

1.增加機器的記憶體，讓 Redis 有足夠的記憶體可以使用

2.整理記憶體空間，釋放出足夠的記憶體供 Redis 使用，然后釋放 Redis 的 Swap，讓 Redis 重新使用記憶體

釋放 Redis 的 Swap 程序通常要重啟實體，為了避免重啟實體對業務的影響，一般會先進行主從切換，然后釋放舊主節點的 Swap，重啟舊主節點實體，待從庫資料同步完成后，再進行主從切換即可，

預防的辦法就是，你需要對 Redis 機器的記憶體和 Swap 使用情況進行監控，在記憶體不足或使用到 Swap 時報警出來，及時處理，

三、Redis變慢了排查步驟

1、獲取 Redis 實體在當前環境下的基線性能，

2、是否用了慢查詢命令？如果是的話，就使用其他命令替代慢查詢命令，或者把聚合計算命令放在客戶端做，

3、是否對過期 key 設定了相同的過期時間？對于批量洗掉的 key，可以在每個 key 的過期時間上加一個亂數，避免同時洗掉，

4、是否存在 bigkey？對于 bigkey 的洗掉操作，如果你的 Redis 是 4.0 及以上的版本，可以直接利用異步執行緒機制減少主執行緒阻塞；如果是 Redis 4.0 以前的版本，可以使用 SCAN 命令迭代洗掉；對于 bigkey 的集合查詢和聚合操作，可以使用 SCAN 命令在客戶端完成，

5、Redis AOF 配置級別是什么？業務層面是否的確需要這一可靠性級別？如果我們需要高性能，同時也允許資料丟失，可以將配置項 no-appendfsync-on-rewrite 設定為 yes，避免 AOF 重寫和 fsync 競爭磁盤 IO 資源，導致 Redis 延遲增加，當然， 如果既需要高性能又需要高可靠性，最好使用高速固態盤作為 AOF 日志的寫入盤，

6、Redis 實體的記憶體使用是否過大？發生 swap 了嗎？如果是的話，就增加機器記憶體，或者是使用 Redis 集群，分攤單機 Redis 的鍵值對數量和記憶體壓力，同時，要避免出現 Redis 和其他記憶體需求大的應用共享機器的情況，

7、在 Redis 實體的運行環境中，是否啟用了透明大頁機制？如果是的話，直接關閉記憶體大頁機制就行了，

8、是否運行了 Redis 主從集群？如果是的話，把主庫實體的資料量大小控制在 2~4GB，以免主從復制時，從庫因加載大的 RDB 檔案而阻塞，

9、是否使用了多核 CPU 或 NUMA 架構的機器運行 Redis 實體？使用多核 CPU 時，可以給 Redis 實體系結物理核；使用 NUMA 架構時，注意把 Redis 實體和網路中斷處理程式運行在同一個 CPU Socket 上，

標籤：其他

上一篇：SpringBoot SpringSecurity 介紹（基于記憶體的驗證）

下一篇：返回列表