簡介說明
Redis速度是很快的，性能很高。但是，Redis有時候會存在執行很慢、性能很差的情況。本文介紹Redis為什么會變慢、解決方案。
Redis執行命令流程
Redis是單線程操作,如果在Redis中執行耗時較長的操作,就會阻塞其他請求了。
Redis客戶端執行一條命令，分為4部分：發送命令=>命令排隊=> 命令執行=> 返回結果
慢查詢在第三步，統計第三步執行時間。
排查步驟
第一步：確定Redis是否真的變慢了
排查思路
若發現你的業務服務 API 響應延遲變長，首先需要排查服務內部，究竟是哪個環節拖慢了整個服務。比較高效的做法是，在服務內部集成鏈路追蹤，也就是在服務訪問外部依賴的出入口，記錄下每次請求外部依賴的響應延時。若發現確實是操作 Redis 的這條鏈路耗時變長了，那么此刻你需要把焦點關注在業務服務到 Redis 這條鏈路上。
從你的業務服務到 Redis 這條鏈路變慢的原因可能也有 2 個：
1 業務服務器到 Redis 服務器之間的網絡存在問題，例如網絡線路質量不佳，網絡數據包在傳輸時存在延遲、丟包等情況
2 Redis 本身存在問題，需要進一步排查是什么原因導致 Redis 變慢
本文重點關注的是第二種情況。如何確認你的 Redis 是否真的變慢了？
基准性能
首先，你需要對 Redis 進行基准性能測試，了解你的 Redis 在生產環境服務器上的基准性能。基准性能就是指 Redis 在一台負載正常的機器上，其最大的響應延遲和平均響應延遲分別是怎樣的。
為什么要測試基准性能？我參考別人提供的響應延遲，判斷自己的 Redis 是否變慢不行嗎？答案是否定的。因為 Redis 在不同的軟硬件環境下，它的性能是各不相同的。例如，我的機器配置比較低，當延遲為 2ms 時，我就認為 Redis 變慢了，但是如果你的硬件配置比較高，那么在你的運行環境下，可能延遲是 0.5ms 時就可以認為 Redis 變慢了。
所以，你只有了解了你的 Redis 在生產環境服務器上的基准性能，才能進一步評估，當其延遲達到什么程度時，才認為 Redis 確實變慢了。
具體如何做？
為了避免業務服務器到 Redis 服務器之間的網絡延遲，你需要直接在 Redis 服務器上測試實例的響應延遲情況。執行以下命令，就可以測試出這個實例 60 秒內的最大響應延遲：
$ redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60 Max latency so far: 1 microseconds. Max latency so far: 15 microseconds. Max latency so far: 17 microseconds. Max latency so far: 18 microseconds. Max latency so far: 31 microseconds. Max latency so far: 32 microseconds. Max latency so far: 59 microseconds. Max latency so far: 72 microseconds. 1428669267 total runs (avg latency: 0.0420 microseconds / 42.00 nanoseconds per run). Worst run took 1429x longer than the average latency.
從輸出結果可以看到，這 60 秒內的最大響應延遲為 72 微秒（0.072毫秒）。你還可以使用以下命令，查看一段時間內 Redis 的最小、最大、平均訪問延遲：
$ redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1 min: 0, max: 1, avg: 0.13 (100 samples) -- 1.01 seconds range min: 0, max: 1, avg: 0.12 (99 samples) -- 1.01 seconds range min: 0, max: 1, avg: 0.13 (99 samples) -- 1.01 seconds range min: 0, max: 1, avg: 0.10 (99 samples) -- 1.01 seconds range min: 0, max: 1, avg: 0.13 (98 samples) -- 1.00 seconds range min: 0, max: 1, avg: 0.08 (99 samples) -- 1.01 seconds range ...
以上輸出結果是，每間隔 1 秒，采樣 Redis 的平均操作耗時，其結果分布在 0.08 ~ 0.13 毫秒之間。了解了基准性能測試方法，那么你就可以按照以下幾步，來判斷你的 Redis 是否真的變慢了：
在相同配置的服務器上，測試一個正常 Redis 實例的基准性能
找到你認為可能變慢的 Redis 實例，測試這個實例的基准性能
如果你觀察到，這個實例的運行延遲是正常 Redis 基准性能的 2 倍以上，即可認為這個 Redis 實例確實變慢了
第二步：查看slowlog（慢日志）
Redis 提供了慢日志命令的統計功能，它記錄了有哪些命令在執行時耗時比較久。
查看 Redis 慢日志之前，你需要設置慢日志的閾值。例如，設置慢日志的閾值為 5 毫秒，並且保留最近 500 條慢日志記錄：
# 命令執行耗時超過 5 毫秒，記錄慢日志 CONFIG SET slowlog-log-slower-than 5000 # 只保留最近 500 條慢日志 CONFIG SET slowlog-max-len 500
設置完成之后，所有執行的命令如果操作耗時超過了 5 毫秒，都會被 Redis 記錄下來。此時，你可以執行以下命令，就可以查詢到最近記錄的慢日志：
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" ...
通過查看慢日志，我們就可以知道在什么時間點，執行了哪些命令比較耗時。
Redis變慢原因（Redis相關）
原因1：使用復雜度過高的命令
排查思路
查看慢日志，看是否有復雜度過高的命令。
導致變慢的操作
經常使用 O(N) 以上復雜度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合類命令
原因：Redis 在操作內存數據時，時間復雜度過高，要花費更多的 CPU 資源
使用 O(N) 復雜度的命令，但 N 的值非常大
原因：Redis 一次需要返回給客戶端的數據過多，更多時間花費在數據協議的組裝和網絡傳輸過程中
另外，我們還可以從資源使用率層面來分析，如果你的應用程序操作 Redis 的 OPS 不是很大，但 Redis 實例的 CPU 使用率卻很高，那么很有可能是使用了復雜度過高的命令導致的。
除此之外，Redis 是單線程處理客戶端請求的，如果你經常使用以上命令，那么當 Redis 處理客戶端請求時，一旦前面某個命令發生耗時，就會導致后面的請求發生排隊，對於客戶端來說，響應延遲也會變長。
解決方案
盡量不使用 O(N) 以上復雜度過高的命令，對於數據的聚合操作，放在客戶端做
執行 O(N) 命令，保證 N 盡量的小（推薦 N <= 300），每次獲取盡量少的數據，讓 Redis 可以及時處理返回
原因2：操作bigkey（value很大）
排查思路
若你查詢慢日志發現，並不是復雜度過高的命令導致的，而都是 SET / DEL 這種簡單命令出現在慢日志中，那么你就要懷疑你的實例否寫入了 bigkey。
導致變慢的操作
Redis 在寫入數據時，需要為新的數據分配內存，相對應的，當從 Redis 中刪除數據時，它會釋放對應的內存空間。如果一個 key 寫入的 value 非常大，那么 Redis 在分配內存時就會比較耗時。同樣的，當刪除這個 key 時，釋放內存也會比較耗時，這種類型的 key 我們一般稱之為 bigkey。此時，需要檢查業務代碼是否存在寫入 bigkey 的情況。你需要評估寫入一個 key 的數據大小，盡量避免一個 key 存入過大的數據。
找出bigkey
若已經寫入了 bigkey，可以掃描出實例中 bigkey 的分布情況嗎？
答案是可以的。Redis 提供了掃描 bigkey 的命令，執行以下命令就可以掃描出，一個實例中 bigkey 的分布情況，輸出結果是以類型維度展示的：
$ redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.01 ... -------- 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)
輸出結果我們可以很清晰地看到，每種數據類型所占用的最大內存 / 擁有最多元素的 key 是哪一個，以及每種數據類型在整個實例中的占比和平均大小 / 元素數量。
其實，使用這個命令的原理，就是 Redis 在內部執行了 SCAN 命令，遍歷整個實例中所有的 key，然后針對 key 的類型，分別執行 STRLEN、LLEN、HLEN、SCARD、ZCARD 命令，來獲取 String 類型的長度、容器類型（List、Hash、Set、ZSet）的元素個數。
執行這個命令時，要注意 2 個問題：
1 對線上實例進行 bigkey 掃描時，Redis 的 OPS 會突增，為了降低掃描過程中對 Redis 的影響，最好控制一下掃描的頻率，指定 -i 參數即可，它表示掃描過程中每次掃描后休息的時間間隔，單位是秒
2 掃描結果中，對於容器類型（List、Hash、Set、ZSet）的 key，只能掃描出元素最多的 key。但一個 key 的元素多，不一定表示占用內存也多，你還需要根據業務情況，進一步評估內存占用情況
針對 bigkey 導致延遲的解決方案
1 業務應用盡量避免寫入 bigkey
2 將釋放key的操作放到后台線程執行
Redis4.0 以上版本：用 UNLINK 命令替代 DEL，此命令可以把釋放 key 內存的操作，放到后台線程中去執行，從而降低對 Redis 的影響
Redis6.0 以上版本：可以開啟 lazy-free 機制（lazyfree-lazy-user-del = yes），在執行 DEL 命令時，釋放內存也會放到后台線程中執行
但即便可以使用方案 2，我也不建議你在實例中存入 bigkey。這是因為 bigkey 在很多場景下，依舊會產生性能問題。例如，bigkey 在分片集群模式下，對於數據的遷移也會有性能影響，以及我后面即將講到的數據過期、數據淘汰、透明大頁，都會受到 bigkey 的影響。
原因3：集中過期
排查思路
如果你發現，平時在操作 Redis 時，並沒有延遲很大的情況發生，但在某個時間點突然出現一波延時，其現象表現為：變慢的時間點很有規律，例如某個整點，或者每間隔多久就會發生一波延遲。
如果是出現這種情況，那么你需要排查一下，業務代碼中是否存在設置大量 key 集中過期的情況。
導致變慢的原因
如果有大量的 key 在某個固定時間點集中過期，在這個時間點訪問 Redis 時，就有可能導致延時變大。為什么集中過期會導致 Redis 延遲變大？這就需要我們了解 Redis 的過期策略是怎樣的。
Redis 的過期數據采用被動過期 + 主動過期兩種策略：
被動過期：只有當訪問某個 key 時，才判斷這個 key 是否已過期，如果已過期，則從實例中刪除
主動過期：Redis 內部維護了一個定時任務，默認每隔 100 毫秒（1秒10次）就會從全局的過期哈希表中隨機取出 20 個 key，然后刪除其中過期的 key，如果過期 key 的比例超過了 25%，則繼續重復此過程，直到過期 key 的比例下降到 25% 以下，或者這次任務的執行耗時超過了 25 毫秒，才會退出循環
注意，這個主動過期 key 的定時任務，是在 Redis 主線程中執行的。也就是說如果在執行主動過期的過程中，出現了需要大量刪除過期 key 的情況，那么此時應用程序在訪問 Redis 時，必須要等待這個過期任務執行結束，Redis 才可以服務這個客戶端請求。此時就會出現，應用訪問 Redis 延時變大。
如果此時需要過期刪除的是一個 bigkey，那么這個耗時會更久。而且，這個操作延遲的命令並不會記錄在慢日志中。因為慢日志中只記錄一個命令真正操作內存數據的耗時，而 Redis 主動刪除過期 key 的邏輯，是在命令真正執行之前執行的。所以，此時你會看到，慢日志中沒有操作耗時的命令，但我們的應用程序卻感知到了延遲變大，其實時間都花費在了刪除過期 key 上，這種情況我們需要尤為注意。
解決方案
1 如果你使用的 Redis 是 4.0 以上版本，可以開啟 lazy-free 機制,這樣當刪除過期 key 時，把釋放內存的操作放到后台線程中執行，避免阻塞主線程
Redis 4.0 以上版本，開啟 lazy-free 機制：
# 釋放過期 key 的內存，放到后台線程執行
lazyfree-lazy-expire yes
2 集中過期 key 增加一個隨機過期時間，把集中過期的時間打散，降低 Redis 清理過期 key 的壓力。這樣一來，Redis 在處理過期時，不會因為集中刪除過多的 key 導致壓力過大，從而避免阻塞主線程
在設置 key 的過期時間時，增加一個隨機時間，偽代碼可以這么寫：
# 在過期時間點之后的 5 分鍾內隨機過期掉
redis.expireat(key, expire_time + random(300))
運維層面
另外，除了業務層面的優化和修改配置之外，你還可以通過運維手段及時發現這種情況。運維層面，你需要把 Redis 的各項運行狀態數據監控起來，在 Redis 上執行 INFO 命令就可以拿到這個實例所有的運行狀態數據。
在這里我們需要重點關注 expired_keys 這一項，它代表整個實例到目前為止，累計刪除過期 key 的數量。
你需要把這個指標監控起來，當這個指標在很短時間內出現了突增，需要及時報警出來，然后與業務應用報慢的時間點進行對比分析，確認時間是否一致，如果一致，則可以確認確實是因為集中過期 key 導致的延遲變大
原因4：開啟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 always：Redis 每處理一次寫操作，都會把這個命令寫入到磁盤中才返回，整個過程都是在主線程執行的，這個過程必然會加重 Redis 寫負擔。原因也很簡單，操作磁盤要比操作內存慢幾百倍，采用這個配置會嚴重拖慢 Redis 的性能，因此我不建議你把 AOF 刷盤方式配置為 always。
appendfsync no：Redis 每次寫操作只寫內存，什么時候把內存中的數據刷到磁盤，交給操作系統決定，此方案對 Redis 的性能影響最小，但當 Redis 宕機時，會丟失一部分數據。
appendfsync everysec：Redis 主線程寫完內存后就返回，具體的刷盤操作是放到后台線程中執行的，后台線程每隔 1 秒把內存中的數據刷到磁盤中。兼顧了性能又盡可能地保證數據安全，是不是覺得很完美？這種方案還是存在導致 Redis 延遲變大的情況發生，甚至會阻塞整個 Redis。為什么？我把 AOF 最耗時的刷盤操作，放到后台線程中也會影響到 Redis 主線程？當 Redis 后台線程在執行 AOF 文件刷盤時，如果此時磁盤的 IO 負載很高，那這個后台線程在執行刷盤操作（fsync系統調用）時就會被阻塞住。此時的主線程依舊會接收寫請求，緊接着，主線程又需要把數據寫到文件內存中（write 系統調用），但此時的后台子線程由於磁盤負載過高，導致 fsync 發生阻塞，遲遲不能返回，那主線程在執行 write 系統調用時，也會被阻塞住，直到后台線程 fsync 執行完成后，主線程執行 write 才能成功返回。
解決方案
什么情況下會導致磁盤 IO 負載過大？以及如何解決這個問題呢？我總結了以下幾種情況，你可以參考進行問題排查：
1 子進程正在執行 AOF rewrite，這個過程會占用大量的磁盤 IO 資源
2 有其他應用程序在執行大量的寫文件操作，也會占用磁盤 IO 資源
對於情況1，Redis 的 AOF 后台子線程刷盤操作，撞上了子進程 AOF rewrite。這怎么辦？難道要關閉 AOF rewrite 才行？
幸運的是，Redis 提供了一個配置項，當子進程在 AOF rewrite 期間，可以讓后台子線程不執行刷盤（不觸發 fsync 系統調用）操作。這相當於在 AOF rewrite 期間，臨時把 appendfsync 設置為了 none，配置如下：
# AOF rewrite 期間，AOF 后台子線程不進行刷盤操作
# 相當於在這期間，臨時把 appendfsync 設置為了 none
no-appendfsync-on-rewrite yes
當然，開啟這個配置項，在 AOF rewrite 期間，如果實例發生宕機，那么此時會丟失更多的數據，性能和數據安全性，你需要權衡后進行選擇。
對於情況2：占用磁盤資源的是其他應用程序。那就比較簡單了，你需要定位到是哪個應用程序在大量寫磁盤，然后把這個應用程序遷移到其他機器上執行就好了，避免對 Redis 產生影響。
當然，如果你對 Redis 的性能和數據安全都有很高的要求，那么我建議從硬件層面來優化，更換為 SSD 磁盤，提高磁盤的 IO 能力，保證 AOF 期間有充足的磁盤資源可以使用。
原因5：fork耗時嚴重
排查思路
為了保證 Redis 數據的安全性，我們可能會開啟后台定時 RDB 和 AOF rewrite 功能。
如果你發現操作 Redis 延遲變大，都發生在 Redis 后台 RDB 和 AOF rewrite 期間，那你就需要排查，在這期間有可能導致變慢的情況。
導致變慢的原因
當 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 產生性能影響。
解決方案
1 控制 Redis 實例的內存：盡量在 10G 以下，執行 fork 的耗時與實例大小有關，實例越大，耗時越久
2 合理配置數據持久化策略：在 slave 節點執行 RDB 備份，推薦在低峰期執行，而對於丟失數據不敏感的業務（例如把 Redis 當做純緩存使用），可以關閉 AOF 和 AOF rewrite
3 Redis 實例不要部署在虛擬機上：fork 的耗時也與系統也有關，虛擬機比物理機耗時更久
4 降低主從庫全量同步的概率：適當調大 repl-backlog-size 參數，避免主從全量同步
原因6：碎片整理
簡介
Redis 的數據都存儲在內存中，當我們的應用程序頻繁修改 Redis 中的數據時，就有可能會導致 Redis 產生內存碎片。內存碎片會降低 Redis 的內存使用率，我們可以通過執行 INFO 命令，得到這個實例的內存碎片率：
# Memory used_memory:5709194824 used_memory_human:5.32G used_memory_rss:8264855552 used_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 的碎片整理工作是也在主線程中執行的，當其進行碎片整理時，必然會消耗 CPU 資源，產生更多的耗時，從而影響到客戶端的請求。
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 機器的負載情況，以及應用程序可接受的延遲范圍進行評估，合理調整碎片整理的參數，盡可能降低碎片整理期間對 Redis 的影響
原因7：綁定CPU
簡介
很多時候，我們在部署服務時，為了提高服務性能，降低應用程序在多個 CPU 核心之間的上下文切換帶來的性能損耗，通常采用的方案是進程綁定 CPU 的方式提高性能。
導致變慢的原因
在部署 Redis 時，如果你需要綁定 CPU 來提高其性能，我建議你仔細斟酌后再做操作。為什么？
因為 Redis 在綁定 CPU 時，是有很多考究的，如果你不了解 Redis 的運行原理，隨意綁定 CPU 不僅不會提高性能，甚至有可能會帶來相反的效果。
我們都知道，一般現代的服務器會有多個 CPU，而每個 CPU 又包含多個物理核心，每個物理核心又分為多個邏輯核心，每個物理核下的邏輯核共用 L1/L2 Cache。
而 Redis Server 除了主線程服務客戶端請求之外，還會創建子進程、子線程。其中子進程用於數據持久化，而子線程用於執行一些比較耗時操作，例如異步釋放 fd、異步 AOF 刷盤、異步 lazy-free 等等。如果你把 Redis 進程只綁定了一個 CPU 邏輯核心上，那么當 Redis 在進行數據持久化時，fork 出的子進程會繼承父進程的 CPU 使用偏好。而此時的子進程會消耗大量的 CPU 資源進行數據持久化（把實例數據全部掃描出來需要耗費CPU），這就會導致子進程會與主進程發生 CPU 爭搶，進而影響到主進程服務客戶端請求，訪問延遲變大。這就是 Redis 綁定 CPU 帶來的性能問題。
解決方案
如果你確實想要綁定 CPU，可以優化的方案是，不要讓 Redis 進程只綁定在一個 CPU 邏輯核上，而是綁定在多個邏輯核心上，而且，綁定的多個邏輯核心最好是同一個物理核心，這樣它們還可以共用 L1/L2 Cache。
當然，即便我們把 Redis 綁定在多個邏輯核心上，也只能在一定程度上緩解主線程、子進程、后台線程在 CPU 資源上的競爭。因為這些子進程、子線程還是會在這多個邏輯核心上進行切換，存在性能損耗。
如何再進一步優化？可能你已經想到了，我們是否可以讓主線程、子進程、后台線程，分別綁定在固定的 CPU 核心上，不讓它們來回切換，這樣一來，他們各自使用的 CPU 資源互不影響。
其實，這個方案 Redis 官方已經想到了。Redis 在 6.0 版本已經推出了這個功能，我們可以通過以下配置，對主線程、后台線程、后台 RDB 進程、AOF rewrite 進程，綁定固定的 CPU 邏輯核心：
# Redis Server 和 IO 線程綁定到 CPU核心 0,2,4,6 server_cpulist 0-7:2 # 后台子線程綁定到 CPU核心 1,3 bio_cpulist 1,3 # 后台 AOF rewrite 進程綁定到 CPU 核心 8,9,10,11 aof_rewrite_cpulist 8-11 # 后台 RDB 進程綁定到 CPU 核心 1,10,11 # bgsave_cpulist 1,10-1
如果你使用的正好是 Redis 6.0 版本，就可以通過以上配置，來進一步提高 Redis 性能。這里我需要提醒你的是，一般來說，Redis 的性能已經足夠優秀，除非你對 Redis 的性能有更加嚴苛的要求，否則不建議你綁定 CPU。
Redis變慢原因（系統相關）
原因1：實例內存達到上限
排查思路
如果你的 Redis 實例設置了內存上限 maxmemory，那么也有可能導致 Redis 變慢。
當我們把 Redis 當做純緩存使用時，通常會給這個實例設置一個內存上限 maxmemory，然后設置一個數據淘汰策略。而當實例的內存達到了 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 釋放內存時，也會耗時比較久。看到了么？bigkey 的危害到處都是，這也是前面我提醒你盡量不存儲 bigkey 的原因。
解決方案
1 避免存儲 bigkey，降低釋放內存的耗時
2 淘汰策略改為隨機淘汰，隨機淘汰比 LRU 要快很多（視業務情況調整）
3 拆分實例，把淘汰 key 的壓力分攤到多個實例上
4 如果使用的是 Redis 4.0 以上版本，開啟 layz-free 機制，把淘汰 key 釋放內存的操作放到后台線程中執行（配置 lazyfree-lazy-eviction = yes
原因2：開啟內存大頁
排查思路
我們都知道，應用程序向操作系統申請內存時，是按內存頁進行申請的，而常規的內存頁大小是 4KB。Linux 內核從 2.6.38 開始，支持了內存大頁機制，該機制允許應用程序以 2MB 大小為單位，向操作系統申請內存。應用程序每次向操作系統申請的內存單位變大了，但這也意味着申請內存的耗時變長。
導致變慢的原因
當 Redis 在執行后台 RDB 和 AOF rewrite 時，采用 fork 子進程的方式來處理。但主進程 fork 子進程后，此時的主進程依舊是可以接收寫請求的，而進來的寫請求，會采用 Copy On Write（寫時復制）的方式操作內存數據。
也就是說，主進程一旦有數據需要修改，Redis 並不會直接修改現有內存中的數據，而是先將這塊內存數據拷貝出來，再修改這塊新內存的數據，這就是所謂的「寫時復制」。寫時復制你也可以理解成，誰需要發生寫操作，誰就需要先拷貝，再修改。這樣做的好處是，父進程有任何寫操作，並不會影響子進程的數據持久化（子進程只持久化 fork 這一瞬間整個實例中的所有數據即可，不關心新的數據變更，因為子進程只需要一份內存快照，然后持久化到磁盤上）。但是請注意，主進程在拷貝內存數據時，這個階段就涉及到新內存的申請，如果此時操作系統開啟了內存大頁，那么在此期間，客戶端即便只修改 10B 的數據，Redis 在申請內存時也會以 2MB 為單位向操作系統申請，申請內存的耗時變長，進而導致每個寫請求的延遲增加，影響到 Redis 性能。同樣地，如果這個寫請求操作的是一個 bigkey，那主進程在拷貝這個 bigkey 內存塊時，一次申請的內存會更大，時間也會更久。可見，bigkey 在這里又一次影響到了性能。
解決方案
關閉內存大頁機制。首先，你需要查看 Redis 機器是否開啟了內存大頁：
$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
如果輸出選項是 always，就表示目前開啟了內存大頁機制，我們需要關掉它：
$ echo never > /sys/kernel/mm/transparent_hugepage/enabled
其實，操作系統提供的內存大頁機制，其優勢是，可以在一定程序上降低應用程序申請內存的次數。
但是對於 Redis 這種對性能和延遲極其敏感的數據庫來說，我們希望 Redis 在每次申請內存時，耗時盡量短，所以我不建議你在 Redis 機器上開啟這個機制。
原因3：使用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 kB Swap: 0 kB Size: 4 kB Swap: 0 kB Size: 132 kB Swap: 0 kB Size: 63488 kB Swap: 0 kB Size: 132 kB Swap: 0 kB Size: 65404 kB Swap: 0 kB Size: 1921024 kB Swap: 0 kB ...
這個結果會列出 Redis 進程的內存使用情況。每一行 Size 表示 Redis 所用的一塊內存大小，Size 下面的 Swap 就表示這塊 Size 大小的內存，有多少數據已經被換到磁盤上了，如果這兩個值相等，說明這塊內存的數據都已經完全被換到磁盤上了。
如果只是少量數據被換到磁盤上，例如每一塊 Swap 占對應 Size 的比例很小，那影響並不是很大。如果是幾百兆甚至上 GB 的內存被換到了磁盤上，那么你就需要警惕了，這種情況 Redis 的性能肯定會急劇下降。
解決方案
1 增加機器的內存，讓 Redis 有足夠的內存可以使用
2 整理內存空間，釋放出足夠的內存供 Redis 使用，然后釋放 Redis 的 Swap，讓 Redis 重新使用內存
釋放 Redis 的 Swap 過程通常要重啟實例，為了避免重啟實例對業務的影響，一般會先進行主從切換，然后釋放舊主節點的 Swap，重啟舊主節點實例，待從庫數據同步完成后，再進行主從切換即可。
可見，當 Redis 使用到 Swap 后，此時的 Redis 性能基本已達不到高性能的要求（你可以理解為武功被廢），所以你也需要提前預防這種情況。
預防的辦法就是，你需要對 Redis 機器的內存和 Swap 使用情況進行監控，在內存不足或使用到 Swap 時報警出來，及時處理。
原因4：網絡帶寬過載
排查思路
如果以上產生性能問題的場景，你都規避掉了，而且 Redis 也穩定運行了很長時間，但在某個時間點之后開始，操作 Redis 突然開始變慢了，而且一直持續下去，這種情況又是什么原因導致？
此時你需要排查一下 Redis 機器的網絡帶寬是否過載，是否存在某個實例把整個機器的網路帶寬占滿的情況。
導致變慢的原因
網絡帶寬過載的情況下，服務器在 TCP 層和網絡層就會出現數據包發送延遲、丟包等情況。
Redis 的高性能，除了操作內存之外，就在於網絡 IO 了，如果網絡 IO 存在瓶頸，那么也會嚴重影響 Redis 的性能。
解決方案
1 及時確認占滿網絡帶寬 Redis 實例，如果屬於正常的業務訪問，那就需要及時擴容或遷移實例了，避免因為這個實例流量過大，影響這個機器的其他實例。
2 運維層面，你需要對 Redis 機器的各項指標增加監控，包括網絡流量，在網絡流量達到一定閾值時提前報警，及時確認和擴容。
原因5：其他原因
1) 頻繁短連接
你的業務應用，應該使用長連接操作 Redis，避免頻繁的短連接。頻繁的短連接會導致 Redis 大量時間耗費在連接的建立和釋放上，TCP 的三次握手和四次揮手同樣也會增加訪問延遲。
2) 運維監控
前面我也提到了，要想提前預知 Redis 變慢的情況發生，必不可少的就是做好完善的監控。
監控其實就是對采集 Redis 的各項運行時指標，通常的做法是監控程序定時采集 Redis 的 INFO 信息，然后根據 INFO 信息中的狀態數據做數據展示和報警。
這里我需要提醒你的是，在寫一些監控腳本，或使用開源的監控組件時，也不能掉以輕心。在寫監控腳本訪問 Redis 時，盡量采用長連接的方式采集狀態信息，避免頻繁短連接。同時，你還要注意控制訪問 Redis 的頻率，避免影響到業務請求。
在使用一些開源的監控組件時，最好了解一下這些組件的實現原理，以及正確配置這些組件，防止出現監控組件發生 Bug，導致短時大量操作 Redis，影響 Redis 性能的情況發生。我們當時就發生過，DBA 在使用一些開源組件時，因為配置和使用問題，導致監控程序頻繁地與 Redis 建立和斷開連接，導致 Redis 響應變慢。
3）其它程序爭搶資源
最后需要提醒你的是，你的 Redis 機器最好專項專用，只用來部署 Redis 實例，不要部署其他應用程序，盡量給 Redis 提供一個相對「安靜」的環境，避免其它程序占用 CPU、內存、磁盤資源，導致分配給 Redis 的資源不足而受到影響。
最后終結一張圖：
