记录一次Redis大Key的排查

最新推荐文章于 2025-11-01 18:06:34 发布
原创 最新推荐文章于 2025-11-01 18:06:34 发布 · 228 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #缓存

该博客介绍了如何利用GitHub上的开源脚本rdb_bigkeys来分析Redis的RDB文件，查找超过特定大小的大键值。首先，下载并安装Go语言，然后配置环境变量，接着克隆脚本仓库，初始化Go模块，获取依赖，并构建可执行文件。通过运行生成的rdbBigKeys工具，可以生成包含大键值的CSV文件，这对于优化Redis存储和性能至关重要。

工具

使用的是GitHub的开源脚本：https://github.com/weiyanwei412/rdb_bigkeys

使用

  1. 下载go语言安装包
    1. wget https://go.dev/dl/go1.17.5.linux-amd64.tar.gz
  2. 解压安装包
    1. rm -rf /usr/local/go && tar -C /usr/local -xzf go1.17.5.linux-amd64.tar.gz
  3. 导入环境变量
    1. export PATH=$PATH:/usr/local/go/bin
  4. 验证go环境是否配置成功
    1. go version
  5. 下载脚本源码
    1. git clone git@github.com:weiyanwei412/rdb_bigkeys.git
  6. 进入目录初始化go语言项目
    1. go mod init redisBigKeys
  7. 拉取相关依赖
    1. go get
  8. 构建可执行脚本go build，执行后生成可执行化文件：rdbBigKeys
  9. 分析Redis RDB文件
    1. ./rdbBigKeys --bytes 1024 --file bigkeys.csv --sep 0 --sorted --threads 4 /var/lib/redis/6379/dump.rdb
  10. 生成CSV文件
  11. 在这里插入图片描述
