redis大key
温馨提示：
本文最后更新于 2025年07月18日，已超过 329 天没有更新。若文章内的图片失效（无法正常加载），请留言反馈或直接联系我。
大Key的查找指令
redis-cli --bigkeys 大key的判定
| 类型 | 大小 | |||
|---|---|---|---|---|
| string | 5MB | |||
| list | 20000个 | |||
| zset | 10000个 | |||
| hash | 1000个，value总大小100MB |
大key带来的问题
- redis变慢
- redis内存不断变大引发OOM，或达到maxmemory设置引发写阻塞或重要Key被驱逐
- redis Cluster 中的某个node内存远超其他node，但因Redis Cluster的主句迁移最小粒度为key而无法将node上的内存均衡化
- 大key的读请求使Redis占用服务器全部带宽，自身变慢的同时影响到该服务器上的其他服务
- 删除一个大key造成主库较长时间的阻塞并引发同步中断或主从切换
大Key产生的原因
| 原因 | 例子 | |||
|---|---|---|---|---|
| 将Redis用在并不适合其能力的场景，造成Key的value过大 | 使用String类型的Key存放法体积二进制文件类型数据 | |||
| 业务上线前规划设计考虑得不足。未对Key中的成员进行合理拆分 ，造成个别Key的成员数量过多 | ||||
| 没有对无效数据进行清理。造成HASH类型的Key中的成员不断增加 | ||||
| 预期外的访问量陡增 | 突然出现的爆款商品、访问量暴涨的新闻热点、直播间某大主播高活动带来的大量刷屏点赞 | |||
| 使用LIST类型Key的业务消费 侧代码故障，造成对应Key的成员只增不减 |
大key的处理
| 处理方法 | ||||
|---|---|---|---|---|
| 进行拆分 | 将一个含有数万成员的HASH KEY拆分成多个HASH KEY，并确保每个key的成员数量在合理范围，在RedisCluster结构中，拆分大key可显著平衡node间的内存分配 | |||
| 进行清理 | 将不适合Redis能力的数据存放至其他存储，并在Redis中删除此类数据。需要注意的是。Redis4.0后，使用UNLINK命令可以非阻塞的方式缓慢逐步清理传入的Key，可以安全的删除大Key甚至特大Key | |||
| 监控Redis内存水位 | 设置Redis内存报警阈值提醒：如 Redis 内存使用率超过70%，Redis内存1小时内增长率超过20%等 | |||
| 定期清理失效数据 | HASH结构中，忽略时效性，导致产生大Key。可通过定时任务清理失效数据。HSCAN 配合 HDEL 在不阻塞的前提 下清理 |
正文到此结束
- 本文标签： Java
- 本文链接： http://119.91.109.247:8443//article/115
- 版权声明： 本文由张亚东原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权