遇到 Redis 性能變慢時，按照這些步驟逐一檢查，高效地解決問題。

1. 獲取 Redis 實(shí)例在當(dāng)前環(huán)境下的基線性能。

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

3.是否對過期 key 設(shè)置了相同的過期時間？對于批量刪除的 key，可以在每個 key 的過期時間上加一個隨機(jī)數(shù)，避免同時刪除。

4.是否存在 bigkey？ 對于 bigkey 的刪除操作，如果你的 Redis 是 4.0 及以上的版本，可以直接利用異步線程機(jī)制減少主線程阻塞；如果是 Redis 4.0 以前的版本，可以使用 SCAN 命令迭代刪除；對于 bigkey 的集合查詢和聚合操作，可以使用 SCAN 命令在客戶端完成。

5.Redis AOF 配置級別是什么？業(yè)務(wù)層面是否的確需要這一可靠性級別？如果我們需要高性能，同時也允許數(shù)據(jù)丟失，可以將配置項(xiàng) no-appendfsync-on-rewrite 設(shè)置為 yes，避免 AOF 重寫和 fsync 競爭磁盤 IO 資源，導(dǎo)致 Redis 延遲增加。當(dāng)然， 如果既需要高性能又需要高可靠性，最好使用高速固態(tài)盤作為 AOF 日志的寫入盤。

6.Redis 實(shí)例的內(nèi)存使用是否過大？發(fā)生 swap 了嗎？如果是的話，就增加機(jī)器內(nèi)存，或者是使用 Redis 集群，分?jǐn)倖螜C(jī) Redis 的鍵值對數(shù)量和內(nèi)存壓力。同時，要避免出現(xiàn) Redis 和其他內(nèi)存需求大的應(yīng)用共享機(jī)器的情況。

7.在 Redis 實(shí)例的運(yùn)行環(huán)境中，是否啟用了透明大頁機(jī)制？如果是的話，直接關(guān)閉內(nèi)存大頁機(jī)制就行了。

8.是否運(yùn)行了 Redis 主從集群？如果是的話，把主庫實(shí)例的數(shù)據(jù)量大小控制在 2~4GB，以免主從復(fù)制時，從庫因加載大的 RDB 文件而阻塞。是否使用了多核 CPU 或 NUMA 架構(gòu)的機(jī)器運(yùn)行 Redis 實(shí)例？使用多核 CPU 時，可以給 Redis 實(shí)例綁定物理核；使用 NUMA 架構(gòu)時，注意把 Redis 實(shí)例和網(wǎng)絡(luò)中斷處理程序運(yùn)行在同一個 CPU Socket 上。

?

關(guān)于如何分析、排查、解決Redis變慢問題，我總結(jié)的checklist如下：

1、使用復(fù)雜度過高的命令（例如SORT/SUION/ZUNIONSTORE/KEYS），或一次查詢?nèi)繑?shù)據(jù)（例如LRANGE key 0 N，但N很大）

分析：a) 查看slowlog是否存在這些命令 b) Redis進(jìn)程CPU使用率是否飆升（聚合運(yùn)算命令導(dǎo)致）

解決：a) 不使用復(fù)雜度過高的命令，或用其他方式代替實(shí)現(xiàn)（放在客戶端做） b) 數(shù)據(jù)盡量分批查詢（LRANGE key 0 N，建議N<=100，查詢?nèi)繑?shù)據(jù)建議使用HSCAN/SSCAN/ZSCAN）

2、操作bigkey

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

解決：a) 優(yōu)化業(yè)務(wù)，避免存儲bigkey b) Redis 4.0+可開啟lazy-free機(jī)制

3、大量key集中過期

分析：a) 業(yè)務(wù)使用EXPIREAT/PEXPIREAT命令 b) Redis info中的expired_keys指標(biāo)短期突增

解決：a) 優(yōu)化業(yè)務(wù)，過期增加隨機(jī)時間，把時間打散，減輕刪除過期key的壓力 b) 運(yùn)維層面，監(jiān)控expired_keys指標(biāo)，有短期突增及時報警排查

4、Redis內(nèi)存達(dá)到maxmemory

分析：a) 實(shí)例內(nèi)存達(dá)到maxmemory，且寫入量大，淘汰key壓力變大 b) Redis info中的evicted_keys指標(biāo)短期突增

解決：a) 業(yè)務(wù)層面，根據(jù)情況調(diào)整淘汰策略（隨機(jī)比LRU快） b) 運(yùn)維層面，監(jiān)控evicted_keys指標(biāo)，有短期突增及時報警 c) 集群擴(kuò)容，多個實(shí)例減輕淘汰key的壓力

5、大量短連接請求

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

解決：使用長連接操作Redis

6、生成RDB和AOF重寫fork耗時嚴(yán)重

分析：a) Redis變慢只發(fā)生在生成RDB和AOF重寫期間 b) 實(shí)例占用內(nèi)存越大，fork拷貝內(nèi)存頁表越久 c) Redis info中l(wèi)atest_fork_usec耗時變長

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

7、AOF使用awalys機(jī)制

分析：磁盤IO負(fù)載變高

解決：a) 使用everysec機(jī)制 b) 丟失數(shù)據(jù)不敏感的業(yè)務(wù)不開啟AOF

8、使用Swap

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

解決：a) 增加機(jī)器內(nèi)存 b) 集群擴(kuò)容 c) Swap使用時監(jiān)控報警

9、進(jìn)程綁定CPU不合理

分析：a) Redis進(jìn)程只綁定一個CPU邏輯核 b) NUMA架構(gòu)下，網(wǎng)絡(luò)中斷處理程序和Redis進(jìn)程沒有綁定在同一個Socket下

解決：a) Redis進(jìn)程綁定多個CPU邏輯核 b) 網(wǎng)絡(luò)中斷處理程序和Redis進(jìn)程綁定在同一個Socket下

10、開啟透明大頁機(jī)制

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

解決：關(guān)閉透明大頁機(jī)制

11、網(wǎng)卡負(fù)載過高

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

解決：a) 機(jī)器網(wǎng)絡(luò)資源監(jiān)控，負(fù)載過高及時報警 b) 提前規(guī)劃部署策略，訪問量大的實(shí)例隔離部署

總之，Redis的性能與CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤都息息相關(guān)，任何一處發(fā)生問題，都會影響到Redis的性能。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。