浅析 Redis 分布式集群倾斜问题
对于分布式系统而言,整个集群处理请求的效率和存储容量,往往取决于集群中响应最慢或存储增长最快的节点。所以在系统设计和容量规划时,我们尽量保障集群中各节点的“数据和请求分布均衡“。但在实际生产系统中,出现数据容量和请求倾斜(类似 Data Skew)问题是比较常见的。
示例:2019 年春节抽奖服务,业务评估峰值 qps 是 2w,转化到 redis 集群为 10w qps 和 5GB 内存存储,部署 5 个分片每个分片 1GB+2W qps 的 redis 集群(包含预留容量)。结果活动开始时,才发现服务存在”热点 key",请求严重倾斜, 峰值时的 6w qps 都集中到其中一个分片,导致这分片过载,整个抽奖服务雪崩。
redis 分布式集群倾斜问题,主要分为两类:1 数据存储容量倾斜,数据存储总是落到集群中少数节点;2 qps 请求倾斜,qps 总是落到少数节点。
本文主要从以下几点分析 redis 分布式集群倾斜:
redis 集群出现倾斜的影响;
导致 redis 集群倾斜的常见原因;
redis 集群倾斜问题的排查方式;
如何有效避免 redis 集群倾斜问题。
redis 集群出现倾斜的影响
倾斜问题对于 redis 这类纯内存和单线程服务影响较大,存在以下痛点:
qps 集中到少数 redis 节点,引起少数节点过载,会拖垮整个服务,同时集群处理 qps 能力不具备可扩展性;
数据容量倾斜,导致少数节点内存爆增,出现 OOM Killer 和集群存储容量不具备可扩展性;
运维管理变复杂,类似监控告警内存使用量、QPS、连接数、redis cpu busy 等值不便统一;
因集群内其他节点资源不能被充分利用,导致 redis 服务器/容器资源利率低;
增大自动化配置管理难度;单集群节点尽量统一参数配置;
分析完影响,那我们再看生产环境中,导致 Redis 集群严重“倾斜”的常见原因。
导致 Redis 集群倾斜的常见原因
一般是系统设计时,键空间(keyspace)设计不合理:
系统设计时,redis 键空间(keyspace)设计不合理,出现”热点 key",导致这类 key 所在节点 qps 过载,集群出现 qps 倾斜;
系统存在大的集合 key(hash,set,list 等),导致大 key 所在节点的容量和 QPS 过载,集群出现 qps 和容量倾斜;
DBA 在规划集群或扩容不当,导致数据槽(slot)数分配不均匀,导致容量和请求 qps 倾斜;
系统大量使用 Keys hash tags, 可能导致某些数据槽位的 key 数量多,集群集群出现 qps 和容量倾斜;
工程师执行 monitor 这类命令,导致当前节点 client 输出缓冲区增大;used_memory_rss 被撑大;导致节点内存容量增大,出现容量倾斜;
接下来,当集群出现内存容量、键数量或 QPS 请求量严重倾斜时,我们应该排查定位问题呢?
Redis 集群倾斜问题的排查方式
排查节点热点 key,确定 top commands.
当集群因热点 key 导致集群 qps 倾斜,需快速定位热点 key 和 top commands。可使用开源工具 redis-faina,或有实时 redis 分析平台更好。
以下是使用 redis-faina 工具分析,可见两个前缀 key 的 QPS 占比基本各为 50%, 明显热点 key;也能看到 auth 命令的异常(top commands)。
系统是否使用较大的集合键
系统使用大 key 导致集群节点容量或 qps 倾斜,比如一个 5kw 字段的 hash key, 内存占用在近 10GB,这个 key 所在 slot 的节点的内存容量或 qps 都很有可能倾斜。
这类集合 key 每次操作几个字段,很难从 proxy 或 sdk 发现 key 的大小。
可使用 redis-cli --bigkeys 分析节点存在的大键。如果需全量分析,可使用 redis-rdb-tools(https://github.com/sripathikrishnan/redis-rdb-tools) 对节点的 RDB 文件全量分析,通过结果 size_in_bytes 列得到大 key 的占用内存字节数。
示例使用 redis-cli 进行抽样分析:
检查集群每个分片的数据槽分配是否均匀
下面以 Redis Cluster 集群为例确认集群中,每个节点负责的数据槽位(slots)和 key 个数。下面 demo 的部分实例存在不轻度“倾斜”但不严重,可考虑进行 reblance.
系统是否大量使用 keys hash tags
在 redis 集群中,有些业务为达到多键的操作,会使用 hash tags 把某类 key 分配同一个分片,可能导致数据、qps 都不均匀的问题。可使用 scan 扫描 keyspace 是否有使用 hash tags 的,或使用 monitor,vc-redis-sniffer 工具分析倾斜节点,是否大理包含有 hash tag 的 key。
是否因为 client output buffer 异常,导致内存容量倾斜
确认是否有 client 出现 output buffer 使用量异常,引起内存过大的问题;比如执行 monitor、keys 命令或 slave 同步 full sync 时出现客户端输入缓冲区占用过大。
这类情况基本 redis 实例内存会快速增长,很快会出现回落。通过监测 client 输出缓冲区使用情况;分析见下面示例:
如何有效避免 Redis 集群倾斜问题
系统设计 redis 集群键空间和 query pattern 时,应避免出现热点 key, 如果有热点 key 逻辑,尽量打散分布不同的节点或添加程序本地缓存;
系统设计 redis 集群键空间时,应避免使用大 key,把 key 设计拆分打散;大 key 除了倾斜问题,对集群稳定性有严重影响;
redis 集群部署和扩缩容处理,保证数据槽位分配平均;
系统设计角度应避免使用 keys hash tag;
日常运维和系统中应避免直接使用 keys,monitor 等命令,导致输出缓冲区堆积;这类命令建议作 rename 处理;
合量配置 normal 的 client output buffer, 建议设置 10mb,slave 限制为 1GB 按需要临时调整(警示:和业务确认调整再修改,避免业务出错)
在实际生产业务场景中,大规模集群很难做到集群的完全均衡,只是尽量保证不出现严重倾斜问题。
版权声明: 本文为 InfoQ 作者【五分钟学大数据】的原创文章。
原文链接:【http://xie.infoq.cn/article/09a9ab9be21149075ff158eee】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论