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

Redis 響應(yīng)時長排查思路

Redis 的核心優(yōu)勢之一就是高性能。在沒有大 Key和熱 Key的情況下，響應(yīng)速度通常非?？?。但如果出現(xiàn)異常，尤其是響應(yīng)時長過高，我們需要仔細(xì)排查。以下是一些關(guān)鍵點(diǎn)：

1. 正常情況下的響應(yīng)時長

• 量化指標(biāo)：

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

調(diào)用端指標(biāo)上報中，一般會在 2ms 以內(nèi)，即使是同城跨區(qū)訪問，時延增加也不過 1ms。

• 異常判斷：

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

2. 可能的性能瓶頸

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

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

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

1. 連接數(shù)配置

• 單節(jié)點(diǎn)模式：

調(diào)用端每個 CPU 核心維護(hù) 10 個連接。假設(shè)是 4 核 CPU，總共就是 40 個連接。

• 集群模式：

調(diào)用端每個 CPU 核心對每個分片維護(hù) 5 個連接。假設(shè)有 2 個分片，4 核 CPU，總共至少 40 個連接。

2. QPS 計算公式

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

• 單節(jié)點(diǎn) Redis：

• 調(diào)用端每個核對應(yīng) 10 個連接。假設(shè)是 4 核 CPU，總共就是 40 個連接。

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

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

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

總結(jié)與建議

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