本文中含有需要您注意的重要提示信息，忽略該信息可能對您的業務造成影響，請務必仔細閱讀。
Tair（包含Redis開源版）實例的CPU使用率升高可能是由于以下三種原因：高并發、高吞吐的業務消耗較多CPU資源，如果CPU資源未達到瓶頸，屬于正常業務場景；業務運行超預期，Tair實例的CPU資源無法滿足業務需求，可通過增加分片數、副本數或者升級為Tair（企業版）來解決資源瓶頸；使用不當，例如高消耗命令、熱Key、大Key等，導致CPU使用率異常升高。當平均CPU使用率高于70%、連續5分鐘內的CPU平均峰值使用率高于90%時，您需要及時關注并排查該問題，以保障應用的穩定運行。
哪些因素會導致CPU使用率異常升高
高消耗命令：即時間復雜度為O(N)的命令，其中N為較大值，例如KEYS、HGETALL或使用MGET、MSET、HMSET、HMGET一次操作大量Key等。通常情況下，命令的時間復雜度越高，在執行時會消耗越多的資源，從而導致CPU使用率上升。
由于命令執行單元為單線程的特性，Tair在執行高消耗命令時會引發排隊導致應用響應變慢。極端情況下，甚至可能導致實例被整體阻塞，引發應用超時中斷或流量跳過緩存層直接到達后端的數據庫側，引發雪崩效應。
說明關于各命令對應的時間復雜度信息，請參見Redis官網。
熱Key：某個或某部分Key的請求訪問次數顯著超過其他Key時，代表此時可能產生了熱Key。熱Key將會消耗Tair的大量CPU資源，從而影響其他Key的訪問時延。并且，在集群架構中，如果熱Key較為集中地分布在部分數據分片節點，可能會導致CPU使用率傾斜（個別分片的CPU使用率遠超其他分片）。
大Key：大Key會占用更多的內存，同時，對大Key的訪問會顯著增加Tair的CPU負載和流量。大Key在一定程度上更容易形成熱點從而造成CPU使用率高。如果大Key較為集中地分布在部分數據分片節點，可能會導致CPU使用率傾斜、帶寬使用率傾斜及內存使用率傾斜。
短連接：頻繁地建立連接，導致Tair實例的大量資源消耗在連接處理上。
AOF：Tair實例默認開啟了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
Tair實例默認開啟了AOF（append-only file），當實例處于高負載狀態時，頻繁地執行AOF會一定程度上導致CPU使用率升高。
在業務允許的前提下，您可以考慮關閉持久化。另外將Tair數據備份時間設定到低訪問/維護時間窗口內，降低影響。
如果您的實例為Tair內存型，關閉AOF后，您將無法通過AOF文件恢復Tair數據（即無法使用數據閃回功能），僅能通過備份集恢復數據（即從備份集恢復至新實例），請謹慎操作。
評估服務能力
經過上文的步驟排查優化后，在業務正常運行的情況下，還是經常遇到實例整體的負載較高（平均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的操作規模過大引起，需要減少對應的操作規模，例如將其拆分為多個操作來執行。