Redis深刻學習筆記（五）Redis阻塞緣由

在實際使用Redis中，有時會碰到客戶端timeout異常，或者沒有可用鏈接異常等等異常，總結大概有以下緣由：

 

內部阻塞緣由：

　　1）大對象存取。

　　2）Fork阻塞。

　　3）Aof刷盤阻塞（距離上次刷盤大於2s時主線程會阻塞，直到當前刷盤完成）。

　　4）HugePage寫操做阻塞（對於開啓Transparent HugePages的操做系統，每次寫命令引發的複製內存頁單位由4K變爲2MB，放大了512倍，會拖慢寫操做的執行時間，致使大量寫操做慢查詢）。

 

外部阻塞緣由：

　　1）與其餘cpu密集型應用一塊兒部署，出現cpu競爭。

　　2）啓用持久化時將redis進程與cpu綁定，子進程與父進程公用一個cpu,子進程進行持久化時會大幅度佔用cpu資源（一般90%），形成父進程cpu資源不足。

　　3）內存交換（太小的最大內存設置，會發生內存交換，將內存數據寫到磁盤上，性能殺手）。

 　　4）客戶端鏈接過多。當Redis用於大量分佈式節點訪問且生命週期比較短的場景時，如比較典型的在Map/Reduce中使用Redis。由於客戶端服務存在頻繁啓動和銷燬的狀況且默認Redis不會主動關閉長時間閒置鏈接或檢查關閉無效的TCP鏈接，所以會致使Redis鏈接數快速消耗且沒法釋放的問題。這種場景下建議設置tcp-keepalive和timeout參數讓Redis主動檢查和關閉無效鏈接（客戶端使用單例或者鏈接池方式）。

 　　5）半鏈接隊列太小。系統對於特定端口的TCP鏈接使用backlog隊列保存。Redis默認的長度爲511，經過tcp-backlog參數設置。若是Redis用於高併發場景爲了防止緩慢鏈接佔用，可適當增大這個設置，但必須大於操做系統容許值才能生效。當Redis啓動時若是tcp-backlog設置大於系統容許值將以系統值爲準。使用echo511>/proc/sys/net/core/somaxconn命令進行修改。能夠經過netstat-s命令獲取因backlog隊列溢出形成的鏈接拒絕統計。

　　6）網絡延遲。Redis提供了測量機器之間網絡延遲的工具，在redis-cli-h{host}-p{port}命令後面加入以下參:

　　數進行延遲測試：

　　　　--latency：持續進行延遲測試，分別統計：最小值、最大值、平均值、採樣次數。

　　　　--latency-history：統計結果同--latency，但默認每15秒完成一行統計，可經過-i參數控制採樣時間。

　　　　--latency-dist：使用統計圖的形式展現延遲統計，每1秒採樣一次。

 

　　排查並明確緣由後能夠針對性的對Redis進行優化，增長服務吞吐量。

 

　　下一篇會介紹Redis內存分配相關。