【Redis问题】记一次大key问题处理
授人以鱼不如授之以渔
02-25 712
背景 今天接到一个报警，redis cluster的某个分片节点内存使用85%了。照这样下去 估计周末就要被打爆。 排查过程 1.首先查看监控，确实其他节点都很正常， 但是这个节点使用很高。监控如下： 2.由于这个节点之前已经因为内存使用过高，之前同事已经迁移过了一次， 所以这次再发生，觉得问题不是简单搬迁slot就可以的，于是进一步排查。 首先考虑的是不是大key的问题。 经过大key分析，确实存在大key，大key分析如下： 分析大key的时候要注意系统的CPU使用率，因为SCAN会耗费大量CPU #
Redis大key有什么危害？如何排查和处理？
辣香牛肉面的博客
06-22 2015
简单来说，如果一个 key 对应的 value 所占用的内存比较大，那这个 key 就可以看作是 bigkey。具体多大才算大呢？有一个不是特别精确的参考标准：String 类型的 value 超过 1MB复合类型（List、Hash、Set、Sorted Set 等）的 value 包含的元素超过 5000 个（不过，对于复合类型的 value 来说，不一定包含的元素越多，占用的内存就越多）。bigkey 判定标准。
Redis 大Key排查与优化
Jc0803kevin的专栏
08-08 2275
bigkey简单来说就是存储本身的key值空间太大，或者hash，list，set等存储中value值过多。没有具体的衡量标准。
Redis性能提升秘籍：大Key与热点Key优化实战
最新发布
东境物语
11-01 1万+
Redis作为高性能键值数据库，在现代应用架构中扮演重要角色，但大Key和热点Key问题严重影响系统性能。大Key指占用内存过大或元素过多的Key，会导致内存压力、阻塞请求和网络拥塞；热点Key则是访问频繁的Key，引发CPU过载、响应延迟甚至系统雪崩。排查方法包括SCAN命令、RDB分析工具和大数据采样等。优化策略方面，针对大Key采用数据拆分、渐进式删除和压缩存储；针对热点Key实施限流、预取、多副本和智能路由等措施。未来随着硬件升级和Redis功能增强，这些问题将持续演进，需要结合AI等技术探索更智能
redis大key排查指南
分享技术，分享经验
04-12 1878
大 key 是指：单个 key 本身的内容过大（如一个超长字符串、超长列表、集合等）或者一个集合类 key（如 hash、list、zset、set）中 元素数量过多Redis 是单线程模型，一次性访问、删除大 key 可能阻塞主线程导致其他请求延迟。常见的大 Key 类型数据类型表现形式String超大字符串，如缓存整页 HTML、全文数据等List超长队列，如上万条记录未消费Hash字段数量巨大，如几万个属性包含大量成员。
Redis 排查大 key 的3种方法，优化必备
热门推荐
LoveSummer
07-04 1万+
Redis 实践总结（仅供参考）：合理的 Key 中 Value 的字节大小，推荐小于 10 KB。过大的 Value 会引发数据倾斜、热点Key、实例流量或 CPU 性能被占满等问题，应从设计源头上避免此类问题带来的性能影响。那么 value Bytes > 10 kb 可以作为判断 大 key 的一个参考值。 是 redis 自带的命令，对整个 Key 进行扫描，统计 string，list，set，zset，hash 这几个常见数据类型中每种类型里的最大的 key。string 类型统计的是 valu
记一次Redis热Key，大Key引发的线上事故
kkBDserver的博客
07-03 1069
记一次Redis热Key，大Key引发的线上事故
Redis 大KEY/慢查询问题的排查和解决
brushli的专栏
04-21 668
Redis大KEY/慢查询问题的排查和解决
一次关于Redis内存诡异增长的排查过程实战记录
09-09
在本文中，我们将深入探讨一次关于Redis内存异常增长的排查过程。这通常是一个棘手的问题，因为内存管理是Redis性能的关键因素。通过这次实战记录，我们可以了解到如何分析和解决此类问题。 首先，我们关注到的现象...
Redis大key问题的排查与解决
zjshuster的博客
08-18 1078
大 key 并不是指 key 的值很大，而是 key 对应的 value 很大。一般而言，下面这两种情况被称为大 key：String 类型的值大于 10 KB；Hash、List、Set、ZSet 类型的元素的个数超过 5000个；
排查Redis大key的方法
Jc0803kevin的专栏
08-08 1882
它是一个非阻塞操作，支持游标(cursor)的方式来逐步遍历所有key。使用SCAN命令可以避免阻塞，减少对Redis性能的影响。这样组合的方式操作比较复杂，需要对命令使用非常熟悉。在生产环境需要更快，更高效的发现问题还是建议使用成熟的分析工具，毕竟也都是用这些命令组合起来的。对于集合类型来说，这个方法只统计集合元素的多少，而不是实际占用的内存量。这个方法只能返回每种类型中最大的那个bigkey，无法得到大小排到前N位的bigkey。实际上bigkey的底层也使用SCAN命令执行。
如何在Redis中查找大key
qq_31459039的博客
10-29 5463
工作中，经常有些Redis实例使用不恰当，或者对业务预估不准确，或者key没有及时进行处理等等原因，导致某些KEY相当大。 那么大Key会带来哪些问题呢？ 如果是集群模式下，无法做到负载均衡，导致请求倾斜到某个实例上，而这个实例的QPS会比较大，内存占用也较多；对于Redis单线程模型又容易出现CPU瓶颈，当内存出现瓶颈时，只能进行纵向库容，使用更牛逼的服务器。 涉及到大key的操作，尤其是...
Redis大key产生、排查与优化实践
weixin_56018532的博客
06-04 1377
在Redis中，大key（Big Key）指的是占用内存空间较大的键值对。从本质上讲，所谓的"大key"问题实际上是"大value"问题，因为key本身通常是固定大小的，而value才是占用大量内存的部分。Redis大key问题是一个常见的性能隐患，需要在设计、开发和运维各个阶段予以重视。通过合理的数据结构设计、有效的监控手段和及时的优化措施，可以有效避免和解决大key问题，提升Redis的性能和稳定性。随着Redis版本的更新和社区工具的丰富，处理大key的方法也在不断演进。
笔记:Redis大key问题排查处理
程序和音乐一样，都是一门艺术
01-18 1294
一、背景 最近一段时间公司有个服务频繁出现"com.mongodb.MongoWaitQueueFullException:Too many threads are already waiting for a connection. Max number of threads (maxWaitQueueSize) of 100 has been exceeded",程序在获取连接的排队队列设置的100，连接使用时间过长导致获取连接溢出， 经DBA分析排除mongo 慢查询原因，对比异常出现时间跟redi
Redis 如何处理大 Key
Linuxprobe18的博客
08-31 1797
所以，如果一下子释放了大量内存，空闲内存块链表操作时间就会增加，相应地就会造成 Redis 主线程的阻塞，如果主线程发生了阻塞，其他所有请求可能都会超时，超时越来越多，会造成 Redis 连接耗尽，产生各种异常。每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。对于删除大 Hash，使用 hscan 命令，每次获取 100 个字段，再用 hdel 命令，每次删除 1 个字段。.
redis中查找大key方法汇总
2401_87878486的博客
10-10 2733
redis作为一个高性能内存数据库，在实际业务中应用的非常广泛，虽然redis的性能很好，但是在实际使用过程中，如果使用不当，也会造成一些性能问题，比如数据中存在大key。什么是大key?顾名思义就是单个key中的数据比较大，通常来说，单个key的value值不会很大，这种情况下，key的读取，删除操作不会影响性能，如果value过大，读取或删除会相对耗时，大家都知道，redis是单线程，耗时操作就会阻塞其它请求，给性能上带来一些影响。
Redis 排查大 key 的4种方法，优化必备
Java笔记虾
07-05 3478
摘要：在日常Redis的使用中，难免遇到因为 key 存储了过大的数据而造成请求缓慢甚至阻塞的情况，这个时候就需要排查 Redis 的大key去优化业务了，下面提供一些排查方案总结，仅供参考。一、多大的 key 算大呢？Redis 实践总结（仅供参考）：合理的 Key 中 Value 的字节大小，推荐小于 10 KB。过大的 Value 会引发数据倾斜、热点Key、实例流...
Redis调优-BigKey如何处理？
weixin_39682329的博客
03-24 957
SCAN 命令是一个基于游标的迭代器，每次被调用之后， 都会向用户返回一个新的游标， 用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来延续之前的迭代过程。没有对Key中的成员进行合理的拆分将大key变成小key，从而造成个别Key中一直往value里面塞数据，没有删除机制，未定期清理无效数据，导致不断增加。：Redis中的大key，实际上指的是key所关联的value值特别大，或者是某种数据结构（如hash, set, zset, list）中存储了过多的元素。
redis如何如何排查大key ？redis过期策略
05-13
<think>好的，我现在需要回答用户关于Redis中排查大Key的方法以及Redis的过期策略实现原理的问题。首先，我要回顾用户提供的引用内容，确保准确引用相关信息，并结合自己的知识来详细解答。 用户的问题分为两部分：排查大Key的方法和过期策略的实现原理。根据用户提供的引用，引用[1]提到了分批删除大Key的案例，引用[3]详细介绍了大Key的排查与优化方法，包括拆分数据结构和使用分片处理。而引用[2]讨论了Redis的过期key删除策略，如惰性删除和定期删除，以及内存淘汰策略。这些信息需要整合到回答中。 首先，针对排查大Key的方法，我需要列举常用的工具和方法，比如使用redis-cli的--bigkeys参数、memory usage命令、SCAN结合debug object等。同时，要提到第三方工具如Redis RDB Tools，并解释每种方法的优缺点，比如--bigkeys的简单但可能不准确，memory usage的精确但耗资源。引用[3]中提到将大Key拆分成多个小Key，使用hget/hset优化，这些可以作为优化建议的一部分。 接下来是过期策略的实现原理。需要解释惰性删除和定期删除两种机制，引用[2]中提到惰性删除是在访问时检查过期时间，定期删除则通过定时任务随机抽查。此外，内存淘汰策略如LRU、LFU等也需要说明，这些策略在内存不足时触发，以释放空间。用户可能还关心这些策略的配置和适用场景，需要结合实际应用例子说明。 在组织回答时，要注意结构清晰，分点说明。使用Markdown的标题和列表来提升可读性。同时，确保引用正确，比如在提到惰性删除时引用[^2]，在讨论大Key优化时引用[^3]。 可能还需要验证一些细节，比如惰性删除的具体实现是否仅在访问时触发，或者还有其他情况。此外，定期删除的扫描频率和每次检查的数据库数量是否正确，比如默认是每秒10次，每次随机检查20个key。这些细节需要准确无误，避免误导用户。 最后，生成的相关问题需要与主题相关，比如大Key对性能的影响、如何选择内存淘汰策略、过期策略的配置方法等，确保问题能够引导用户进一步探索。</think>### **Redis大Key排查方法与过期策略实现原理** --- #### **一、Redis大Key排查方法** --- ##### **1. 官方工具排查** - **`redis-cli --bigkeys`命令** 通过扫描数据库识别各类型最大Key： ```bash redis-cli -h 127.0.0.1 -p 6379 --bigkeys ``` - **优点**：无需额外工具，快速定位TOP大Key - **缺点**：仅统计最大值，可能遗漏次大Key[^3] - **`MEMORY USAGE`命令** 精确计算指定Key的内存占用： ```bash MEMORY USAGE user:profile:1024 ``` - **适用场景**：已知Key名称时的详细分析 - **注意**：对生产环境性能有轻微影响（需遍历数据结构）[^3] --- ##### **2. 编程式扫描** 使用`SCAN`命令结合`DEBUG OBJECT`实现分批次扫描： ```python cursor = 0 while True: cursor, keys = redis.scan(cursor, count=100) for key in keys: mem = redis.memory_usage(key) if mem > 1024 * 1024: # 1MB阈值 print(f"大Key: {key}, 内存: {mem}字节") if cursor == 0: break ``` - **优化技巧**： - 设置合理阈值（如字符串>10KB，集合>1000元素） - 分批处理避免阻塞主线程[^3] --- ##### **3. RDB文件分析** 使用**Redis RDB Tools**离线分析持久化文件： ```bash rdb -c memory dump.rdb --bytes 10240 > bigkeys.csv ``` - **优势**：不影响线上服务，支持全量数据分析 - **输出内容**：Key名称、数据类型、内存占用、元素数量 --- ##### **4. 大Key处理方案** | 数据类型 | 优化策略 | 实现方法示例 | |----------|-----------------------------------|-----------------------------------| | String | 分片存储 | `user:1024:metadata_part1` | | Hash | 按字段拆分 | `hget user:1024 name` | | List | 分页存储 | `lrange comments:1024 0 99` | | Set/ZSet | 按业务维度拆分 | `sinter user:1024:followers` | --- #### **二、Redis过期策略实现原理** --- ##### **1. 过期Key删除机制** - **惰性删除（被动删除）** - **触发时机**：访问Key时检查过期时间 - **执行逻辑**： ```c if (key.expire_time < now()) { delete_key(key); return NULL; } ``` - **优点**：零额外CPU消耗 - **缺点**：可能积累大量已过期未访问的Key[^2] - **定期删除（主动删除）** - **工作机制**： 1. 每秒执行10次定时任务（可配置`hz`参数） 2. 每次随机抽取20个Key检查 3. 删除其中已过期的Key，若比例>25%则重复本步骤 - **设计目标**：平衡CPU消耗与内存释放效率[^2] --- ##### **2. 内存淘汰策略** 当内存达到`maxmemory`时触发淘汰机制： | 策略 | 特点 | 适用场景 | |---------------------|-------------------------------------------|---------------------------| | volatile-lru | 淘汰最近最少使用的**带过期时间**Key | 缓存系统 | | allkeys-lru | 淘汰最近最少使用的**任意**Key | 通用数据库 | | volatile-lfu | 淘汰使用频率最低的**带过期时间**Key | 热点数据分布不均场景 | | allkeys-random | 随机淘汰任意Key | 数据重要性均匀分布 | | volatile-ttl | 优先淘汰剩余存活时间最短的Key | 短期临时数据存储 | | noeviction（默认） | 拒绝写入新数据 | 数据不可丢失场景 | --- ##### **3. 内存碎片处理** - **自动重整**： Redis 4.0+支持`activedefrag`配置，在内存碎片率超过阈值时自动整理 ```conf # 启用自动碎片整理 activedefrag yes # 碎片率超过10%时触发 active-defrag-ignore-bytes 100mb active-defrag-threshold-lower 10 ``` - **手动触发**： 执行`MEMORY PURGE`命令（依赖jemalloc等支持）[^2] --- #### **三、生产环境最佳实践** 1. **大Key预防** - 设计阶段定义Key规范（如`业务:类型:ID:字段`） - 使用Hash类型存储对象，避免巨型String - 对List/Set设置元素数量阈值（通过Lua脚本控制写入）[^3] 2. **过期策略配置** ```conf # 调整定期删除频率（默认10） hz 20 # 设置内存淘汰策略 maxmemory 16gb maxmemory-policy volatile-lru ``` 3. **监控指标** - `expired_keys`：累计过期Key数量 - `evicted_keys`：内存淘汰触发的Key删除数 - `mem_fragmentation_ratio`：内存碎片率（>1.5需告警） --- ### **相关问题** 1. 如何通过Redis监控系统实时发现大Key？ 2. 在集群模式下，Redis的过期策略有什么特殊表现？ 3. 使用Lua脚本操作大Key时需要注意哪些问题？ 4. Redis的LFU算法是如何统计Key访问频率的？ [^1]: 大Key删除需分批次处理以避免服务阻塞 [^2]: 惰性删除与定期删除共同保障内存回收效率 [^3]: 数据结构优化是解决大Key问题的根本方法
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

壹氿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值