数据倾斜通常分为两种情况，一是各实例上面的数据不均匀，个别实例数据量特别多；
二是某个实例上的热点数据多，导致的访问量倾斜。发生了数据倾斜，那么保存了大量
数据或者是保存了热点数据的实例的处理压力就会增大，速度变慢，甚至还可能会引起
这个实例的内存资源耗尽导致宕机风险。
bigkey导致倾斜
如果某个实例上保存了bigkey，会导致这个实例的数据量及相应的内存资源消耗增加，
bigkey的操作容易导致主线程IO的阻塞，bigkey最好能够从业务层面避免掉，如果是
集合类型的bigkey，建议拆分成多个集合多实例保存，再根据业务逻辑做相应的映射。
slot分配不均
solt分配不均，就根据具体的使用的中间件查看slot分布情况进而做具体slot迁移
hashtag导致的分配不均
hashtag指的是对key的部分用{}圈起来，例如dramaId:episode:1232变成
dramaId:episode:{1232},在计算 key 的 CRC16 值时，只对HashTag花括号中的
key内容进行计算,这有什么用处呢？就是key不一样但是hashtag内容一样的key
会被分配到同一个slot，它主要是用在 Redis Cluster 和 Codis中，支持事务操作
和范围查询。因为 Redis Cluster 和 Codis 本身并不支持跨实例的事务操作和
范围查询，当业务应用有这些需求时，就只能先把这些数据读取到业务层进行事务
处理，或者是逐个查询每个实例，得到范围查询的结果，所以我们可以使用 Hash Tag
把要执行事务操作或是范围查询的数据映射到同一个实例上，这样就能很轻松实现
事务或范围查询，潜在的风险就是会导致大量的数据被分配到同一实例，导致数据
倾斜和集群负载不均衡，所以在hashtag和业务上的事务范围查询，得我们自己做
取舍，建议还是避免hashtag
热点数据导致的访问量倾斜
在某个实例上的商品或者某些影视剧集突然火了，那么就导致这个实例的访问量突增，
好在热点数据通常只是读，所以我们可以采用热点数据多副本的方式应对，我们把热点
数据复制多份，然后把key加个前缀，使其分布在不同的slot，查询的时候做好相应逻辑，
那么即可把热点数据的压力分摊到多实例上
