redis資料傾斜處理方法

2022-12-21 14:01:29

寫在前面

我們在使用Redis分片叢集時，叢集最好的狀態就是每個範例可以處理相同或相近比例的請求，但如果不是這樣，則會出現某些範例壓力特別大，而某些範例特別空閒的情況發生，本文就一起來看下這種情況是如何發生的以及如何處理。

1：什麼是資料傾斜

資料傾斜分為兩種，第一種是資料量傾斜，第二種是資料存取傾斜，定義如下：

資料量傾斜：資料分佈的不均勻，導致某些範例資料特別多，進而導致處理的請求量大
資料存取傾斜：資料分佈均勻，但是某些範例存在熱點資料，進而導致處理的請求量大

可以看到不管是資料量傾斜，還是資料存取傾斜，最終導致的結果都是發生傾斜的範例處理了更多的資料請求，壓力增大。

2：資料量傾斜

資料量傾斜最常見的原因就是在手動劃分slot時，分配不均勻，除此之外，還有big key，hash tag，分別來看下。

2.1：slot分配不均勻

slot分配不均勻一般是由於手動分配造成，或者是因為某個範例節點設定較高，為了更加充分的利用其計算機資源，有意的給其分配更多的slot，但是這個多出的量其實是不好預估的，所以對於因為計算機效能差異有意分配的造成的slot不均勻還是要儘量避免，即保證所有的範例節點都具有相同的設定，然後將slot進行均勻分配。如果是已經發生了slot分配不均勻，我們可以通過遷移slot的方式來處理，首先通過cluster slots命令檢視當前slot的分配情況：

上圖slot0~4095分配到了範例192.168.10.3:6379,slot12288~16383分配到了範例192.168.10.5:6379。如下是一個slot遷移的例子。

假設我們要把 Slot 300 從源範例（ID 為 3）遷移到目標範例（ID 為 5），那要怎麼做呢？

第1步，我們先在目標範例5上執行下面的命令，將Slot 300的源範例設定為範例 3，表示要從範例 3 上遷入 Slot 300。

第2步，在源範例 3 上，我們把 Slot 300 的目標範例設定為 5，這表示，Slot 300 要遷出到範例 5 上，如下所示：

第3步，從 Slot 300 中獲取 100 個 key。因為 Slot 中的 key 數量可能很多，所以我們需要在使用者端上多次執行下面的這條命令，分批次獲得並遷移 key。

第4步，我們把剛才獲取的 100 個 key 中的 key1 遷移到目標範例 5 上（IP 為 192.168.10.5），同時把要遷入的資料庫設定為 0 號資料庫，把遷移的超時時間設定為 timeout。我們重複執行 MIGRATE 命令，把 100 個 key 都遷移完。

最後，我們重複執行第 3 和第 4 步，直到 Slot 中的所有 key 都遷移完成。

從Redis3.0.6開始，你也可以使用KEYS選項，一次遷移多個key（key1、2、3），這樣可以提升遷移效率。

2.2：big key

bigkey，主要包括string的值特別大，和集合型別的元素特別多兩種情況，對於string，我們需要在業務上處理，分散到多個key儲存，然後在業務上多次獲取，並進行合併，比如如下劃分：

key:
    names
劃分為
key:
    name:1_1000 ... name:100001_101001

其實這裡是用到了分片的思想，對於集合的處理方式和string也是類似的，比如有一個包含100萬個元素的hash集合user:info，分片儲存後如下：

key: 
    user:info
key: 
    user:info:1_100000,user:info:100001_20000，...,user:info:900001_1000000

對於bigkey我們還是要在業務上儘量避免，因為bigkey的副作用不僅僅如此，還有如資料同步慢，資料恢復慢，刪除慢等。

2.3：hash tag

我們正常設定key，計算其slot值的方式是crc16(key)%16384,但是如果是使用了{},比如keypart1:{keypart2}，則計算的邏輯就變成了crc16(keypart2)%16384,一般用在希望某幾類key分佈到同一個範例，進而可以方便的進行某些操作的場景，如事務，簡單的計算等，但是一般帶來的的負面影響要比收益大的多，比如造成這裡分析的資料傾斜問題，資料傾斜影響的是整個Redis範例，影響更大，所以在實踐中要儘量避免使用hash tag。

3：資料存取傾斜

資料存取傾斜出現的場景一般就是熱點資料，比如首頁的新聞，某明星出軌離婚等爆點新聞，對於這類問題一般有如下的解決方法：

1：拷貝幾份資料，以分散到不同的範例
比如news:1,可以虛擬出幾份資料，如news:1:A,news:1:B,...news:1:Z,使用者端存取時隨機的增加A~Z的字尾，分散壓力，這種方法可以用於唯讀的熱點資料
2：增加機器設定
這種方法是針對讀寫資料，因為如果是按照方案1，資料的一致性將會帶來額外的效能開銷，以及更多潛在的bug。

到此這篇關於redis之資料傾斜如何處理的文章就介紹到這了,更多相關redis資料傾斜內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！