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的情況,網卡軟中斷瓶頸一般出現在網絡高流量吞吐的場景