處理叢集資料扭曲 - Tair (Redis® OSS-Compatible)

在Tair (Redis OSS-compatible)叢集架構執行個體中，若個別資料分區節點（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 OSS-compatible)叢集架構執行個體作為一個分布式系統，整個資料庫空間會被分為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。	升級執行個體規格，具體操作請參見變更執行個體配置。重要變更配置時執行個體會進行資料扭曲預檢查，若您選擇的執行個體規格無法解決記憶體傾斜問題，執行個體會進行攔截與報錯，請您調大執行個體規格後重試。在成功升級執行個體規格後，會改善記憶體傾斜問題，但可能也引起頻寬傾斜或CPU傾斜。
頻寬傾斜	大Key、熱Key、高消耗命令。	提升執行個體中指定1個或多個分區的頻寬，具體操作請參見手動增加執行個體頻寬。說明單個執行個體分區可增加頻寬的上限為192MB/s，若業務流量仍大於該值，則只能在業務層進行改造。
CPU使用率傾斜	大Key、熱Key、高消耗命令。	如果熱點Key分布在不同Slot，可以嘗試在業務低峰期增加資料分區節點，使熱點Key分散。最佳化高消耗命令，例如減少每次SCAN命令擷取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進行拆分，例如將含有數萬成員的一個HASH Key拆分為多個HASH Key，並確保每個Key的成員數量在合理範圍。
熱Key	熱Key指某個Key或者少部分Key的操作QPS明顯高於其他Key。常見於壓測時選了單一Key或秒殺情境下熱點商品ID Key。更多關於熱Key資訊，請參考發現並處理大Key和熱Key。	請避免使用熱Key。使用QueryCache特性，緩衝熱點資料，更多資訊請參見最佳化大Key與熱Key。
高消耗命令	不同的命令具有不同的複雜度，高複雜度的命令會消耗大量效能資源，例如`HGETALL`命令的複雜度為O(n)，該命令會隨著您儲存的Field越多，消耗越大。同時，簡單的`SET`或`GET`命令也會在Value過大時，消耗大量資料分區節點的效能資源。	可通過查詢慢日誌功能查詢資料分區節點的慢日誌。可通過時延洞察查看消耗大量效能資源的命令。業務側需減少或禁止使用高消耗命令，如需禁用命令，可以在參數設定中配置`#no_loose_disabled-commands`參數。
Hash Tags	若Key名稱中包含`{}`，例如`{item}id1`，則Tair僅會對`{}`中的內容進行Slot計算並選擇資料分區節點。若存在`{item}id1`、`{item}id2`、`{item}id3`等大量Key，由於`{}`中的內容相同，上述Key均會被分配至同一資料分區節點，導致該資料分區節點的記憶體資源、效能消耗大幅升高。	避免在Key名稱中使用`{}`。說明如需在Key名稱中使用`{}`，需保證`{}`中的內容儘可能不同，從而使Key盡量均勻地分布在叢集的不同資料分區節點上。

常見問題

Q：叢集執行個體中有大Key，可以升級大Key所在的資料分區節點的執行個體規格嗎？
A：不可以，Tair (Redis OSS-compatible)執行個體不支援單獨升級某個分區節點的執行個體規格，僅支援同時升級所有分區節點的執行個體規格。
Q：叢集執行個體中有大Key，新增分區節點並重新分配Key可以解決該問題嗎？
A：不會解決，新的分區節點會幫原有分區節點分擔部分記憶體壓力。但Tair (Redis OSS-compatible)的資料分布粒度為Key級，大Key是無法被自動拆分的。由於大Key沒被解決掉，在重新分配Key後，仍會一個分區節點的記憶體是高於其他分區節點，此時仍存在資料扭曲。推薦的方法是拆分大Key，讓大Key變成多個小Key。