Redis變慢？深入淺出Redis效能診斷系列文章(一)

 

Redis 作為一款業內使用率最高的記憶體資料庫，其擁有非常高的效能，單節點的QPS壓測能達到18萬以上。但也正因此如此，當應用存取 Redis 時，如果發現響應延遲變大時就會給業務帶來非常大的影響。

比如在日常使用Redis時，肯定或多或少都遇到過下面這種問題：

• 為什麼Redis服務過去一直很穩定，突然從今天某個時間點開始變慢了？
• 為什麼存取Redis相同的命令，有時響應很快，有時卻非常慢？
• 為什麼存取Redis突然卡住了，過一會又自動恢復了，這也導致業務請求出現很多的毛刺？
• 。。。

如果不理解 Redis 的架構體系、核心功能的實現原理甚至一些命令的使用限制等，那麼這種存取變慢問題的排查就會一頭霧水，不知道從哪裡下手才好。

本文基於多年使用和運維管理Redis的經驗，詳細梳理了可能引起Redis效能問題的原因並剖析對應的解決方案，也希望這一系列的文章能幫助大家更加合理的使用 Redis ，快速的定位並解決問題。

 

一、Redis存取架構鏈路分析

首先，在深入分析Redis服務前，需要弄清楚是不是真的Redis存取變慢了。

如果我們發現自己的應用服務響應延遲變長，我們首先要排查應用內部，確認是不是存取Redis路徑變慢進而拖慢了整個服務的響應吞吐。

這裡有兩個比較關鍵的自查：

• 對於應用服務存取Redis的請求，記錄下每次請求的響應延時（比如使用分散式鏈路跟蹤系統等），看看是不是存取Redis響應時間變長了；
• 排查應用服務的多個節點，看看是不是每個節點都有問題，還是僅僅一個出現了問題。

這兩個是後續深入分析Redis服務問題前的關鍵自查，事半功倍！

 

對於第一點從應用到Redis這條鏈路變慢的原因可能有如下兩個：

• 應用到Redis服務之間的鏈路出現問題了，比如Redis所在伺服器網路負載過高丟包、交換機問題、Proxy變慢等；
• Redis本身確實因為一些原因變慢了。

一般伺服器層面都會有相關監控，網路的問題很容易就會發現，比如網路卡打滿、網路卡降頻【萬兆降為千兆】等。

 

對於Redis存取鏈路的響應時間則可以做個模擬監控，如下Redis存取架構，應用程式經過域名系統、VIP系統，最後才到Redis所在的伺服器，這種情況下則分別可以模擬 請求域名、請求VIP、請求直連Redis Server三條路徑來評估響應時間是否確實變長了。

 下面是另外一種Redis架構，存取路徑又有不同，那麼排查的方向也不會不同。

二、Redis效能基準測評

如果核查發現確實是請求Redis的服務響應耗時變長了，那麼此刻就可以把問題分析的焦點放到Redis上了。

下面我們重點分析下Redis效能問題。

首先，需要對 Redis 進行基準的效能測試，瞭解我們的 Redis 服務在當前環境伺服器上的基準效能。

什麼是基準效能？

簡單來講，基準效能就是指在一臺負載正常的伺服器上，存取Redis的最大的響應延遲和平均響應延遲分別是怎樣的？

為什麼要測試基準效能？參考官方提供的響應延遲測試，來判斷自己的 Redis服務是否變慢不行嗎？

答案是不行的。

因為Redis 在不同的軟硬體環境下，它的效能表現差別特別大，不同主頻型號的CPU、不同的SSD硬碟，都會極大影響Redis的效能表現。伺服器設定比較低時延遲為 10ms 時，才認為 Redis響應變慢了，但是如果設定比較高，那麼可能延遲是 1ms 時就可以認為 Redis 變慢了。

 

所以，只有瞭解我們的 Redis 在生產環境伺服器上的基準效能，才能進一步評估，當其延遲達到什麼程度時，才認為 Redis 確實變慢了。

 

Redis自帶的工具可以幫助我們完成這種測評，如下介紹兩種基準效能測試的方式。

方式一：redis-cli --intrinsic-latency

為了避免業務測試伺服器到 Redis 伺服器之間的網路延遲，需要直接在 Redis 伺服器上測試範例的響應延遲情況。執行以下命令，就可以測試出這個範例 120 秒內的最大響應延遲：

 

shell> redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 120

Max latency so far: 4 microseconds.

Max latency so far: 5 microseconds.

Max latency so far: 15 microseconds.

Max latency so far: 23 microseconds.

Max latency so far: 64 microseconds.

Max latency so far: 196 microseconds.

Max latency so far: 245 microseconds.

Max latency so far: 246 microseconds.

Max latency so far: 254 microseconds.

Max latency so far: 259 microseconds.

29298480 total runs (avg latency: 4.0958 microseconds / 40957.76 nanoseconds per run).

Worst run took 63x longer than the average latency.

從輸出結果可以看到，這 120 秒內的最大響應延遲為 259 微秒（0.259毫秒）。

 

方式二：redis-benchmark

Redis-benchmark是Redis官方自帶的Redis效能測試工具，可以有效的測試Redis服務的效能.

 

shell> redis-benchmark -h 127.0.0.1 -p 6379 -t set,get -c 500 -n 100000

====== SET ======

100000 requests completed in 1.02 seconds

500 parallel clients

3 bytes payload

keep alive: 1

 

0.00% <= 1 milliseconds

0.05% <= 2 milliseconds

99.09% <= 3 milliseconds

99.88% <= 4 milliseconds

100.00% <= 4 milliseconds

97847.36 requests per second

 

====== GET ======

100000 requests completed in 1.02 seconds

500 parallel clients

3 bytes payload

keep alive: 1

 

0.00% <= 1 milliseconds

0.05% <= 2 milliseconds

99.29% <= 3 milliseconds

99.92% <= 4 milliseconds

100.00% <= 4 milliseconds

97656.24 requests per second

該命令對set和get命令的操作響應時間進行測評，並行500個執行10w次操作，從輸出結果可以看到，set的QPS達到了97847，響應時間都在4ms以內；get的QPS達到了97656，最大響應時間也在4ms以內；

瞭解了基準效能測試方法，那麼我們就可以按照以下幾步，來判斷 Redis 是否真的變慢了：

• 在相同設定的伺服器上，測試一個正常 Redis 範例的基準效能
• 找到可能變慢的 Redis 範例，測試這個範例的基準效能
• 對比這個範例的執行延遲與正常 Redis 基準效能，如果效能差距在兩倍以上，就可以認為這個 Redis 服務確實響應變慢了 

如果確認是 Redis服務變慢了，那如何排查是哪裡發生了問題呢？後面的系列文章將從多個維度來一步步詳細分析，歡迎關注。

 

如果你還想看更多優質文章，歡迎關注我的公號「資料庫架構師」，提升資料庫技能。

如果我的文章對你有所幫助，還請幫忙點贊、在看、轉發一下，你的支援會激勵我輸出更高質量的文章，非常感謝！