介面優化程序記錄
問題背景
某個介面耗時長（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的各個指標進行監控
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/539298.html
標籤：Java
上一篇：JAVA里Map的一些常用方法