：排查CPU使用率高的問題

尋找並禁用高消耗命令

高消耗命令：即時間複雜度為O(N)或更高的命令。通常情況下，命令的時間複雜度越高，在執行時會消耗較多的資源，從而導致CPU使用率上升。關於各命令對應的時間複雜度資訊，請參見Redis官網。

由於單線程的特性，Tair在執行高消耗命令時會引發排隊導致應用響應變慢。極端情況下，甚至可能導致執行個體被整體阻塞，引發應用逾時中斷或流量跳過緩衝層直接到達後端的資料庫側，引發雪崩效應。

1. 通過效能監控功能，確認CPU使用率高的具體時間段。具體操作，請參見查看效能監控。
2. 通過下述方法，找出高消耗的命令：
   • 審計日誌功能會記錄對Tair資料執行的修改和刪除操作資訊，通過分析指定時間段內的命令及趨勢，可協助您找出高消耗的命令。具體操作，請參見查詢審計日誌。

     圖 1. 審計日誌查詢樣本

   • 慢日誌功能會記錄執行超過指定時間閾值的命令，通過分析慢日誌的語句和執行時間長度可協助您找出高消耗命令。具體操作，請參見查詢慢日誌。

     圖 2. 慢日誌查詢樣本

     說明 執行時間長度的單位為微秒。
3. 評估並禁用高風險命令和高消耗命令，例如FLUSHALL、KEYS、HGETALL等。具體操作，請參見禁用高風險命令。
4. 最佳化業務，例如避免頻繁執行資料排序操作。
5. 可選：根據業務情況，選擇下述方法對執行個體進行調整：
   • 調整執行個體為讀寫分離架構，對高消耗命令或應用進行分流。
   • 調整執行個體為記憶體型，利用其多線程的特性降低CPU使用率。
   說明 關於如何變更執行個體的架構和類型，請參見變更執行個體配置。

最佳化熱點Key

現象：

Tair執行個體為叢集架構或讀寫分離架構，執行個體中部分資料節點的CPU使用率高。

解決方案：

• 啟用代理查詢快取功能（Proxy Query Cache），代理節點會緩衝熱點Key對應的請求和查詢結果，當在有效時間內收到同樣的請求時直接返回結果至用戶端，無需和後端的資料分區互動，可改善對熱點Key的發起大量讀請求導致的訪問傾斜。更多資訊，請參見通過Proxy Query Cache最佳化熱點Key問題。
  說明 僅叢集架構的記憶體型執行個體支援該功能。
• 在分析相應節點的慢日誌和審計日誌的基礎上，再分析各節點的熱點Key，從而消除或緩解熱點Key。具體操作，請參見即時Top Key統計。

最佳化短串連

現象：

頻繁地建立串連，導致Tair執行個體的大量資源消耗在串連處理上。具體表現為CPU使用率較高，串連數較高，但QPS（每秒訪問次數）未達到預期的情況。

解決方案：

• 將短串連調整為長串連，例如使用JedisPool串連池串連。具體操作，請參見TairJedis。
• 調整執行個體為記憶體型（具備短串連最佳化特性）。

關閉AOF

現象：

Tair執行個體預設開啟了AOF（append-only file），當執行個體處於高負載狀態時，頻繁地執行AOF會一定程度上導致CPU使用率升高。

解決方案：

在業務允許的前提下，您可以考慮關閉持久化。另外將Tair資料備份時間設定到低訪問/維護時間視窗內，降低影響。

最佳化Proxy節點串連與管道的使用

現象：

Tair執行個體為叢集架構或讀寫分離架構，通過控制台的效能趨勢查看Proxy節點的CPU使用率不均衡，差額過大。

解決方案：

1. 通過效能趨勢功能，確認串連使用率是否均衡。具體操作，請參見效能趨勢。
2. 根據串連使用率是否均衡，選擇下述操作：
   • 均衡：重啟業務所屬的用戶端或Proxy節點使串連重分配。
   • 不均衡：通常因pipeline或batch的操作規模過大引起，需要減少對應的操作規模，例如將其拆分為多個操作來執行。

評估服務能力

經過上述方法最佳化後，在業務正常啟動並執行情況下，還是經常遇到執行個體整體的負載較高（平均CPU使用率在50%以上），可能存在效能瓶頸。

首先，應排查是否存在異常的業務訪問，例如異常的命令、來自某台應用主機的異常訪問等，此類情況需要從業務上進行最佳化。如果均為正常訪問，此時的高負載是正常業務行為，為保障業務平穩運行，建議升級執行個體的規格，將其升級為叢集架構或讀寫分離架構。關於如何升級執行個體，請參見變更執行個體配置。