go-zero 社區核心貢獻者 Mikael（go-zero-looklook  作者）找我溝通了一個關于 Redis 的問題。在解決后，我意識到，社區中很多同學可能也會遇到類似的問題。因此，抽空總結了一些關于 Redis 響應時長和 QPS 評估的經驗，希望對大家有所幫助。

Redis 響應時長排查思路

Redis 的核心優勢之一就是高性能。在沒有大 Key和熱 Key的情況下，響應速度通常非?？?。但如果出現異常，尤其是響應時長過高，我們需要仔細排查。以下是一些關鍵點：

1. 正常情況下的響應時長

• 量化指標：

Redis 在正常情況下處理請求時長通常低于 1ms。

調用端指標上報中，一般會在 2ms 以內，即使是同城跨區訪問，時延增加也不過 1ms。

• 異常判斷：

• 如果響應時長（均值或 P99）超過 10ms，就需要開始排查原因。

2. 可能的性能瓶頸

• 大 Key 或熱 Key：單次請求操作的數據量過大，導致 Redis 處理時間變長。
• CPU 負載過高：CPU 占用過高會直接影響性能。
• 內存淘汰機制：內存即將耗盡時，Redis 會進行數據淘汰，導致響應變慢。
• 大范圍查詢：如使用 SCAN、SORT 等命令，會觸發較大的數據遍歷。
• 連接數過多：Redis 連接過載，可能引發排隊等待，影響響應速度。

Redis 客戶端可承載 QPS 計算方法

在 go-zero 中，使用了官方庫 go-redis。這里按照 Redis 的部署模式，分別探討單節點和集群模式下的 QPS 計算。

1. 連接數配置

• 單節點模式：

調用端每個 CPU 核心維護 10 個連接。假設是 4 核 CPU，總共就是 40 個連接。

• 集群模式：

調用端每個 CPU 核心對每個分片維護 5 個連接。假設有 2 個分片，4 核 CPU，總共至少 40 個連接。

2. QPS 計算公式

假設每個請求的平均處理時長為 2ms（包含網絡延遲），那么單個連接每秒可處理 500 個請求。按照上面的連接數：

• 單節點 Redis：

• 調用端每個核對應 10 個連接。假設是 4 核 CPU，總共就是 40 個連接。

• 集群模式（至少兩分片）：

• 調用端每個核對應每個分片 5 個連接，每個分片至少提供 10,000 QPS 的處理能力（如果是用來限流或者熱 key 則可能請求打在單分片上）。

這種計算雖然粗略，但基本能夠作為評估依據。如果遇到 Redis 連接數不足的問題，可以按照上述方法進行自查，分析瓶頸所在。

總結與建議

遇到 Redis 性能問題時，不能簡單地通過增加連接數來解決。我們需要深入分析根因，定位到具體問題，找到真正的瓶頸。提升系統性能的關鍵在于理解 Redis 的工作機制，并針對性優化。