Redis阻塞原因詳解

發現阻塞

線上應用服務最先感知到，可在應用方加入異常統計並透過郵件、簡訊、微信警報。

借助日誌系統，統計異常和觸發警報邏輯

借助Redis監控系統發現阻塞問題，觸發警報。推薦CacheCloud系統。

內在原因

API或資料結構使用不合理

對於高並發場景，避免在大物件上執行演算法複雜度超過O(n)O(n)的命令。

發現慢查詢：slowlog get {n}

發現大物件：redis-cli -h{ip} -p{port} bigkeys

##CPU飽和

CPU飽和指redis把單核心CPU跑到100%。

top指令查看redis程式CPU使用率

redis-cli -h{ip} -p{port} –stat取得目前redis使用情況，判斷並發是否達到極限

info commandstats 分析指令不合理開銷時間，可能過度記憶體最佳化

持久化阻塞

1、fork阻斷

發生在RDB或AOF重寫時，redis主執行緒呼叫fork產生子程序完成持久化檔案重寫

使用info stats指令取得lastest_fork_usec指標，表示redis最近一次fork操作耗時

2、AOF刷盤阻塞

開啟AOF，檔案刷盤一般每秒一次，硬碟壓力過大時，fsync需要等待寫入完成

查看redis日誌或info persistence統計中的aof_delayed_fsync指標

可使用iotop差可能哪個程序消耗過多的硬碟資源

3、HugePage寫操作阻塞

對於開啟Transparent HugePages的作業系統，每次寫入指令所引起的複製記憶體頁單位由4KB變成2MB

會拖慢寫入操作的執行時間，導致大量寫入操作慢查詢

外在原因

CPU競賽

1、進程競爭：redis是典型的CPU密集型應用程式。使用top、sar指令定位CPU消耗的時間點和行程

2、綁定CPU：常見最佳化是把redis行程綁定到CPU上，較低CPU上下文切換開銷，如果fork子程序做了CPU綁定，則父子程序存在激烈的CPU競爭，極大影響redis穩定性。

記憶體交換

如果作業系統把redis使用的記憶體換出到硬碟上，會導致交換後的redis效能急遽下降。

識別redis記憶體交換的檢查方法：

1、查詢redis進程號

redis-cli info server | grep process_id

2、根據進程號查詢記憶體交換資訊

cat /proc/{process_id}/smaps | grep Swap

如果交換量都是0KB或個別4KB，是正常現象。

預防記憶體交換：

1、確保機器充足的可用記憶體

2、確保所有redis範例設定最大可用記憶體(maxmemory)，防止極端情況下redis內存不可控的成長

3、降低系統使用swap優先權，如echo 10>/proc/sys/vm/swappiness

網路問題

#1、連線拒絕

網路閃斷：一般在網路割接或頻寬耗盡的情況

redis連線拒絕：

連線數大於maxclients時拒絕新的連線進入，info stats的rejected_connections指標

客戶端存取redis盡量採用NIO長連線或連線池的方式

redis用於大量分散式節點存取且生命週期較短的場景(如Map/Reduce)時，建議設定tcp-keepalive和timeout參數讓redis主動檢查和關閉無效連線

連線溢位：

進程限制：進程可開啟最大檔案數控制,ulimit -n，通常1024，大量連接的redis需要增加該值

backlog隊列溢出：系統對於特定端口tcp連接使用backlog隊列保存，redis預設511，系統backlog預設128，線上可使用cron定時執行netstat -s | grep overflowed統計

2、網路延遲

#測量機器之間網路延遲

redis-cli -h{ip} -p{port} –latency
redis-cli -h{ip} -p{port} –latency-history 默认15秒完成一行统计，-i控制采样时间
redis-cli -h{ip} -p{port} –latency-dist 统计图展示，每1秒采样一次

3、網路卡軟體中斷

#單一網路卡佇列只能使用一個CPU，高併發下網卡資料互動都集中在同一個CPU，導致無法充分利用多核心CPU的情況。

一般出現在網路高流量吞吐的場景

更多redis知識請關注

redis入門教學專欄。

以上是Redis阻塞原因詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！