redis集群如何解决key不均匀对分布式存储系统的架构和运维管理，如何保证每个 Node 的数据存储容量和请求量尽量均衡，是非常重要的。本文介绍 Redis 大集群运维过程中，常见导致数据和请求量“倾斜”的场景，及规避措施。Redis 数据容量或请求量严重”倾斜”的影响
以下从运维的角度解释，Redis数十节点的集群，出现数据容量和请求量倾斜情况下，存在的一些痛点：
少数或单个节点请求量”过热”，导致 Redis 分布式系统失去可扩展性能力和集群的意义，类似 MongoDB_id 字段作为片键；导致运维容量规划，扩容处理难度大；增大自动化配置管理难度；单集群节点尽量统一参数配置；监控告警复杂（容量，QPS，连接数的阈值等）。那大家再看生产环境中，常见导致 Redis 集群严重“倾斜”的场景
Redis 集群常见“倾斜”的场景这类问题一般 DBA 规划不当，业务键空间（keyspace）设计不合理等问题导致
DBA 在规划集群时或扩容后，导致数据槽（哈希桶）位分配不均匀，引起内存容量、键个数和请求 QPS 倾斜；业务的键空间设计不合理，所谓“热点key”，导致某少量 KEY 的 QPS 操作很大；这类节点 QPS 过载；程序大量使用 Keys hash tags, 可能导致某些数据槽位的键个数较多；程序存在大的集群 key（hash，set，list等），导致大 key 所在节点的容量和 QPS 过高；工和师执行Monitor这类命令，导致当前节点client输出缓冲区增大，used_memory_rss 被撑大，导致节点内存容量增大。接下来，当集群出现内存容量、键数量或 QPS 请求量严重倾斜时，大家应该排查定位问题。
Redis 集群“倾斜”问题排查检查集群每个分片的数据槽分配是否均匀
下面以 Redis Cluster 集群为例确认集群中，每个节点负责的数据槽位（slots）和 key 个数。下面 demo的部分实例存在不轻度“倾斜”，但不严重，可考虑进行reblance。
排查节点热点 Key，确定 top commands
使用 redis-faina，当然有实时分析平台就更好。从以下示例中，可见两个前缀 key 的 QPS 占比基本各为 50%, 明显热点 key；也能看到auth命令的异常（top commands）。
程序是否大量使用 Keys hash tags
可能导致数据存储内存量，QPS都不均匀的问题，可使用scan扫描keyspace是否有使用hash tags的，或使用monitor，vc-redis-sniffer。
程序是否使用较大的集合键
比如 1kw 个字段的 hash key， 内存占用在几个 GB，这类集合 key 每次操作几个字段，很难从 proxy 或 sdk 发现 key 的大小。 可通过 redis-cli –bigkeys
确认是否因 monitor 命令引起的输出缓冲区占用内存过大的问题
这类情况基本 Redis 实例内存会快速增长，很快会出现回落。通过监测 client 输出缓冲区使用情况：
查看输出缓冲区列表长度不为 0 的 client。 可见 monitor 占用输出缓冲区 370MB如何有效避免 Redis 集群“倾斜”问题集群部署和扩容处理，保证数据槽位分配平均；keyspace设计时，如何避免热点key, 打散热key；业务在键空间设计时，中尽量避免使用大的集合类型的Key，把key设计拆分；程序角度尽量避免使用keys hash tag；避免工程师直接使用keys,monitor等命令，导致输出缓冲区堆积；合量配置 normal 的 client output buffer，建议设置 10MB（警示:和业务确认调整再修改，避免业务出错）在实际生产业务场景中，大规模集群很难做到集群的完全均衡，只是尽量保证不出现严重倾斜问题。
以上就是偶的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 偶是科技领域创作者，十年互联网从业经验，欢迎关注偶了解更多科技知识！