單一介面優化過程全記錄（主要涉及Redis）
介面優化過程記錄
問題背景
某個介面耗時長（247ms），但裡面邏輯不算複雜，只進行了簡單的物件引用以及操作了多次Redis
步驟1：鏈路追蹤，確定業務耗時點
接口裡通過鏈路追蹤以及日誌查詢發現主要是操作Redis的這條鏈路耗時變長
步驟2：從Redis找問題，列出可能點
原因可能是：
- Redis本身存在問題，可能是命令複雜度、IO、連線數不夠、過載等
- 網路原因，獲取連線或者是資料傳輸耗時
經測試發現以下這些問題
-
使用本機ping伺服器，網路延遲大概在42ms（ping內網<1ms，ping公司線上環境7ms），屬於 高延遲
-
內部邏輯對獲取Redis連線進行耗時記錄，發現除首次獲取連線需30ms，後續獲取連線耗時 <1ms,
-
內部對Redis的一個get操作需要47ms（高耗時）
步驟二總結：
- 呼叫方與客戶端的網路高延遲
- 普通的get操作需要47ms不排除Redis本身存在問題，需要繼續排查
步驟3：從Redis內部排查
3.1從伺服器內部檢視延遲峰值
由於Redis是使用Docker搭建，在虛擬化環境可能會差一些，不過還是先檢視延遲峰值以及平均響應時 間
100秒內測試結果
60秒內測試結果
從測試資料可以看出
- 在100秒時，最大延遲為16ms，處理了1,762,165,232次命令平均響應時間為0.053ms
- 在60秒時，最大延遲為14ms，處理了1,066,484,486次命令平均響應時間為0.056ms
總結：從這一測試資料看單一get命令是不會到40+ms
3.2設定慢命令時間
通過給Redis設定slowlog時間為5ms，從業務程式碼裡操作set和get命令各200條，均無發現slowlog。
3.3命令複雜度過高（略）
接口裡使用的命令只是簡單的get，set操作，並不是SORT、SUNION等聚合類容易導致操作延遲變大的 命令。
且O(N)裡的N值並不大，也不需要花費很多時間在資料協議的組裝和網路傳輸過程中。
所以該指標不做測試。⚠ Ps:若是想測試該指標也可用slowlog進行排查。
3.4bigkey（略）
接口裡操作的都不是bigkey，該指標不做測試。有需要可先使用redis命令掃描bigkey。注意：掃描時與 上述提到的延遲峰值都會使Redis的OPS突增。
3.5集中過期（略）
該Redis裡並沒有過多資料，該指標不做測試。
3.6例項記憶體達到上限
從資料上來看，記憶體並沒有使用很多。
3.7fork耗時嚴重（略）
如3.5中所說，該指標不做測試
3.8連線數問題
從springboot裡使用了nio開發的lettuce Redis執行緒池，當設定連線數為500時，在程式碼層面開啟多個線 程一直跑，Redis客戶端連線數可以達到峰值，所以這塊暫時沒有問題。
暫時總結
根據上述資料總結出99%是網路問題造成的獲取資料延遲。當然還有很多指標都沒有列舉，例如：是否 開啟記憶體大頁、是否開啟AOF造成Redis、或者是是否使用Swap等。由於伺服器的Redis也算比較簡 單，這些也就預設是正常了
後續執行
後續可以再繼續監控
- 觀察連線數，是否有頻繁的短連線消耗
- 以及對Redis的各個指標進行監控