上一篇講述了由于redis服務器cpu100%導致網站502的問題，今天延續上一篇的內容，說明一下原因和分析過程。

首先引起cpu100%可能的幾大原因：

1.redis連接數過高

2.數據持久化導致的阻塞

3.主從存在頻繁全量同步

4.value值過大

5.redis慢查詢

為了模擬redis服務器cpu100%，臨時買了一臺阿里云ecs，并把那天清空前的redis備份還原到服務器上。下面我們按照順序逐個排查，

redis連接數過高?

redis的默認鏈接數是10000，我們并沒有更改這個值，前面提到了web的承載量是1600左右，所有可以排除

數據持久化導致的阻塞？

大家知道redis是可以持久化的，而redis持久化會采取LZF算法進行壓縮，這種方式會減少磁盤的存儲大小，而通過這種方式是需要消耗cpu的，我們看下redis的配置

rdbcompression yes 表示壓縮算法是打開的

還有3個關鍵的參數，這里解釋一下：

save 900 1 //表示每15分鐘且至少有1個key改變，就觸發一次持久化

save 300 10 //表示每5分鐘且至少有10個key改變，就觸發一次持久化

save 60 10000 //表示每60秒至少有10000個key改變，就觸發一次持久化

因為redis持久化的動作會記錄日志，我們首先找出出問題的時間段里的持久化內容大小

也才75M，看起來不會是它了，為了確保，我批量的高頻次寫入redis進行驗證(這里代碼就不貼了)，直接看實驗結果，數據量大概是上面的4倍

寫入的過程我實時的觀察cpu運作情況(實驗的服務器是單核的，所有直接看阿里云的監控頁)：

得出結論：毫無壓力，所有這項也排除

主從存在頻繁全量同步

因為我們是單服務器，沒有做主從所以直接排除

value值過大

?先看一下當時cpu時redis的key和存儲量情況

462萬多的key才使用900MB左右的內容，平均一個key才0.2kb左右，基本不可能，但是抱著嚴謹的態度還是決定模擬寫入大的value值，測試之前現進行清空，然后寫了一個數據讀寫腳本(這里就不展示代碼了)：

使單個key平均300KB左右提升了100多倍，cpu毫無壓力，所有這個問題也可以排除。

redis慢查詢

相信大家看到這里已經知道結論了，就是慢查詢的問題。

一個高頻訪問的網頁程序請求redis使用keys命令，導致每次訪問接近2秒，當2秒內訪問超過服務器的最高承載量時,后面請求全部需要排隊，導致大量的超時(504)...

看了一下官方對keys命令的說明，已經進行警告生產環境要慎用，會產生性能問題：

?

?