一、什么是 BigKey？
1、BigKey的定义
BigKey是指那些在 Redis 中存储了大量数据，或者其序列化后占用大量内存空间的键。它不仅仅是一个值很长的字符串，更常见的是指那些包含巨多元素的集合类型（如 Hash、List、Set、ZSet）。
想象一下：
一个 String 类型的 Key，存储了一个几 MB 甚至几十 MB 的 JSON 字符串。
一个 List 类型的 Key，里面有几百万个元素，就像一个永无止境的日志队列。
一个 Hash 类型的 Key，存储了几十万个字段，代表了一个复杂对象的巨量属性。
一个 Set 或 ZSet 类型的 Key，包含了数百万的成员。
这些，都是 BigKey。它们就像 Redis 内存中的“巨无霸”，吞噬着宝贵的资源。
2、BigKey 为什么是性能杀手？
BigKey 绝不仅仅是占用更多内存那么简单。它会引发一系列连锁反应，严重影响 Redis 性能和稳定性：
- 内存失衡与 OOM 风险： 一个 BigKey 就能瞬间吃掉大量内存，可能导致 Redis 内存使用率飙升，甚至触发操作系统的 OOM（Out Of Memory），进而导致 Redis 实例崩溃或频繁发生 SWAP（内存交换到磁盘），严重拖慢性能。
- 网络阻塞： 当客户端获取或更新 BigKey 时，需要传输大量数据。这会占用大量的网络带宽，导致其他正常、小巧的请求被阻塞，增加整体延迟。
- CPU 耗尽与服务阻塞： Redis 是单线程模型，对 BigKey 的操作，比如删除 (
DEL)、过期 (EXPIRE)、序列化/反序列化等，都会消耗大量的 CPU 资源。这些操作会长时间阻塞 Redis 主线程，导致所有其他命令都排队等待，降低 Redis 的吞吐量和响应速度。 - 集群稳定性下降： 在 Redis Cluster 模式下，BigKey 的迁移（re-sharding）会耗费大量时间，期间可能导致节点卡顿、迁移失败，甚至引起整个集群的不稳定。主从复制时，BigKey 的传输也会占用大量带宽，影响主从同步的效率。
- 持久化开销增大： RDB 快照或 AOF 重写时，BigKey 的处理会显著增加持久化的耗时和生成的文件大小。
二、如何发现 Redis 中的 BigKey？
1、使用redis-cli --bigkeys命令(推荐)
这是 Redis 官方推荐且最简单直接的方法。它会遍历 Redis 中的所有 Key，计算每个 Key 的内存大小或元素数量，并按类型进行统计，最后列出每个类型中最大的 N 个 Key。它通过 SCAN 命令分批次遍历，不会阻塞 Redis 服务。
redis-cli -h <host> -p <port> --bigkeys -i 0.01命令说明
-h <host>: Redis 服务器地址。
-p <port>: Redis 服务器端口。
--bigkeys: 启用 BigKey 扫描模式。
-i 0.01(可选): 指定SCAN命令的间隔时间，单位为秒。这可以减小对 Redis 服务器的压力，但会延长扫描时间。默认不设置或设置为 0，表示尽可能快地扫描。
- 优点： 简单易用，对在线 Redis 服务的阻塞影响小。
- 缺点： 只能获取当前时刻的 BigKey 快照，无法实时监控。在大 Key 频繁变动的场景下，可能无法及时捕捉。
2. 使用 RDB 工具进行离线分析
Redis 的 RDB 文件是内存数据的二进制快照。通过分析 RDB 文件，我们可以离线地获取 Redis 中所有 Key 的详细信息（包括大小和类型），而不会对在线的 Redis 服务造成任何影响。这对于生产环境来说是一个非常安全的分析方式。
常用工具：
redis-rdb-tools(Python)： 这是一个功能强大的 RDB 文件解析器，可以生成报告、CSV 文件，帮助你分析 Key 的大小、类型、过期时间等。redis-memory-for-json(Node.js)： 另一个流行的 RDB 分析工具。
使用方式（以 redis-rdb-tools 为例）：
生成 RDB 文件： 在 Redis 命令行中执行
BGSAVE命令，生成最新的 RDB 文件。拷贝 RDB 文件： 将生成的 RDB 文件拷贝到分析工具所在的机器。
运行分析命令：
rdb --command bigkeys /path/to/dump.rdb # 或者生成 JSON 格式报告进行更详细分析 rdb -c json /path/to/dump.rdb > dump.json
- 优点： 零入侵，对在线 Redis 服务无任何性能影响；可以获取历史某个时间点的数据快照。
- 缺点： 无法实时监控；分析需要额外的工具和环境；RDB 文件可能很大，分析耗时。
3. 实时监控与自定义脚本
对于需要实时或近实时发现 BigKey 的场景，结合 Redis 的监控数据和自定义脚本是更灵活的选择。
监控内存指标： 持续监控 Redis 实例的内存使用情况 (
used_memory) 和 Key 数量 (db0:keys)。如果内存突然飙升但 Key 数量变化不大，很可能是有 BigKey 产生。INFO命令： 定期执行INFO MEMORY或INFO KEYSPACE命令，收集内存和 Key 空间的信息。虽然不能直接定位 BigKey，但可以作为 BigKey 产生的预警信号。SCAN结合类型特有命令： 编写脚本（如 Python、Java 等），使用SCAN命令分批遍历 Key。对于每个 Key，先用TYPE命令判断其类型，然后根据类型使用对应的命令来获取其大小或元素数量。一旦发现超过预设阈值的 Key，就记录下来并触发告警。
Java 伪代码示例（使用 Jedis 客户端）：
添加 Jedis 依赖
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>5.1.0</version>
</dependency>Java 代码
import redis.clients.jedis.Jedis;
import redis.clients.jedis.params.ScanParams;
import redis.clients.jedis.resps.ScanResult;
import java.util.Set;
public class RedisBigKeyScanner {
private static final String REDIS_HOST = "localhost";
private static final int REDIS_PORT = 6379;
private static final String REDIS_PASSWORD = null; // 如果有密码则填写
// 定义 BigKey 的阈值
// 字符串 10MB
private static final long BIG_STRING_THRESHOLD_BYTES = 10 * 1024 * 1024;
// 集合类型 10万元素
private static final long BIG_COLLECTION_THRESHOLD_ELEMENTS = 100000;
public static void main(String[] args) {
// 使用 try-with-resources 确保 Jedis 连接被正确关闭
try (Jedis jedis = new Jedis(REDIS_HOST, REDIS_PORT)) {
// 如果 Redis 服务器有密码，进行认证
if (REDIS_PASSWORD != null && !REDIS_PASSWORD.isEmpty()) {
jedis.auth(REDIS_PASSWORD);
}
System.out.println("Scanning for BigKeys...");
// 初始化 SCAN 命令的游标，从头开始扫描
String cursor = ScanParams.SCAN_POINTER_START;
// 设置每次 SCAN 命令返回的 Key 数量
ScanParams scanParams = new ScanParams().count(1000);
// 循环执行 SCAN 命令，直到游标回到起点（表示所有 Key 都已遍历）
do {
ScanResult<String> scanResult = jedis.scan(cursor, scanParams);
// 更新游标
cursor = scanResult.getCursor();
// 获取当前批次扫描到的 Key 集合
Set<String> keys = scanResult.getResult();
// 遍历当前批次获取到的所有 Key
for (String key : keys) {
String keyType = jedis.type(key);
// 根据 Key 类型，使用不同的命令来判断是否是 BigKey
switch (keyType) {
case "string":
// 获取字符串的长度（字节数）
long stringSize = jedis.strlen(key);
if (stringSize > BIG_STRING_THRESHOLD_BYTES) {
System.out.printf(" [BIG KEY] String: %s (Size: %.2f MB)%n", key, (double) stringSize / (1024 * 1024));
}
break;
case "list":
// 获取列表的元素数量
long listLength = jedis.llen(key);
if (listLength > BIG_COLLECTION_THRESHOLD_ELEMENTS) {
System.out.printf(" [BIG KEY] List: %s (Elements: %d)%n", key, listLength);
}
break;
case "hash":
// 获取哈希表的字段数量
long hashFields = jedis.hlen(key);
if (hashFields > BIG_COLLECTION_THRESHOLD_ELEMENTS) {
System.out.printf(" [BIG KEY] Hash: %s (Fields: %d)%n", key, hashFields);
}
break;
case "set":
// 获取集合的成员数量
long setMembers = jedis.scard(key);
if (setMembers > BIG_COLLECTION_THRESHOLD_ELEMENTS) {
System.out.printf(" [BIG KEY] Set: %s (Members: %d)%n", key, setMembers);
}
break;
case "zset":
// 获取有序集合的成员数量
long zsetMembers = jedis.zcard(key);
if (zsetMembers > BIG_COLLECTION_THRESHOLD_ELEMENTS) {
System.out.printf(" [BIG KEY] ZSet: %s (Members: %d)%n", key, zsetMembers);
}
break;
// 可以根据需要添加其他 Redis 数据类型的判断或跳过
default:
break;
}
}
// 当游标回到起始点 "0" 时，表示遍历完成
} while (!cursor.equals(ScanParams.SCAN_POINTER_START));
System.out.println("BigKey scan complete.");
} catch (Exception e) {
System.err.println("Error connecting to Redis or during scan: " + e.getMessage());
e.printStackTrace();
}
}
}- 优点： 灵活性高，可以根据业务需求自定义 BigKey 的判断标准和告警策略；能够实现实时或准实时监控。
- 缺点： 脚本开发和维护成本较高；需要考虑对 Redis 性能的影响，合理设置
SCAN的COUNT参数和扫描频率。
4. 业务层面排查
有时 BigKey 的产生源于业务逻辑的缺陷，比如某个业务 ID 对应的 Key 不断积累数据，从未清理。
慢查询日志： 定期检查 Redis 的慢查询日志（
slowlog），看是否有针对特定 Key 的操作耗时过长。这往往是 BigKey 的一个重要信号。业务梳理： 定期梳理业务中数据量可能持续增长的场景，例如用户操作日志、动态列表、排行榜等，评估其是否可能产生 BigKey，并提前设计好清理或拆分方案。
代码审查： 检查应用程序代码中是否有不合理的数据结构使用，例如将一个复杂对象直接序列化成一个大字符串存储，或者在单个 Key 下无限追加数据。