1.內因：
A.api或數據結構使用不合理： 如：對一個包含上萬元素的hash結構執行hgetall操作,數據量大且命令複雜度O(n),必然阻塞
B.慢查詢：前面有介紹
C.大對象：
執行./redis-cli -h {ip} -p {port} --bigkeys命令可找出當前最大對象出來,接着便可對大對象進行調整或縮減或分成多個小對象
生產環境可執行debug object key查看key對應value序列化後的長度,或strlen key查看key的字節數
主動檢測大對象：scan + debug object key命令
可使用info commandstats命令分析命令不合理的開銷時間，會返回最近執行命令的調用次數、耗時等信息
D.CPU飽和：redis單線程只能使用一個CPU,飽和將無法處理更多命令 可以執行命令redis-cli -h {ip} -p {port} --stat獲取當前redis使用情況
E.持久化相關阻塞：
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 {ip} -p {port}命令後加入參數進行測試：
--latency：持續進行延遲測試,分別統計：最小值、最大值、平均值、採樣次數
--latency-history：統計結果同—latency,但默認每15秒完成一行統計,可通過-i參數控制採樣時間
--latency-dist：使用統計圖的形式展示延遲統計,每1秒採樣一次
3)網卡軟中斷(求大佬指教)：
網卡軟中斷是指由於單個網卡隊列只能使用一個CPU,高併發下網卡數據交互都集中在同一個CPU,導致無法充分利用多核CPU的情況,網卡軟中斷瓶頸一般出現在網絡高流量吞吐的場景