如何处理Redis集群数据倾斜
背景
在Redis集群中,少数分片节点的空间使用率或CPU使用率、带宽使用率、延时等性能指标明显高于其他数据分片,该Redis集群可能已产生数据倾斜。数据倾斜严重时,会导致集群在整体使用率不高的情况下,响应时间上升、写入失败等异常情况。
为什么会产生数据倾斜 ?
数据倾斜分为空间倾斜和访问倾斜:
空间倾斜可分为 key 数量倾斜和 key 大小倾向。
key 数量倾向比较常见的场景为 Redis 集群开启了 hashtag,业务的 key 名包含了 hashtag 大括号,在无意识下大量的 key 名中的 {} 里面包含相同的内容,这些 key 经过集群代理的转发,集中落在少数分片上,造成这些分片 key 数量明显高于其他分片。
key 大小倾斜 比较常见的场景为业务使用了复杂数据类型,例如 LIST 类型,业务在无意识下,向少数 LIST 类型 key 添加了较多数量的元素,其元素个数明显高于其他 LIST 类型 key,就出现在各分片 key 数量相当的情况下,个别分片的空间使用率明显高于其他分片。
访问倾斜可分为CPU消耗型访问倾斜和IO消耗型访问倾斜。
CPU消耗型访问倾斜一般出现在内存型 Redis 集群,比较典型的场景为业务使用了计算复杂度较高的命令,例如 ZSET 类型 key 的元素排序命令,当 key 内部元素数量较大时,排序命令的执行会消耗大量的CPU资源,整个命令的执行耗时较长,容易引发慢请求甚至超时断链。
IO消耗型访问倾斜一般出在业务频繁调用结果集较大的命令的场景。例如业务频繁调用 hgetall 命令,若碰到 HASH key 的元素数量较大,单次命令的结果集就会很大,当访问频次较高时,容易将实例网络IO打满,造成网络阻塞。另外一种比较典型场景是热key,例如在秒杀场景下,业务会超过频访问个别key,容易引发 CPU 和 网络IO 资源打满。
如何确认是否存在数据倾斜 ?
查看实例的集群监控、分片监控、节点监控,查看慢日志。
如何处理数据倾斜 ?
可能的原因 | 短期方案 | 长期方案 | ||
---|---|---|---|---|
空间倾斜 | key数量倾斜 | hashtag。 | 实例容量升配。 | 业务分析改造。 |
key大小倾斜 | 个别复杂数据类型key包含元素个数较多。 | 实例容量升配。 | 使用平台的大key分析功能找到大key,业务对大key进行拆分改造。 | |
访问倾斜 | CPU消耗型访问倾斜 | 热key。 | 开启从只读,提交工单开启代理层热 key 缓存。 | 业务设计优化和访问逻辑优化。 |
高复杂度的命令。 | 开启从只读。 | 查看慢日志找到复杂命令,业务针对性优化。 | ||
IO 消耗型访问倾斜 | 热key。 | 开启从只读,提交工单开启代理层热 key 缓存,提交工单升配网络IO。 | 开启平台热key分析出热 key,业务针优化。 | |
大key。 | 开启从只读,提交工单升配网络IO。 | 开启平台大key分析出大key,业务针优化。 | ||
结果集大的命令。 | 开启从只读,提交工单升配网络IO。 | 查看慢日志找到复杂命令,业务针对性优化。 |