雖然我們在日常工作中常常使用redis來充當資料庫的快取，從而大大緩解資料庫的壓力以及提高使用者的體驗感，但是redis也會存在阻塞的情況，導致整個系統變慢，從而影響使用者體驗。
所以我們在針對redis阻塞的情況下可以從以下七個方面來整體的進行分析，看看到底是**導致了redis的阻塞。
因為redis是單執行緒的，所以如果出現大量的慢查詢，可能會導致redis-server阻塞，可以通過slowlog get n 獲取慢日誌檢視詳細情況，如下所示
另外還可以通過config get slowlog-*來檢視現有的配置
bigkey大物件可能導致的問題如下
但是要是幾乎不會被訪問到，那麼只有記憶體空間不均勻的問題存在，影響不大，但是如果其是乙個熱點key（頻繁訪問），那麼其影響還是很大的。
可以通過 redis-cli -h -p bigkeys 發現大物件。
因為redis的資料存放在記憶體中，所以存放資料量的大小取決於記憶體的多少
如果乙個redis的例項的記憶體使用率超過可用最大記憶體，那麼作業系統開始進行記憶體和swap空間的交換，把記憶體中舊的不用的內容寫到硬碟的swap區。
所以當redis程序上發生記憶體交換，那麼redis和依賴redis上資料的應用都會受到嚴重的效能影響。
我們可以使用used_memory指標可知道redis正在使用的記憶體情況。
另外我們可以提前識別redis記憶體交換：
根據程序號查詢記憶體交換資訊
如果交換量都是0kb或者個別的4kb都是正常現象在 rdb 生成和 aof 重寫時，會 fork 乙個子程序完成持久化工作，當 fork 操作執行太過耗時也會造成阻塞，阻塞原因是該操作會複製父程序的空間記憶體表，即 fork 操作耗時跟記憶體量（資料集）關係較大。
fork 操作是重量級操作，其耗時應該在 20ms/gb；應該嚴格控制每個例項可使用的最大記憶體 10gb 以內（複製空間記憶體表）；降低 fork 操作執行頻率，適當放寬 aof 重寫觸發時機。
另外使用 info stats 命令獲取 lastest_fork_usec 指標，表示 redis 最近一次 fork 操作耗時。
開啟 aof，檔案刷盤一般每秒一次，硬碟壓力過大時，fsync 需要等待寫入完成。
檢視 redis 日誌或 info persistence 統計中的 aof_delayed_fsync 指標。
輸入緩衝區
redis 為每個客戶端分配了輸入緩衝區，會將客戶端傳送命令臨時儲存，然後取出來執行。 qbuf 表示總容量（0 表示沒有分配查詢緩衝區），qbuf-free 表示剩餘容量（0 表示沒有剩餘空間）；大小不能超過 1g，當大小超過 1g 時會將客戶端自動關閉，輸入緩衝區不受 maxmemory 限制。
當大量的 key 進入輸入緩衝區且無法被消費時，即可造成 redis 阻塞；通過 client list 命令可定位發生阻塞的客戶端；通過 info clients 命令的 blocked_clients 引數可以檢視到當前阻塞的命令。
輸出緩衝區
其是 redis-server 端實現的乙個讀取緩衝區，redis-server 在接收到客戶端的請求後，把獲取結果寫入到 client buffer 中，而不是直接傳送給客戶端。從而可以繼續處理客戶端的其他請求，這樣非同步處理方式使 redis-server 不會因為網路原因阻塞其他請求的處理。
連線拒絕
網路延遲
redis執行緒阻塞原因排插 Redis 阻塞原因
1.內因 a.api或資料結構使用不合理 如 對乙個包含上萬元素的hash結構執行hgetall操作,資料量大且命令複雜度o n 必然阻塞 b.慢查詢 前面有介紹 c.大物件 執行.redis cli h p bigkeys命令可找出當前最大物件出來,接著便可對大物件進行調整或縮減或分成多個小物件 ...
linux效能排查以及優化方法
1.系統硬體資源 1 cpu 多核 或超執行緒 2 記憶體 物理記憶體和swap設定 3 磁碟i o raid技術 ssd磁碟 4 頻寬 2.作業系統 1 核心引數優化 ulimit n 最大開啟檔案數 ulimit u 最大使用者數 2 檔案系統優化 推薦 讀操作頻繁，同時小檔案眾多的應用 首選 ...
spring無法啟動常見原因及排查方法
這裡總結的問題，通常啥錯誤也不報，需要自個debug排查，當然每個人遇到的問題可能是不同的，這裡僅僅是我個人幫同事解決問題後的一些總結,可能網上的小夥伴可能也遇到，姑且簡單記錄一下 1.mybatis檔案配置有問題，比如返回值型別寫錯了，或者sql語法有問題 排查方法 在abstractautowi...