Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
81696 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 53 讲
开篇词 (1讲)
实践篇 (28讲)
Redis 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

37 | 数据分布优化:如何应对数据倾斜?

避免使用Hash Tag进行数据切片,优先考虑避免数据倾斜
查看Slot和实例的具体分配关系,迁移部分Slot到其他实例
避免把过多的Slot分配到同一个实例
将bigkey拆分成多个小的集合类型数据,分散保存在不同的实例上
业务层生成数据时避免保存过多数据在同一个键值对中
给实例本身增加资源,如使用配置更高的机器
只适用于只读的热点数据
解决方法
解决方法
解决方法
热点数据多副本
实例上存在热点数据
使用Hash Tag导致倾斜
Slot分配不均衡导致倾斜
bigkey导致倾斜
在构建切片集群时,尽量使用大小配置相同的实例,避免因实例资源不均衡而在不同实例上分配不同数量的Slot
应对方法
成因
成因
小建议
Redis Cluster和Codis集群提供了查看Slot分配和手工迁移Slot的命令
缓解数据倾斜的影响
数据访问倾斜
数据量倾斜
集群的实例资源配置
数据迁移
数据倾斜
数据分布优化

该思维导图由 AI 生成,仅供参考

你好,我是蒋德钧。
在切片集群中,数据会按照一定的分布规则分散到不同的实例上保存。比如,在使用 Redis Cluster 或 Codis 时,数据都会先按照 CRC 算法的计算值对 Slot(逻辑槽)取模,同时,所有的 Slot 又会由运维管理员分配到不同的实例上。这样,数据就被保存到相应的实例上了。
虽然这种方法实现起来比较简单,但是很容易导致一个问题:数据倾斜。
数据倾斜有两类。
数据量倾斜:在某些情况下,实例上的数据分布不均衡,某个实例上的数据特别多。
数据访问倾斜:虽然每个集群实例上的数据量相差不大,但是某个实例上的数据是热点数据,被访问得非常频繁。
如果发生了数据倾斜,那么保存了大量数据,或者是保存了热点数据的实例的处理压力就会增大,速度变慢,甚至还可能会引起这个实例的内存资源耗尽,从而崩溃。这是我们在应用切片集群时要避免的。
今天这节课,我就来和你聊聊,这两种数据倾斜是怎么发生的,我们又该怎么应对。

数据量倾斜的成因和应对方法

首先,我们来看数据量倾斜的成因和应对方案。
当数据量倾斜发生时,数据在切片集群的多个实例上分布不均衡,大量数据集中到了一个或几个实例上,如下图所示:
那么,数据量倾斜是怎么产生的呢?这主要有三个原因,分别是某个实例上保存了 bigkey、Slot 分配不均衡以及 Hash Tag。接下来,我们就一个一个来分析,同时我还会给你讲解相应的解决方案。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

