如何處理資料扭曲

快速處理

本章節介紹如何確認是否存在資料扭曲，以及尋找、處理大Key的方法。

1. 訪問CloudDBA > 即時效能，查看各資料分區節點的記憶體使用量率是否均衡。

   本樣本中，db-0資料分區節點的記憶體使用量率顯著高於其他資料分區節點，該執行個體存在資料扭曲。

   說明

   您還可以使用執行個體診斷功能，一鍵排查當前執行個體是否存在傾斜的情況。

2. 查看每個資料分區節點的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名稱中使用{}。

3. 使用離線全量Key分析功能，快速找出大Key。

   該功能將分析執行個體的備份檔案，不會對線上業務產生影響。分析完成後，您可以查看Top 500 BigKey，在本樣本中，名為mylist的Key為大Key。

   

4. （可選）您也可以串連到具體的資料分區節點中，進行查詢與分析。

   • 叢集架構代理模式：可以使用阿里雲自研的ISCAN命令，在指定的資料分區節點上執行SCAN命令，更多資訊請參見阿里雲自研的Proxy命令。

   • 叢集架構直連模式：可以通過DescribeDBNodeDirectVipInfo API介面擷取各資料分區節點的VIP，再通過用戶端串連待分析的資料分區節點進行分析。

5. 解決方案。

   • 臨時：升級執行個體規格。

   • 長期（推薦）：進行業務改造，合理地拆分大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使用率等效能指標也是相近的。

但在使用資料庫的過程中，可能會由於前期規劃不足、不規範的資料寫入及突發的訪問量，造成資料量傾斜或資料訪問傾斜，最終引起資料扭曲。

下圖介紹兩個典型的資料扭曲情境，如下圖所示，雖然Key均勻地分布在叢集中，每個資料分區節點2個Key，但仍產生了資料扭曲：

臨時方案

因此，若執行個體已產生資料扭曲，您可以通過如下臨時方案進行過渡。

同時，您也可以在短時間內可降低大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。