Redis為什么會出現阻塞

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出現阻塞的原因就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。章！