導致阻塞問題的原因：

內在原因：不合理地使用API或數據結構、CPU飽和、持久化阻塞等
外在原因：CPU競爭、內存交換、網絡問題等

圖片描述(最多50字)

一、發現阻塞

應用方加入異常監控，如日誌系統，比如Java語言中的logback或log4j
Redis監控系統，如CacheCloud

二、內在原因

2.1 API或數據結構使用不合理

通常Redis執行命令速度非常快，但是，如果對一個包含上萬個元素的hash結構執行hgetall操作，由於數據量比較大且命令算法復雜度是O(n)，這條命令執行速度必然很慢。

對於高並發的場景應該盡量避免在大對象上執行算法復雜度超過O(n)的命令。

（1）如何發現慢查詢

Redis原生提供慢查詢統計功能，執行slowlog get{n}命令可以獲取最近的n條慢查詢命令，默認對於執行超過10毫秒的命令都會記錄到一個定長隊列中，線上實例建議設置為1毫秒便於及時發現毫秒級以上的命令。

（2）發現慢查詢後如何調整

修改為低算法復雜度的命令
調整大對象：縮減大對象數據或把大對象拆分為多個小對象，防止一次命令操作過多的數據。大對象拆分過程需要視具體的業務決定，如用戶好友集合存儲在Redis中，有些熱點用戶會關註大量好友，這時可以按時間或其他維度拆分到多個集合中。

（3）如何發現大對象

Redis本身提供發現大對象的工具。具體命令：

redis-cli -h {ip} -p {port} --bigkeys

內部原理采用分段進行scan操作，把歷史掃描過的最大對象統計出來便於分析優化。

2.2 CPU飽和

單線程的Redis處理命令時只能使用一個CPU。而CPU飽和是指Redis把單核CPU使用率跑到接近100%。使用top命令很容易識別出對應Redis進程的CPU使用率。CPU飽和是非常危險的，將導致Redis無法處理更多的命令，嚴重影響吞吐量和應用方的穩定性。對於這種情況，首先判斷當前Redis的並發量是否達到極限，建議使用統計命令redis-cli -h {ip} -p {port} --stat獲取當前Redis使用情況

2.3 持久化阻塞

對於開啟了持久化功能的Redis節點，需要排查是否是持久化導致的阻塞。

fork阻塞：fork操作發生在RDB和AOF重寫時，Redis主線程調用fork操作產生共享內存的子進程，由子進程完成持久化文件重寫工作。如果fork操作本身耗時過長，必然會導致主線程的阻塞。
AOF刷盤阻塞：當我們開啟AOF持久化功能時，文件刷盤的方式一般采用每秒一次，後臺線程每秒對AOF文件做fsync操作。當硬盤壓力過大時，fsync操作需要等待，直到寫入完成。如果主線程發現距離上一次的fsync成功超過2秒，為了數據安全性它會阻塞直到後臺線程執行fsync操作完成。這種阻塞行為主要是硬盤壓力引起。
HugePage寫操作阻塞：子進程在執行重寫期間利用Linux寫時復制技術降低內存開銷，因此只有寫操作時Redis才復制要修改的內存頁。對於開啟Transparent HugePages的操作系統，每次寫命令引起的復制內存頁單位由4K變為2MB，放大了512倍，會拖慢寫操作的執行時間，導致大量寫操作慢查詢。
三、外在原因

3.1 CPU競爭

進程競爭：Redis是典型的CPU密集型應用，不建議和其他多核CPU密集型服務部署在一起。當其他進程過度消耗CPU時，將嚴重影響Redis吞吐量。可以通過top、sar等命令定位到CPU消耗的時間點和具體進程，這個問題比較容易發現，需要調整服務之間部署結構。
綁定CPU：部署Redis時為了充分利用多核CPU，通常一臺機器部署多個實例。常見的一種優化是把Redis進程綁定到CPU上，用於降低CPU頻繁上下文切換的開銷。這個優化技巧正常情況下沒有問題，但是存在例外情況，當Redis父進程創建子進程進行RDB/AOF重寫時，如果做了CPU綁定，會與父進程共享使用一個CPU。子進程重寫時對單核CPU使用率通常在90%以上，父進程與子進程將產生激烈CPU競爭，極大影響Redis穩定性。因此對於開啟了持久化或參與復制的主節點不建議綁定CPU。

3.2 內存交換

內存交換（swap）對於Redis來說是非常致命的，Redis保證高性能的一個重要前提是所有的數據在內存中。如果操作系統把Redis使用的部分內存換出到硬盤，由於內存與硬盤讀寫速度差幾個數量級，會導致發生交換後的Redis性能急劇下降。

預防內存交換：

保證機器充足的可用內存。
確保所有Redis實例設置最大可用內存（maxmemory），防止極端情況下Redis內存不可控的增長。
降低系統使用swap優先級。
3.3 網絡問題

（1）連接拒絕

網絡閃斷（網絡割接或者帶寬耗盡）
Redis連接拒絕（超過客戶端最大連接數）
連接溢出（進程限制或backlog隊列溢出）
（2）網絡延遲

網絡延遲取決於客戶端到Redis服務器之間的網絡環境。主要包括它們之間的物理拓撲和帶寬占用情況。常見的物理拓撲按網絡延遲由快到慢可分為：同物理機>同機架>跨機架>同機房>同城機房>異地機房。但它們容災性正好相反，同物理機容災性最低而異地機房容災性最高。

網絡延遲問題經常出現在跨機房的部署結構上，對於機房之間延遲比較嚴重的場景需要調整拓撲結構，如把客戶端和Redis部署在同機房或同城機房等。

帶寬瓶頸通常出現在以下幾個方面：

機器網卡帶寬。
機架交換機帶寬。
機房之間專線帶寬。
（3）網卡軟中斷

網卡軟中斷是指由於單個網卡隊列只能使用一個CPU，高並發下網卡數據交互都集中在同一個CPU，導致無法充分利用多核CPU的情況。網卡軟中斷瓶頸一般出現在網絡高流量吞吐的場景。

Redis阻塞整理筆記