在云數據庫 Tair（兼容 Redis）集群架構實例中，若個別數據分片節點（Data Node）的內存使用率、CPU使用率或帶寬使用率等性能指標遠遠高于其他數據分片，該集群可能已產生數據傾斜。數據傾斜嚴重時，會導致實例在整體內存使用率不高的情況下，發生內存逐出（Key eviction）、內存溢出OOM（Out Of Memory）、實例響應時間上升等異常情況。
快速處理
本章節介紹如何確認是否存在數據傾斜，以及查找、處理大Key的方法。
訪問CloudDBA > 實時性能，查看各數據分片節點的內存使用率是否均衡。
本示例中，db-0數據分片節點的內存使用率顯著高于其他數據分片節點，該實例存在數據傾斜。
說明您還可以使用實例診斷功能，一鍵排查當前實例是否存在傾斜的情況。
查看每個數據分片節點的Key總數。
在本示例中，可以看到db-0、db-1和db-2數據分片節點的Key總數分別是2.59、2.60和2.59 Million（百萬）個，各數據分片節點中Key數量是相對均衡的，此時大概率可以確定db-0數據分片節點中存在大Key。
說明若各數據分片節點的Key數量不均衡，則表示業務中可能存在Key名稱設計不規范，例如使用了Hash Tags等，客戶端在通過CRC算法時，將Key都寫至同一數據分片節點中。此時您需要從業務側進行改造，避免在Key名稱中使用
{}。使用離線全量Key分析功能，快速找出大Key。
該功能將分析實例的備份文件，不會對在線業務產生影響。分析完成后，您可以查看Top 500 BigKey，在本示例中，名為mylist的Key為大Key。
（可選）您也可以連接到具體的數據分片節點中，進行查詢與分析。
集群架構代理模式：可以使用阿里云自研的ISCAN命令，在指定的數據分片節點上執行SCAN命令，更多信息請參見阿里云自研的Proxy命令。
集群架構直連模式：可以通過DescribeDBNodeDirectVipInfo API接口獲取各數據分片節點的VIP，再通過客戶端連接待分析的數據分片節點進行分析。
解決方案。
臨時：升級實例規格。
長期（推薦）：進行業務改造，合理地拆分大Key。
關于導致數據傾斜的詳細原因和處理方法請見下文，本文也適用于排查標準架構內存使用率、CPU使用率、帶寬使用率和延遲等性能指標高的問題。
為什么會產生數據傾斜
云數據庫 Tair（兼容 Redis）集群架構實例作為一個分布式系統，整個數據庫空間會被分為16384個槽（Slot），每個數據分片節點將存儲與處理指定Slot的數據（Key），例如3分片集群實例，3個分片分別負責的Slot為：[0,5460]、[5461,10922]、[10923,16383]。當用戶寫入或更新數據時，客戶端會通過CRC算法計算出Key所屬的Slot，具體公式為Slot=CRC16(key)%16384，并將數據寫入Slot所屬的數據分片節點。通常情況下，各數據分片節點的Key數量是均勻分布的，同時內存使用率、CPU使用率等性能指標也是相近的。
但在使用數據庫的過程中，可能會由于前期規劃不足、不規范的數據寫入及突發的訪問量，造成數據量傾斜或數據訪問傾斜，最終引起數據傾斜。
數據傾斜通常是指大多數據分片節點的性能指標較低，而個別節點的性能指標較高的情況，高或低沒有明確的標準。您可以在性能監控的數據節點頁面中查看各數據分片節點的對應指標，通常情況下，若某數據分片節點（最高）的性能指標高出其他數據分片節點（最低）20%及以上時，可認為已產生數據傾斜，差值越大，數據傾斜程度越嚴重。
當單數據分片節點的內存使用率達100%時，該數據分片節點會觸發數據逐出（默認策略為volatile-lru）。
下圖介紹兩個典型的數據傾斜場景，如下圖所示，雖然Key均勻地分布在集群中，每個數據分片節點2個Key，但仍產生了數據傾斜：
Shard 1節點中key1的QPS明顯高于其他Key，屬于典型的數據訪問傾斜，會導致該Key所在的數據分片節點CPU使用率、帶寬使用率升高，從而影響該分片上所有Key的處理。Shard 2節點中key5的QPS雖然不高，但該Key的大小為1 MB，屬于典型的數據量傾斜，會導致該Key所在的數據分片節點的內存使用率、帶寬使用率升高，從而影響該分片上所有Key的處理。
臨時方案
因此，若實例已產生數據傾斜，您可以通過如下臨時方案進行過渡。
傾斜場景 | 可能原因 | 臨時方案 |
內存傾斜 | 大Key、Hash Tags。 | 升級實例規格，具體操作請參見變更實例配置。 重要
|
帶寬傾斜 | 大Key、熱Key、高消耗命令。 | 提升實例中指定1個或多個分片的帶寬，具體操作請參見手動增加實例帶寬。 說明 單個實例分片可增加帶寬的上限為192MB/s，若業務流量仍大于該值，則只能在業務層進行改造。 |
CPU使用率傾斜 | 大Key、熱Key、高消耗命令。 |
說明 請在業務低峰期擴容，因為擴容期間數據遷移操作會消耗CPU。 |
同時，您也可以在短時間內可降低大Key、熱Key的請求量，暫緩數據傾斜問題，但大Key、熱Key問題只能通過業務上的改造才能解決。建議您及時對實例進行數據傾斜的原因排查，并根據對應處理方法在業務層進行改造，對實例進行優化，更多信息請參見多種數據傾斜原因的處理方法。
多種數據傾斜原因的處理方法
請提前規劃業務增長率，合理地拆分大Key，并保持規范的數據寫入，才能解決數據傾斜的根源問題。
產生傾斜原因 | 說明 | 處理方法 |
大Key | 大Key通常以Key的大小和Key中成員的數量來綜合判定。 常見于在KKV（Key-key-value）類型的數據結構中，例如Hash、List、Set、Zset等，存放過多或過大的field，從而導致單個Key過大，產生實例數據傾斜。 關于如何在不影響業務的情況下，優雅地刪除大Key或熱Key，請參見優化大Key與熱Key。 |
|
熱Key | 熱Key指某個Key或者少部分Key的操作QPS明顯高于其他Key。常見于壓測時選了單一Key或秒殺場景下熱點商品ID Key。更多關于熱Key信息，請參考發現并處理大Key和熱Key。 |
|
高消耗命令 | 不同的命令具有不同的復雜度，高復雜度的命令會消耗大量性能資源，例如 | |
Hash Tags | 若Key名稱中包含 |
|
常見問題
Q：集群實例中有大Key，可以升級大Key所在的數據分片節點的實例規格嗎？
A：不可以，云數據庫 Tair（兼容 Redis）實例不支持單獨升級某個分片節點的實例規格，僅支持同時升級所有分片節點的實例規格。
Q：集群實例中有大Key，新增分片節點并重新分布Key可以解決該問題嗎？
A：不會解決，新的分片節點會幫原有分片節點分擔部分內存壓力。但云數據庫 Tair（兼容 Redis）的數據分布粒度為Key級，大Key是無法被自動拆分的。由于大Key沒被解決掉，在重新分布Key后，仍會一個分片節點的內存是高于其他分片節點，此時仍存在數據傾斜。推薦的方法是拆分大Key，讓大Key變成多個小Key。