數(shù)據(jù)傾斜通常分為兩種情況，一是各實例上面的數(shù)據(jù)不均勻，個別實例數(shù)據(jù)量特別多；

二是某個實例上的熱點數(shù)據(jù)多，導致的訪問量傾斜。發(fā)生了數(shù)據(jù)傾斜，那么保存了大量

數(shù)據(jù)或者是保存了熱點數(shù)據(jù)的實例的處理壓力就會增大，速度變慢，甚至還可能會引起

這個實例的內(nèi)存資源耗盡導致宕機風險。

bigkey導致傾斜

如果某個實例上保存了bigkey，會導致這個實例的數(shù)據(jù)量及相應的內(nèi)存資源消耗增加，

bigkey的操作容易導致主線程IO的阻塞，bigkey最好能夠從業(yè)務層面避免掉，如果是

集合類型的bigkey，建議拆分成多個集合多實例保存，再根據(jù)業(yè)務邏輯做相應的映射。

slot分配不均

solt分配不均，就根據(jù)具體的使用的中間件查看slot分布情況進而做具體slot遷移

hashtag導致的分配不均

hashtag指的是對key的部分用{}圈起來，例如dramaId:episode:1232變成

dramaId:episode:{1232},在計算 key 的 CRC16 值時，只對HashTag花括號中的?

key內(nèi)容進行計算,這有什么用處呢？就是key不一樣但是hashtag內(nèi)容一樣的key

會被分配到同一個slot，它主要是用在 Redis Cluster 和 Codis中，支持事務操作

和范圍查詢。因為 Redis Cluster 和 Codis 本身并不支持跨實例的事務操作和

范圍查詢，當業(yè)務應用有這些需求時，就只能先把這些數(shù)據(jù)讀取到業(yè)務層進行事務

處理，或者是逐個查詢每個實例，得到范圍查詢的結果，所以我們可以使用 Hash Tag?

把要執(zhí)行事務操作或是范圍查詢的數(shù)據(jù)映射到同一個實例上，這樣就能很輕松實現(xiàn)

事務或范圍查詢，潛在的風險就是會導致大量的數(shù)據(jù)被分配到同一實例，導致數(shù)據(jù)

傾斜和集群負載不均衡，所以在hashtag和業(yè)務上的事務范圍查詢，得我們自己做

取舍，建議還是避免hashtag

熱點數(shù)據(jù)導致的訪問量傾斜

在某個實例上的商品或者某些影視劇集突然火了，那么就導致這個實例的訪問量突增，

好在熱點數(shù)據(jù)通常只是讀，所以我們可以采用熱點數(shù)據(jù)多副本的方式應對，我們把熱點

數(shù)據(jù)復制多份，然后把key加個前綴，使其分布在不同的slot，查詢的時候做好相應邏輯，

那么即可把熱點數(shù)據(jù)的壓力分攤到多實例上