Tair（以及Redis開源版）執行個體的CPU使用率升高可能是由於以下三種原因：高並發、高吞吐的業務消耗較多CPU資源，如果CPU資源未達到瓶頸，屬於正常業務情境；業務運行超預期，Redis開源版執行個體的CPU資源無法滿足業務需求，可通過增加分區數、副本數或者升級為Tair（企業版）來解決資源瓶頸；使用不當，例如高消耗命令、熱Key、大Key等，導致CPU使用率異常升高。當平均CPU使用率高於70%、連續5分鐘內的CPU平均峰值使用率高於90%時，您需要及時關注並排查該問題，以保障應用的穩定運行。
哪些因素會導致CPU使用率異常升高
高消耗命令：即時間複雜度為O(N)的命令，其中N為較大值，例如KEYS、HGETALL或使用MGET、MSET、HMSET、HMGET一次操作大量Key等。通常情況下，命令的時間複雜度越高，在執行時會消耗越多的資源，從而導致CPU使用率上升。
由於命令執行單元為單線程的特性，執行個體在執行高消耗命令時會引發排隊導致應用響應變慢。極端情況下，甚至可能導致執行個體被整體阻塞，引發應用逾時中斷或流量跳過緩衝層直接到達後端的資料庫側，引發雪崩效應。
說明關於各命令對應的時間複雜度資訊，請參見Redis官網。
熱Key：某個或某部分Key的請求訪問次數顯著超過其他Key時，代表此時可能產生了熱Key。熱Key將會消耗執行個體的大量CPU資源，從而影響其他Key的訪問時延。並且，在叢集架構中，如果熱Key較為集中地分布在部分資料分區節點，可能會導致CPU使用率傾斜（個別分區的CPU使用率遠超其他分區）。
大Key：大Key會佔用更多的記憶體，同時，對大Key的訪問會顯著增加執行個體的CPU負載和流量。大Key在一定程度上更容易形成熱點從而造成CPU使用率高。如果大Key較為集中地分布在部分資料分區節點，可能會導致CPU使用率傾斜、頻寬使用率傾斜及記憶體使用量率傾斜。
短串連：頻繁地建立串連，導致執行個體的大量資源消耗在串連處理上。
AOF：執行個體預設開啟了AOF（append-only file），當執行個體處於高負載狀態時，AOF的寫盤行為將會導致CPU使用率升高及執行個體整體的響應時延增加。
CPU使用率異常升高的現象分類
CPU使用率高，主要分為以下三種現象：
在某個時間段，CPU使用率突然升高，甚至到100%。原因排查和解決方案，請參見CPU使用率突然升高。
某個資料節點的CPU使用率較高，而其他資料節點的CPU使用率較低。原因排查和解決方案，請參見資料節點CPU使用率不一致。
某個Proxy節點的CPU使用率較高，而其他Proxy節點的CPU使用率較低。原因排查和解決方案，請參見代理節點CPU使用率不一致。
請根據不同現象，分別採取措施降低CPU使用率。
CPU使用率突然升高
如果執行個體全域的CPU使用率升高，可參考以下步驟排查並最佳化。
排查並禁用高消耗命令
排查步驟
通過效能監控功能，確認CPU使用率高的具體時間段。具體操作，請參見查看效能監控。
通過下述方法，找出高消耗的命令：
解決辦法
評估並禁用高風險命令和高消耗命令，例如FLUSHALL、KEYS、HGETALL等。具體操作，請參見禁用高風險命令。
可選：根據業務情況，選擇下述方法對執行個體進行調整：
說明如何變更執行個體的架構和類型，請參見變更執行個體配置。
排查並最佳化短串連
排查步驟
通過效能監控功能，確認CPU使用率高的具體時間段。具體操作，請參見查看效能監控。
在效能監控頁面，查看是否有CPU使用率較高，串連數較高，但QPS（每秒訪問次數）未達到預期的現象。如果有，說明可能存在短串連，請參考下文的解決方案。
解決方案
關閉AOF
執行個體預設開啟了AOF（append-only file），當執行個體處於高負載狀態時，頻繁地執行AOF會一定程度上導致CPU使用率升高。
在業務允許的前提下，您可以考慮關閉持久化。另外將執行個體的資料備份時間設定到低訪問/維護時間視窗內，降低影響。
如果您的執行個體為Tair記憶體型，關閉AOF後，您將無法通過AOF檔案恢複資料（即無法使用資料閃回功能），僅能通過備份組恢複資料（即從備份組恢複至新執行個體），請謹慎操作。
評估服務能力
經過上文的步驟排查最佳化後，在業務正常啟動並執行情況下，還是經常遇到執行個體整體的負載較高（平均CPU使用率在70%以上），可能存在效能瓶頸。
首先，應排查是否存在異常的業務訪問，例如異常的命令、來自某台應用主機的異常訪問等，此類情況需要從業務上進行最佳化。如果均為正常訪問，此時的高負載是正常業務行為，為保障業務平穩運行，建議升級執行個體的規格，或將其升級為叢集架構或讀寫分離架構。關於如何升級執行個體，請參見變更執行個體配置。
為保障業務的正常運行，在正式升級執行個體前，建議先購買一個隨用隨付的執行個體，完成業務負載和相容性測試，測試完成後可將其釋放。
資料節點CPU使用率不一致
如果執行個體為叢集架構或讀寫分離架構，您發現執行個體的部分資料分區節點的CPU使用率高，而其他資料分區節點的CPU使用率較低，可參考以下步驟排查並最佳化。
排查並最佳化熱點Key
排查步驟
通過效能監控功能，確認CPU使用率高的具體時間段。具體操作，請參見查看效能監控。
在即時Top Key統計的歷史頁面，選擇CPU使用率高的資料節點，然後根據步驟1，選擇時間篩選條件，單擊查看，可看到CPU使用率高的時間段內有哪些熱點Key。具體操作，請參見即時Top Key統計。
解決方案
啟用代理查詢快取功能（Proxy Query Cache），代理節點會緩衝熱點Key對應的請求和查詢結果，當在有效時間內收到同樣的請求時直接返回結果至用戶端，無需和後端的資料分區互動，可改善對熱點Key的發起大量讀請求導致的訪問傾斜。通過Proxy Query Cache最佳化熱點Key問題。
如果熱Key的產生來自於讀請求，您可以將執行個體改造成讀寫分離架構來降低每個資料分區的讀請求壓力。
說明在請求量極大的情境下，讀寫分離架構會產生不可避免的延遲，此時會有讀取到髒資料的問題。因此，在讀、寫壓力都較大且對資料一致性要求很高的情境下，讀寫分離架構並不是最優方案。
排查並禁用高消耗命令
排查步驟
通過效能監控功能，確認CPU使用率高的具體時間段。具體操作，請參見查看效能監控。
通過下述方法，找出高消耗的命令：
解決辦法
評估並禁用高風險命令和高消耗命令，例如FLUSHALL、KEYS、HGETALL等。具體操作，請參見禁用高風險命令。
排查並最佳化大Key
排查步驟
通過效能監控功能，確認CPU使用率高的具體時間段。具體操作，請參見查看效能監控。
在離線全量Key分析的頁面，單擊立即分析。選擇CPU使用率高的資料節點，單擊確定，可看到CPU使用率高的時間段內有哪些大Key。具體操作，請參見離線全量Key分析。
解決方案
根據業務的實際情況，將大Key拆分為小Key，以分散請求壓力。
代理節點CPU使用率不一致
如果執行個體為叢集架構或讀寫分離架構，您發現執行個體的部分Proxy節點的CPU使用率高，而其他代理分區節點的CPU使用率較低，可參考以下步驟排查並最佳化。
排查步驟
在效能趨勢的代理節點頁面，確認串連數使用率是否均衡。具體操作，請參見效能趨勢。
解決方案
根據串連數使用率是否均衡，採取下述措施：
均衡：重啟業務所屬的用戶端或Proxy節點使串連重分配。重啟Proxy節點，請參見重啟或重搭代理節點。
不均衡：通常因pipeline或batch的操作規模過大引起，需要減少對應的操作規模，例如將其拆分為多個操作來執行。