浅析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](http://redis.io/topics/cluster-spec), 可能导致某些数据槽位的key数量多，集群集群出现qps和容量倾斜；

• 工程师执行monitor这类命令，导致当前节点client输出缓冲区增大；used_memory_rss被撑大；导致节点内存容量增大，出现容量倾斜；

接下来，当集群出现内存容量、键数量或QPS请求量严重倾斜时，我们应该排查定位问题呢？

Redis集群倾斜问题的排查方式

排查节点热点key,确定top commands.

当集群因热点key导致集群qps倾斜，需快速定位热点key和top commands。可使用开源工具[redis-faina](https://github.com/facebookarchive/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](https://www.vividcortex.com/resources/network-analyzer-for-redis)工具分析倾斜节点，是否大理包含有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按需要临时调整(警示:和业务确认调整再修改，避免业务出错)

在实际生产业务场景中，大规模集群很难做到集群的完全均衡，只是尽量保证不出现严重倾斜问题。