数据分布优化是切片集群中的重要问题,本文介绍了数据倾斜的成因和应对方法。数据倾斜主要包括数据量倾斜和数据访问倾斜两种情况。数据量倾斜可能由bigkey、Slot分配不均衡以及Hash Tag等原因导致。针对bigkey导致的倾斜,建议在业务层生成数据时避免将过多数据保存在同一个键值对中,或者将bigkey拆分成小的集合类型数据分散保存在不同实例上。对于Slot分配不均衡导致的倾斜,需要避免过多Slot分配到同一个实例,可以通过迁移命令将部分Slot迁移到其他实例上来避免数据倾斜。此外,文章还介绍了在Redis Cluster和Codis中查看和迁移Slot的具体操作方法。通过本文的总结,读者可以了解数据倾斜的成因及相应的解决方案,为优化数据分布提供了有益的参考。 文章还介绍了Hash Tag导致的数据倾斜问题,以及在Redis Cluster和Codis中使用Hash Tag的场景和潜在问题。针对数据访问倾斜的问题,文章提出了采用热点数据多副本的方法来应对,以及针对有读有写的热点数据需要增加实例资源的建议。最后,文章总结了数据倾斜的原因和应对方法,并提供了关于实例资源配置的小建议。 总的来说,本文通过详细介绍数据倾斜的成因和解决方法,为读者提供了全面的数据分布优化方案,使其能够更好地应对切片集群中可能出现的数据倾斜问题。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(32)

  • 最新
  • 精选
  • xuanyuan
    赞,很多设计思想可以和mysql对比着看,收获颇丰

    作者回复: 是的,如果能和其他系统对比起来学习,一般会有更多收获。这是个好方法。

    2020-12-09
    8
  • Kaito
    在有数据访问倾斜时,如果热点数据突然过期了,而 Redis 中的数据是缓存,数据的最终值保存在后端数据库,此时会发生什么问题? 此时会发生缓存击穿,热点请求会直接打到后端数据库上,数据库的压力剧增,可能会压垮数据库。 Redis 的很多性能问题,例如导致 Redis 阻塞的场景:bigkey、集中过期、大实例 RDB 等等,这些场景都与数据倾斜类似,都是因为数据集中、处理逻辑集中导致的耗时变长。其解决思路也类似,都是把集中变分散,例如 bigkey 拆分为小 key、单个大实例拆分为切片集群等。 从软件架构演进过程来看,从单机到分布式,再到后来出现的消息队列、负载均衡等技术,也都是为了将请求压力分散开,避免数据集中、请求集中的问题,这样既可以让系统承载更大的请求量,同时还保证了系统的稳定性。
    2020-11-16
    5
    200
  • Summer 空城
    我们把热点数据复制多份,在每一个数据副本的 key 中增加一个随机前缀,让它和其它副本数据不会被映射到同一个 Slot 中。 这样做了以后怎么查呢?key前边加了随机数,客户端也不知道用啥key去查数据了
    2020-11-27
    17
    16
  • nxcat
    终于追上了,期待课代表的留言!课后问题我理解的话,只读模式下会发生缓存击穿,严重的话还可能造成雪崩。
    2020-11-16
    10
  • 感觉后面干货越来越少了,前几篇,一篇一看就是一晚上,后面一晚上看8,9篇,还是我变强了呢?
    2021-09-26
    2
    5
  • Sam Fu
    不过业界中解决热key的话一般不采用hotkey+随机数的方式吧。毕竟如果集群实例个数特别多的话,删除hotkey的话成本有点大。 查看网上资料说解决热key更多的采用是将热点key加入到二级缓存(如JVM缓存) 不知道对不对?
    2021-02-13
    3
    5
  • Lemon
    课后题:将发生缓存击穿,导致数据库压力激增,可能导致数据库奔溃。与之相对的解决方法是不设置热点 Key 的过期时间,并以采用热点数据多副本的方法减少单实例压力。 疑问:老师您好,热点数据多副本的方法使得每一个数据副本的 key 都有一个随机前缀,那么客户端在读取的时候怎么获取这个随机前缀?又怎么保证带上随机前缀后的热点 Key 会被较为均匀的请求呢?
    2020-11-17
    6
    3
  • InfoQ_小汤
    针对流量倾斜问题,对key作切分 理论上其实很简单 但是联合业务实践上挺复杂的,某个key一开始是非热点数据状态的,需要有监控redis key的工具,需要有相关自动切分或者人工干预切分的行为,切分以后业务端查询也需要同步被告知切分的规则,否则业务查询时候无法获取正确的key,切换的过程中新key与旧key需要同时存在一小段时间,否则肯能存在读旧key的请求异常。目前唯一能想到的是通过zookeeper这种配置中心去协调(watch机制),但是大量读会给zookeeper带来比较大的压力。增加二级缓存又会有数据延迟的情况,真的不清楚实际上业务是如何实现这种联动的。
    2021-11-26
    2
  • dfuru
    缓存击穿
    2020-11-26
    2
  • 云海
    热点多副本方案的使用:客户端请求时带上客户端标记即可,不同的客户端请求就会hash分散到不同的热点副本。
    2020-11-19
    2
收起评论
显示
设置
留言
32
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部