數(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ù)的壓力分攤到多實例上
