1.內因：
a.api或資料結構使用不合理： 如：對乙個包含上萬元素的hash結構執行hgetall操作,資料量大且命令複雜度o(n),必然阻塞
b.慢查詢：前面有介紹
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來充當資料庫的快取，從而大大緩解資料庫的壓力以及提高使用者的體驗感，但是redis也會存在阻塞的情況，導致整個系統變慢，從而影響使用者體驗。所以我們在針對redis阻塞的情況下可以從以下七個方面來整體的進行分析，看看到底是 導致了redis的阻塞。因為redis...
Redis使用單執行緒的原因
單執行緒指的是網路請求模組使用了乙個執行緒 所以不需考慮併發安全性 即乙個執行緒處理所有網路請求，其他模組仍用了多個執行緒。1絕大部分請求是純粹的記憶體操作 非常快速 2資料結構簡單，對資料操作也簡單 3採用單執行緒,避免了不必要的上下文切換和競爭條件 4非阻塞io io多路復用 多路 i o 復用...
redis單執行緒的原因和併發快的原因
1 redis是基於記憶體的，記憶體的讀寫速度非常快 2 redis是單執行緒的，省去了很多上下文切換執行緒的時間 3 redis使用多路復用技術，可以處理併發的連線。非阻塞io 內部實現採用epoll，採用了epoll 自己實現的簡單的事件框架。epoll中的讀 寫 關閉 連線都轉化成了事件，然後...