遇到 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 文件而阻塞。是否使用了多核 CPU 或 NUMA 架構的機器運行 Redis 實例？使用多核 CPU 時，可以給 Redis 實例綁定物理核；使用 NUMA 架構時，注意把 Redis 實例和網絡中斷處理程序運行在同一個 CPU Socket 上。

?

關于如何分析、排查、解決Redis變慢問題，我總結的checklist如下：

1、使用復雜度過高的命令（例如SORT/SUION/ZUNIONSTORE/KEYS），或一次查詢全量數據（例如LRANGE key 0 N，但N很大）

分析：a) 查看slowlog是否存在這些命令 b) Redis進程CPU使用率是否飆升（聚合運算命令導致）

解決：a) 不使用復雜度過高的命令，或用其他方式代替實現（放在客戶端做） b) 數據盡量分批查詢（LRANGE key 0 N，建議N<=100，查詢全量數據建議使用HSCAN/SSCAN/ZSCAN）

2、操作bigkey

分析：a) slowlog出現很多SET/DELETE變慢命令（bigkey分配內存和釋放內存變慢） b) 使用redis-cli -h $host -p $port --bigkeys掃描出很多bigkey

解決：a) 優化業務，避免存儲bigkey b) Redis 4.0+可開啟lazy-free機制

3、大量key集中過期

分析：a) 業務使用EXPIREAT/PEXPIREAT命令 b) Redis info中的expired_keys指標短期突增

解決：a) 優化業務，過期增加隨機時間，把時間打散，減輕刪除過期key的壓力 b) 運維層面，監控expired_keys指標，有短期突增及時報警排查

4、Redis內存達到maxmemory

分析：a) 實例內存達到maxmemory，且寫入量大，淘汰key壓力變大 b) Redis info中的evicted_keys指標短期突增

解決：a) 業務層面，根據情況調整淘汰策略（隨機比LRU快） b) 運維層面，監控evicted_keys指標，有短期突增及時報警 c) 集群擴容，多個實例減輕淘汰key的壓力

5、大量短連接請求

分析：Redis處理大量短連接請求，TCP三次握手和四次揮手也會增加耗時

解決：使用長連接操作Redis

6、生成RDB和AOF重寫fork耗時嚴重

分析：a) Redis變慢只發生在生成RDB和AOF重寫期間 b) 實例占用內存越大，fork拷貝內存頁表越久 c) Redis info中latest_fork_usec耗時變長

解決：a) 實例盡量小 b) Redis盡量部署在物理機上 c) 優化備份策略（例如低峰期備份） d) 合理配置repl-backlog和slave client-output-buffer-limit，避免主從全量同步 e) 視情況考慮關閉AOF f) 監控latest_fork_usec耗時是否變長

7、AOF使用awalys機制

分析：磁盤IO負載變高

解決：a) 使用everysec機制 b) 丟失數據不敏感的業務不開啟AOF

8、使用Swap

分析：a) 所有請求全部開始變慢 b) slowlog大量慢日志 c) 查看Redis進程是否使用到了Swap

解決：a) 增加機器內存 b) 集群擴容 c) Swap使用時監控報警

9、進程綁定CPU不合理

分析：a) Redis進程只綁定一個CPU邏輯核 b) NUMA架構下，網絡中斷處理程序和Redis進程沒有綁定在同一個Socket下

解決：a) Redis進程綁定多個CPU邏輯核 b) 網絡中斷處理程序和Redis進程綁定在同一個Socket下

10、開啟透明大頁機制

分析：生成RDB和AOF重寫期間，主線程處理寫請求耗時變長（拷貝內存副本耗時變長）

解決：關閉透明大頁機制

11、網卡負載過高

分析：a) TCP/IP層延遲變大，丟包重傳變多 b) 是否存在流量過大的實例占滿帶寬

解決：a) 機器網絡資源監控，負載過高及時報警 b) 提前規劃部署策略，訪問量大的實例隔離部署

總之，Redis的性能與CPU、內存、網絡、磁盤都息息相關，任何一處發生問題，都會影響到Redis的性能。

主要涉及到的包括業務使用層面和運維層面：業務人員需要了解Redis基本的運行原理，使用合理的命令、規避bigke問題和集中過期問題。運維層面需要DBA提前規劃好部署策略，預留足夠的資源，同時做好監控，這樣當發生問題時，能夠及時發現并盡快處理。

總結

以上是生活随笔為你收集整理的redis性能9个checklist和实操的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。