1.內因：
a.api或資料結構使用不合理： 如：對乙個包含上萬元素的hash結構執行hgetall操作,資料量大且命令複雜度o(n),必然阻塞
b.慢查詢：和很多關係型資料庫（例如：mysql）一樣， redis 也提供了慢查詢日誌記錄，redis 會把命令執行時間超過 slowlog-log-slower-than 的都記錄在 reids 內部的乙個列表（list）中，該列表的長度最大為 slowlog-max-len 。需要注意的是，慢查詢記錄的只是命令的執行時間，不包括網路傳輸和排隊時間
c.大物件：
執行./redis-cli -h -p --bigkeys命令可找出當前最大物件出來,接著便可對大物件進行調整或縮減或分成多個小物件
生產環境可執行debug object key檢視key對應value序列化後的長度,或strlen key檢視key的位元組數
主動檢測大物件：scan + debug object key命令
可使用info commandstats命令分析命令不合理的開銷時間，會返回最近執行命令的呼叫次數、耗時等資訊
a.fork阻塞： fork操作發生在rdb和aof重寫時,redis主線程呼叫fork操作產生共享記憶體的子程序,由子程序完成持久化檔案重寫工作,若fork操作本身耗時過長,則必會導致主線程阻塞；可執行info stats命令獲取到latest_fork_usec指標,表示redis最近一次fork操作耗時,若超過1s,則需要做出優化調整
b.aof刷盤阻塞： 當開啟aof持久化功能時,檔案刷盤的方式一般採用每秒一次,後台執行緒每秒對aof檔案做fsync操作,硬碟壓力過大時,fsync操作需要等待,直到寫入完成如果主線程發現距離上一次的fsync成功超過2秒,為了資料安全性它會阻塞直到後台執行緒執行fsync操作完成,這種阻塞行為主要是硬碟壓力引起,可檢視redis日誌識別出這種情況,當發生這種阻塞行為時,會列印如下日誌：
亦可檢視info persistence統計中的aof_delayed_fsync指標,每次發生aof刷盤阻塞主線程時會累加
c.hugepage寫操作阻塞(求大佬指教)： 子程序在執行重寫期間利用linux寫時複製技術降低記憶體開銷,因此只有寫操作時redis才複製要修改的記憶體頁,對於開啟transparent hugepages的作業系統,每次寫命令引起的複製記憶體頁單位由4k變為2mb,放大了512倍,會拖慢寫操作的執行時間,導致大量寫操作慢查詢
2.外因：
a.cpu競爭：
a.程序競爭：當redis與其他cpu密集型服務部署在一起時可能發生
b.繫結cpu：由於redis單執行緒架構,為充分利用多核cpu,一台機器部署多個redis並將redis程序繫結到cpu(可降低cpu上下文切換開銷),當redis父程序fork操作建立子程序進行rdb/aof重寫(很耗cpu)時,父子程序共享同一cpu,將影響redis的穩定性
b.記憶體交換：指作業系統把redis使用的部分記憶體換出到硬碟,導致交換後redis效能急劇下降(記憶體與硬碟處理速度不在乙個數量級),可如下檢視記憶體交換資訊獲取redis程序號→cat /proc/程序號/smaps | grep swap
c.網路問題：
1)連線拒絕：
a).網路閃段：略
b).連線拒絕：略
c).連線溢位：指作業系統或redis客戶端在連線時的問題,2種原因
原因1：程序限制 作業系統會對程序使用的資源做限制,其中之一便是對可開啟最大檔案數進行控制,ulimit –n可檢視,超過則傳送too many open files錯誤
原因2：backlog佇列溢位 系統對於特定埠的tcp連線使用backlog佇列儲存,redis預設長度為511,通過tcp-backlog引數設定,高併發場景下可增大該值,但必須大於作業系統允許值才生效，系統預設backlog為128,使用echo511>/proc/sys/net/core/somaxconn命令進行修改,可通過netstat -s命令獲取因佇列溢位造成的連線拒絕統計
2)網路延遲： 可使用redis提供的測試工具進行測試,在redis-cli -h -p 命令後加入引數進行測試：
--latency：持續進行延遲測試,分別統計：最小值、最大值、平均值、取樣次數
--latency-history：統計結果同—latency,但預設每15秒完成一行統計,可通過-i引數控制取樣時間
--latency-dist：使用統計圖的形式展示延遲統計,每1秒取樣一次
3)網絡卡軟中斷(求大佬指教)：
網絡卡軟中斷是指由於單個網絡卡佇列只能使用乙個cpu,高併發下網絡卡資料互動都集中在同乙個cpu,導致無法充分利用多核cpu的情況,網絡卡軟中斷瓶頸一般出現在網路高流量吞吐的場景
原文：
redis執行緒阻塞原因排插 Redis 阻塞原因
1.內因 a.api或資料結構使用不合理 如 對乙個包含上萬元素的hash結構執行hgetall操作,資料量大且命令複雜度o n 必然阻塞 b.慢查詢 前面有介紹 c.大物件 執行.redis cli h p bigkeys命令可找出當前最大物件出來,接著便可對大物件進行調整或縮減或分成多個小物件 ...
redis 6 阻塞查詢
redis是典型的單執行緒架構，所有的讀寫操作都是在一條主線程中完成的。當redis用於高併發場景時，這條執行緒就變成了它的生命線。如果出現阻塞，哪怕是很短時間，對於我們的應用來說都是噩夢。導致阻塞問題的場景大致分為內在原因和外在原因 內在原因包括 不合理地使用api或資料結構 cpu飽和 持久化阻...
redis學習筆記7 阻塞
1.發現阻塞 客戶端記錄redis相關日誌時，需要具體到redis節點，在出現連線相關異常時能定位的具體節點。伺服器端應利用相關工具加強對redis集群的監控，發現不正常指標時應進行報警，並快速反應。主要監控指標為慢查詢 持久化阻塞 連線拒絕 cpu記憶體網路磁碟使用過載。阻塞出現的原因主要包括內在...