redis是一個單線程的架構(gòu)，所有的操作全部都在一個主線程中完成。所以一旦Redis發(fā)生阻塞，那將是一場噩夢。接下來，我們就來看下對于Redis發(fā)生阻塞問題。如何排查以及解決。
Redis數(shù)據(jù)結(jié)構(gòu)或API使用不合理
存在大對象且對大對象進行復(fù)雜的較高的命令
1、對一個有千萬個元素的hash執(zhí)行hgetall操作, 或del操作.類似的這種操作都會造成Redis阻塞
2、對于這種大對象可以采用redis-cli -h {host} -p {port} bigkeys 來查看。但是該命令只能查詢某類型中的其中最大的一個key。如果你想查詢多個?？梢圆捎眯薷膔edis-cli源代碼的方式（Redis的源代碼是C）。如果不想修 改源代碼的話也可以使用scan來完成。
對于Scan命令需要注意。該命令只能掃描單臺Redis上的數(shù)據(jù)。如果你是一個集群，需要每臺機器執(zhí)行一遍。但是如果你使用開源的客戶端的話（比如：JAVA的Lettuce客戶端）就已經(jīng)幫你把scan命令實現(xiàn)為可以掃描整個集群了。
3、然后對大對象進行拆分。具體拆分要視業(yè)務(wù)而定了。
Redis的CPU使用率接近100%
1、從機同步主機數(shù)據(jù)。從機接受到rdb文件后從磁盤加載數(shù)據(jù)
2、主從持久化數(shù)據(jù)。
3、將cpu使用率達到100%，有可能是真實業(yè)務(wù)訪問量確實很大。單臺Redis達到每秒處理6萬+的請求。這個時候就只能做水平擴展了
4、如果Redis每秒操作數(shù)只有幾百，或者幾千，且cpu還是很高的話就有可能使用了高算法復(fù)雜度的命令。例如hgetall。還有一種可能是內(nèi)存的過度優(yōu)化導(dǎo)致。這種情況目前暫時沒有遇到，但也納入考慮范圍。
Cpu競爭
1、Redis是一個CPU密集型的應(yīng)用，不適合和其他CPU密集的服務(wù)部署在一起。
2、在生產(chǎn)環(huán)境中，我們一臺服務(wù)器的配置是32核邏輯cpu, 256GB內(nèi)存。每臺機器如果只部署一臺Redis比較浪費。所以可能會一臺機器部署多個Redis。通常會將Redis進程綁定到CPU上。但是在生成RDB文件或者AOF持久話時，就會產(chǎn)生子進程。這樣子進程與父進程會產(chǎn)生CPU競爭。所以當開啟持久化或者主節(jié)點。不建議綁定CPU
內(nèi)存交換
Redis是一個內(nèi)存型數(shù)據(jù)庫，所有數(shù)據(jù)全部放在內(nèi)存中。所以強烈建議不開啟內(nèi)存交換
網(wǎng)絡(luò)問題
主從同步網(wǎng)絡(luò)延遲較大的話，導(dǎo)致從機經(jīng)常斷線重連。如果斷線時間久了。導(dǎo)致從機再次連接上主機時會全量同步，這時主機，從機都會收到影響
