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