Redis是一個單執行緒的架構，所有的操作全部都在一個主執行緒完成。所以一旦Redis發生阻塞，那將是一場惡夢。接下來，我們就來看看對於Redis發生阻塞問題。如何排查以及解決。
Redis資料結構或API使用不合理
#存在大物件且對大物件進行複雜的較高的命令
1、對一個有千萬個元素的hash執行hgetall操作, 或del操作.類似的這種操作都會造成Redis阻塞
2、對於這種大物件可以採用redis-cli -h {host} -p {port} bigkeys 來查看。但是該指令只能查詢某類型中的其
中最大的一個key。如果你想查詢多個。可以採用修改redis-cli原始碼的方式（Redis的原始碼是C）。如果不想修 改原始碼的話也可以使用scan來完成。
對於Scan指令需要注意。此指令只能掃描單一Redis上的資料。如果你是一個集群，需要每台機器執行一遍。但如果你使用開源的客戶端的話（例如：Java的Lettuce客戶端）就已經幫你把scan指令實作為可以掃描整個叢集了。
3、然後對大物件進行拆分。具體拆分要視業務而定了。
Redis的CPU使用率接近100%
1、從機同步主機資料。從機接受到rdb檔案後從磁碟載入資料
2、主從持久化資料。
3、將cpu使用率達到100%，有可能是真實業務訪問量確實很大。單一Redis達到每秒處理6萬 的請求。這時候就只能做水平擴展了
4、如果Redis每秒操作數只有幾百，或者幾千，且cpu還是很高的話就有可能使用了高演算法複雜度的命令。例如hgetall。還有一種可能是記憶體的過度優化導致。這種情況目前暫時沒有遇到，但也納入考慮範圍。
Cpu競賽
1、Redis是CPU密集型的應用，不適合和其他CPU密集的服務部署在一起。
2、在生產環境中，我們一台伺服器的設定是32核心邏輯cpu, 256GB記憶體。每台機器如果只部署一台Redis比較浪費。所以可能會一台機器部署多個Redis。通常會將Redis程序綁定到CPU上。但是在產生RDB檔或AOF持久話時，就會產生子程序。這樣子進程與父進程會產生CPU競爭。所以當開啟持久化或主節點。不建議綁定CPU
記憶體交換
Redis是一個記憶體型資料庫，所有資料都放在記憶體中。所以強烈建議不要開啟記憶體交換
網路問題
主從同步網路延遲較大的話，導致從機經常斷線重連。如果斷線時間久了。導致從機再次連接上主機時會全量同步，這時主機，從機都會收到影響
更多redis知識請關注redis入門教程欄目。
以上是Redis阻塞問題排除的詳細內容。更多資訊請關注PHP中文網其他相關文章！
