Redis 数据倾斜产生的原因及问题详解_Redis

一、什么是redis数据倾斜？

数据倾斜是指在redis分布式集群（如redis cluster或codis）中，数据（内存占用）或访问请求（qps）没有均匀地分布到各个节点上，导致部分节点负载过高，而其他节点相对空闲的现象。这违背了分布式系统负载均衡的设计初衷。

数据倾斜主要分为两种：

通常，两者会相互关联和加剧。

大key（big key）：
定义：一个key对应的value非常大，例如一个包含数百万元素的hash/list/set，或者一个巨大的字符串（>10kb）。
影响：这个大key必然落在某个特定节点上。它会导致：
- 该节点内存使用率高，可能率先触发内存淘汰或oom。
- 持久化（rdb/aof）时，bgsave或rewriteaof操作耗时剧增，阻塞主线程风险高。
- 网络传输压力大，迁移困难。
槽位（slot）分配不均：
- 在redis cluster中，总共有16384个槽位。理论上，节点间槽位数应大致相等。如果手动使用 cluster addslots 分配不均，或者迁移过程中出现异常，会导致部分节点管理的槽位更多，存储的数据也相应更多。
hash tag使用不当：
hash tag 是一种高级特性，用 {} 包裹键名的一部分，例如 user:{1000}:profile 和 user:{1000}:orders。redis会仅使用{}内的内容来计算槽位，从而保证相关联的多个key落在同一个节点。
滥用风险：如果所有业务的key都使用同一个hash tag（例如 {global}:key1, {global}:key2），那么所有数据都会集中到同一个节点，造成严重的存储和请求倾斜。
数据分布与业务逻辑强相关：
- 例如，所有以特定前缀（如 hot_news:2024）开头的key，由于哈希算法特性，可能恰好都映射到了同一个或某几个槽位。

热点key（hot key）：
定义：某个key在短时间内被超高频率地访问（如秒杀商品、热点新闻）。
影响：
- 该key所在节点的cpu、网络带宽和连接数负载激增，成为性能瓶颈。
- 可能导致该节点响应变慢，甚至因过载而宕机，引发雪崩效应。
命令复杂度不均：
- 某个节点上的key虽然数量不多，但经常被执行 o(n) 复杂度的命令（如 hgetall、lrange 0 -1、keys *、sort），消耗大量cpu资源。
客户端连接池配置不当：
- 所有客户端可能由于某种原因（如配置错误、故障转移后）集中连接到集群中的少数几个节点。

基础监控：持续监控所有redis节点的以下指标：
- 内存使用率：各节点是否均衡？
- keys数量：各节点key数是否大致相当？
- qps/ops：各节点请求量是否均衡？
- cpu使用率：是否有节点cpu持续偏高？
- 网络流量：输入/输出带宽是否均衡？
- 慢查询日志：是否集中在某些节点？

查看集群节点与槽位分布：

redis-cli -c -h <host> -p <port> cluster nodes

观察每个节点后面的 slots 范围是否均匀，以及 connected 连接数。

分析节点内存与key数：

redis-cli -c -h <host> -p <port> info memory | grep used_memory_human
redis-cli -c -h <host> -p <port> info keyspace

可以编写脚本遍历所有节点，对比数据。

redis-cli -h <host> -p <port> --bigkeys -i 0.1

redis-cli -h <host> -p <port> --hotkeys

使用 monitor 命令（生产环境慎用，临时采样）：短暂运行，观察哪些key被频繁操作。

基于代理或客户端埋点：在应用端或代理层（如codis proxy、twemproxy）统计key的访问频率。

拆分大key：
示例：一个存储了100万用户id的set all_users，可以拆分为 all_users:shard1、all_users:shard2 ... 等多个子key，通过哈希将用户id分散到不同子key中。
注意：拆分会增加客户端逻辑的复杂度。
优化数据结构：
- 例如，不用string存储大json，改用hash；使用hyperloglog代替set进行基数统计。
调整槽位分布：
- 对于redis cluster，可以使用 redis-cli --cluster rebalance 命令，在节点间重新均衡槽位。但这只能均衡槽位数量，无法解决因大key或hash tag导致的单个槽位内数据过大的问题。
规范使用hash tag：
仅对有强关联、需要共同操作的key使用hash tag。例如，确保一个用户会话的多个key在同一个节点。避免滥用。

本地缓存：
在应用层（如guava、caffeine）或靠近应用的缓存（如sidecar）中对热点key进行缓存，大幅降低对redis的直接请求。注意设置合理的过期时间和更新策略。
读写分离：
如果热点主要是读请求，可以为该热点key所在的redis节点配置从库（replica），将读流量分散到从库上。
key分片：
与拆分大key类似，将一个逻辑热点key（如 hot_news）拆分为多个物理key（如 hot_news:1、hot_news:2）。客户端访问时，通过一个确定性规则（如 用户id % 分片数）决定访问哪个分片。这本质上是将压力从单key分摊到多节点。
使用 redisgears/actions：
利用redis的服务端脚本能力，在redis内部实现复杂的逻辑，减少网络往返和客户端压力。

容量规划与监控先行：在上线前预估数据量和访问模式，建立完善的监控告警体系。
数据预热：在活动（如大促）开始前，将预期可能成为热点或主要的数据加载到缓存，并使其均匀分布。
客户端优化：
- 使用连接池，并确保连接均匀分布到集群节点。
- 避免在线上使用阻塞式或高复杂度命令（keys、flushall、hgetall 等），使用 scan 系列命令替代。
升级架构：
- 如果业务增长迅猛，可以考虑使用更高级的分布式缓存方案（如阿里云tair、腾讯云redis企业版），它们内置了更好的负载均衡和热点发现能力。

redis数据倾斜的本质是数据或流量在分布式系统中分布不均。解决思路可以概括为：

监控发现：建立指标，快速定位是存储问题还是请求问题。
精准分析：使用工具定位到大key或热点key。
对症下药：
- 对大key：拆。
- 对热点key：分（分片）或挡（本地缓存/读写分离）。
- 对分布不均：调（槽位重平衡）和规（规范hash tag使用）。
预防为主：在系统设计和开发阶段就充分考虑数据分布和访问模式。