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

1.redis連接數(shù)過高
2.數(shù)據(jù)持久化導(dǎo)致的阻塞
3.主從存在頻繁全量同步
4.value值過大
5.redis慢查詢

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

redis連接數(shù)過高?

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

數(shù)據(jù)持久化導(dǎo)致的阻塞？

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

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

還有3個(gè)關(guān)鍵的參數(shù)，這里解釋一下：

save 900 1 //表示每15分鐘且至少有1個(gè)key改變，就觸發(fā)一次持久化
save 300 10 //表示每5分鐘且至少有10個(gè)key改變，就觸發(fā)一次持久化
save 60 10000 //表示每60秒至少有10000個(gè)key改變，就觸發(fā)一次持久化

因?yàn)閞edis持久化的動(dòng)作會(huì)記錄日志，我們首先找出出問題的時(shí)間段里的持久化內(nèi)容大小

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

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

得出結(jié)論：毫無壓力，所有這項(xiàng)也排除

主從存在頻繁全量同步

因?yàn)槲覀兪菃畏?wù)器，沒有做主從所以直接排除

value值過大

先看一下當(dāng)時(shí)cpu時(shí)redis的key和存儲(chǔ)量情況

462萬多的key才使用900MB左右的內(nèi)容，平均一個(gè)key才0.2kb左右，基本不可能，但是抱著嚴(yán)謹(jǐn)?shù)膽B(tài)度還是決定模擬寫入大的value值，測試之前現(xiàn)進(jìn)行清空，然后寫了一個(gè)數(shù)據(jù)讀寫腳本(這里就不展示代碼了)：

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

redis慢查詢

相信大家看到這里已經(jīng)知道結(jié)論了，就是慢查詢的問題。

一個(gè)高頻訪問的網(wǎng)頁程序請求redis使用keys命令，導(dǎo)致每次訪問接近2秒，當(dāng)2秒內(nèi)訪問超過服務(wù)器的最高承載量時(shí),后面請求全部需要排隊(duì)，導(dǎo)致大量的超時(shí)(504)...

看了一下官方對keys命令的說明，已經(jīng)進(jìn)行警告生產(chǎn)環(huán)境要慎用，會(huì)產(chǎn)生性能問題：

原文鏈接：redis服務(wù)器cpu100%的原因和解決方案_數(shù)據(jù)庫_weixin_44753686的博客-CSDN博客

總結(jié)

以上是生活随笔為你收集整理的链接服务器 慢_redis服务器cpu100%的原因和解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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