这是我参与8月更文挑战的第19天，活动详情查看：8月更文挑战
某个系统上，redis集群各个节点之间的访问分布不均，并且看监控，部分节点连接数忽大忽小。大佬同事的总结，非常不错，整理分享给大家。
数据倾斜导致访问不均衡
数据倾斜的问题：
- 造成各节点内存使用不均，内存占用高的节点片会成为整个集群容量的瓶颈
- 影响集群的伸缩性
- 数据倾斜一般会带来访问倾斜
数据倾斜可能的原因：
- BigKey
- slot分配不均
- Hash Tag等等
BigKey导致的访问不均
BigKey，即key对应的value所占的内存空间比较大。例如一个字符串类型的value可以最大存到512MB，一个列表类型的value最多可以存储2^32-1个元素。 bigkey无论是空间复杂度和时间复杂度都不太友好。
BigKey的危害体现在三个方面：
- 内存空间不均匀(数据倾斜)
- 超时阻塞:由于Redis单线程的特性，操作bigkey比较耗时，也就意味 着阻塞Redis可能性增大
- 每次获取bigkey产生的网络流量较大，假设一个bigkey为1MB，每秒访问量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey可能会对其他实例造成影响，其后果不堪设想。
优化BigKey，在方案设计时尽量避免BigKey，避免不了则将BigKey拆分到合适的粒度。
访问倾斜的问题：
- 造成各节点CPU、带宽使用不均，负载高的节点会成为集群瓶颈，甚至影响集群性能
- 影响集群的伸缩性
访问倾斜的原因
- 数据倾斜
- HotKey
- 方案设计不合理等
HotKey,即热点key，指的是在一段时间内该key的访问量远高于其他的redis key。例如运营活动中的榜单、秒杀活动中的商品、热点推送中的新闻帖子等
HotKey带来的问题显而易见，大量访问某一个key，流量集中在某一个节点造成集群负载不均，甚至可能会使节点过载，影响整个集群可用性。
优化HotKey，一般的应对方案是拆分、使用本地缓存
