作者 | 不才陳某 責編 | 張文
頭圖 | CSDN 下載自視覺中國
來源 | 碼猿技術專欄（ID：oneswholife）
前言
眾所周知 Redis 是單線程，有著極快的響應速度，但是有一天 Redis 突然變"慢"了，運維甚至開發都慌了，開始一系列的騷操作了，但是一點效果都沒有，why？
遇到問題不要慌。首先需要確定的是：Redis真的變慢了嗎？
今天陳某就來介紹下以什麼標準為基線判斷Redis變慢了？
Redis真的變慢了？
我們知道一個應用程式在伺服器上運行，它的運行快慢和硬體乃至底層作業系統都有巨大的關係，因此 Redis 響應慢了就真的是 Redis 的鍋？
如何判斷 Redis 是不是真的變慢了？一個最直接方法：查看Redis響應延遲
大部分情況下 Redis 的延遲很低，但是在某些時刻延遲突然很高，當你發現Redis 命令的執行時間突然增長到幾秒，基本就可以認定 Redis 變慢了。
但是不同的軟硬體環境下，延遲時間的標準卻是大相逕庭，比如在伺服器 A 上延遲為 1s 時基本就能判定 Redis 變慢了，在較好配置的伺服器 B 上甚至延遲10ms 就可以判定 Redis 變慢了。
顯然上述的標準很難判斷，此時只能通過 Redis 基線性能來判斷。
基線性能：系統在低壓力、無幹擾下的基本性能，這個性能只由當前的軟體配置決定。
那麼如何確定這個基線性能呢？很多人疑惑了？
從 2.8.7 版本開始，redis-cli 命令提供了–intrinsic-latency 選項，可以用來監測和統計測試期間內的最大延遲，這個延遲可以作為 Redis 的基線性能。其中，測試時長可以用–intrinsic-latency 選項的參數來指定（一般情況下 120s足夠監測到最大延遲了）。
本機測試（未通過客戶端）的監測命令如下：
redis-cli --intrinsic-latency 120Max latency so far: 1 microseconds.Max latency so far: 9 microseconds.Max latency so far: 11 microseconds.Max latency so far: 29 microseconds.Max latency so far: 34 microseconds.Max latency so far: 36 microseconds.Max latency so far: 42 microseconds.Max latency so far: 44 microseconds.Max latency so far: 62 microseconds.Max latency so far: 599 microseconds.Max latency so far: 613 microseconds.Max latency so far: 8158 microseconds.Max latency so far: 13426 microseconds.Max latency so far: 16073 microseconds.Max latency so far: 19587 microseconds.Max latency so far: 22988 microseconds.1982697419 total runs (avg latency: 0.0605 microseconds / 605.24 nanoseconds per run).Worst run took 379819x longer than the average latency.
發現最大的延遲 22988 微秒，因此這裡的基線性能為 22988 微秒。
基線性能只和作業系統、硬體配置相關，因此這裡可以結合基線性能判斷 Redis是否真的變慢了？
一般運行時延遲達到基線性能的 2 倍以上則可判定 Redis 變慢了。
注意：基線性能非常重要，尤其對於虛擬化的環境（虛擬機、容器），他們的基線性能相對很高，因此結合基線性能判斷是必要的。
切記：一定要在本機上運行測試命令，如果通過客戶端則需要考慮網絡性能的影響。
現在有很多網絡性能的測量工具，比如 iperf，如果發現網絡阻塞了，此時就需要聯絡公司的網絡工程師了。
總結
本文介紹了如何判斷 Redis 變慢的標準，即是基線性能。只有結合基線性能和運行延遲相對比，大概超過 2 倍以上則可判斷 Redis 真的變慢了。