在Redis叢集中，若個別資料分區節點（Data Node）的記憶體使用量率或CPU使用率、頻寬使用率、延時等效能指標遠遠高於其他資料分區，該Redis叢集可能已產生資料扭曲。資料扭曲嚴重時，會導致執行個體在整體記憶體使用量率不高的情況下，發生記憶體逐出（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使用率、頻寬使用率和延遲等效能指標高的問題。
為什麼會產生資料扭曲
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%及以上時，可認為已產生資料扭曲，差值越大，資料扭曲程度越嚴重。
下圖介紹兩個典型的資料扭曲情境，如下圖所示，雖然Key均勻地分布在叢集中，每個資料分區節點2個Key，但仍產生了資料扭曲：
Shard 1節點中key1的QPS明顯高於其他Key，屬於典型的資料訪問傾斜，會導致該Key所在的資料分區節點CPU使用率、頻寬使用率升高，從而影響該分區上所有Key的處理。Shard 2節點中key5的QPS雖然不高，但該Key的大小為1 MB，屬於典型的資料量傾斜，會導致該Key所在的資料分區節點的記憶體使用量率、頻寬使用率升高，從而影響該分區上所有Key的處理。
臨時方案
因此，若執行個體已產生資料扭曲，您可以通過如下臨時方案進行過渡。
同時，您也可以在短時間內可降低大Key、熱Key的請求量，暫緩資料扭曲問題，但大Key、熱Key問題只能通過業務上的改造才能解決。建議您及時對執行個體進行資料扭曲的原因排查，並根據對應處理方法在業務層進行改造，對執行個體進行最佳化，更多資訊請參見多種資料扭曲原因的處理方法。
傾斜情境 | 可能原因 | 臨時方案 |
記憶體傾斜 | 大Key、Hash Tags。 | 升級執行個體規格，具體操作請參見變更執行個體配置。 重要
|
頻寬傾斜 | 大Key、熱Key、高消耗命令。 | 提升執行個體中指定1個或多個分區的頻寬，具體操作請參見手動增加執行個體頻寬。 說明 單個執行個體分區可增加頻寬的上限為192MB/s，若業務流量仍大於該值，則只能在業務層進行改造。 |
CPU使用率傾斜 | 大Key、熱Key、高消耗命令。 | 如果熱點Key分布在不同Slot，可以嘗試在業務低峰期增加資料分區節點，使熱點Key分散。 說明 請在業務低峰期擴容，因為擴容期間資料移轉操作會消耗CPU。 |
多種資料扭曲原因的處理方法
請提前規劃業務增長率，合理地拆分大Key，並保持規範的資料寫入，才能解決資料扭曲的根源問題。
產生傾斜原因 | 說明 | 處理方法 |
大Key | 大Key通常以Key的大小和Key中成員的數量來綜合判定。 常見於在KKV（Key-key-value）類型的資料結構中，例如Hash、List、Set、Zset等，存放過多或過大的field，從而導致單個Key過大，產生執行個體資料扭曲。更多關於大Key的資訊，請參見發現並處理Redis的大Key和熱Key。 |
|
熱Key | 熱Key指某個Key或者少部分Key的操作QPS明顯高於其他Key。常見於壓測時選了單一Key或秒殺情境下熱點商品ID Key。更多關於熱key資訊，請參考發現並處理Redis的大Key和熱Key。 |
|
高消耗命令 | 不同的命令具有不同的複雜度，高複雜度的命令會消耗大量效能資源，例如 | |
Hash Tags | 若Key名稱中包含 |
|