在处理大型数据时，redis 作为我们的非关系型数据库经常出现在解决方案之中。然而，在使用 Redis 的过程中，有一些问题可能会悄无声息地影响我们的系统性能，其中最具代表性的就是 Big Key 问题。
这个问题往往被低估，Big Key会对 Redis 的效率和整体性能产生重大影响。在本文中，我们将深入探索 Big Key 问题的源头，讨论它如何影响系统性能，并提供相应的解决策略。通过了解和解决 Big Key 问题，我们可以更有效地利用 Redis，优化我们的系统并提高性能。
在Redis中，每个key都有一个对应的value，如果某个key的value过大，就会导致Redis的性能下降或者崩溃。
因为Redis需要将大key全部加载到内存中，这会占用大量的内存空间，会降低Redis的响应速度，这个问题被称为Big Key问题。
不要小看这个问题，它可是能让你的Redis瞬间变成“乌龟”，由于Redis单线程的特性，操作Big Key的通常比较耗时，也就意味着Big Key阻塞Redis的可能性很大，这样会造成客户端阻塞或者引起故障切换，有可能导致“慢查询”或其他连锁反应。
一般而言，下面这两种情况可以被称为Big Key：
以上对Big Key的判断标准并不唯一，只是一个大体的标准。在实际业务开发中，对Big Key的判断是需要根据具体的使用场景做不同的判断。比如操作某个 key 导致请求响应时间变慢，那么这个 key 就可以判定成 Big Key。
在Redis中，Big Key通常是由以下几种原因导致的：
如果不及时处理这些大key，它们会逐渐消耗Redis服务器的内存资源，最终导致Redis崩溃。
当出现Redis性能急剧下降的情况时，很可能是由于存在大key导致的。在排除大key问题时，可以考虑采取以下几种方法：
Redis自带的 BIGKEYS 命令可以查询当前Redis中所有key的信息，对整个数据库中的键值对大小情况进行统计分析。
比如说，统计每种数据类型的键值对个数以及平均大小。
此外，这个命令执行后，会输出每种数据类型中最大的 big key 的信息，对于 String 类型来说，会输出最大 big key 的字节长度，对于集合类型来说，会输出最大 big key 的元素个数。
BIGKEYS命令会扫描整个数据库，这个命令本身会阻塞Redis，找出所有的大键，并将其以一个列表的形式返回给客户端。
命令格式如下：
$ redis-cli --bigkeys
返回示例如下：
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Biggest string found so far 'a' with 3 bytes
[05.14%] Biggest list found so far 'b' with 100004 items
[35.77%] Biggest string found so far 'c' with 6 bytes
[73.91%] Biggest hash found so far 'd' with 3 fields
-------- summary -------
Sampled 506 keys in the keyspace!
Total key length in bytes is 3452 (avg len 6.82)
Biggest string found 'c' has 6 bytes
Biggest list found 'b' has 100004 items
Biggest hash found 'd' has 3 fields
504 strings with 1403 bytes (99.60% of keys, avg size 2.78)
1 lists with 100004 items (00.20% of keys, avg size 100004.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
1 hashs with 3 fields (00.20% of keys, avg size 3.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
解读下返回结果，从这个结果中可以看出：
这些信息可以帮助你理解Redis数据库的使用状态，以便进行相应的优化或调整。
需要注意的是，由于BIGKEYS命令需要扫描整个数据库，所以它可能会对Redis实例造成一定的负担。在执行这个命令之前，请确保你的Redis实例有足够的资源来处理它，建议在从节点执行。
如果我们找到了Big Key，就需要对其进行进一步的分析。我们可以使用命令debug object key查看某个key的详细信息，包括该key的value大小等。这时候你就可以“窥探”Redis的内部，看看到底是哪个key太大导致的问题。
Debug Object 命令是一个调试命令，当 key 存在时，返回有关信息。当 key 不存在时，返回一个错误。
redis 127.0.0.1:6379> DEBUG OBJECT key
Value at:0xb6838d20 refcount:1 encoding:raw serializedlength:9 lru:283790 lru_seconds_idle:150
redis 127.0.0.1:6379> DEBUG OBJECT key
(error) ERR no such key
第一次运行命令时，返回了 key 对应的具体信息。这些值的意思如下：
第二次运行命令时，返回了 (error) ERR no such key，说明在 Redis 中没有找到名为 'key' 的键。
在Redis4.0之前，只能通过DEBUG OBJECT命令估算key的内存使用(字段serializedlength)，但DEBUG OBJECT命令是存在误差的。
4.0版本及以上，更推荐使用memory usag命令。
memory usage命令使用非常简单，格式为：memory usage key。
如果当前key存在，则返回key的value实际使用内存估算值，如果key不存在，则返回nil。
127.0.0.1:6379> set k1 value1
OK
127.0.0.1:6379> memory usage k1 //这里k1 value占用57字节内存
(integer) 57
127.0.0.1:6379> memory usage aaa // aaa键不存在，返回nil.
(nil)
对于除String类型之外的类型，memory usage命令采用抽样的方式，默认抽样5个元素，所以计算是近似值，我们也可以手动指定抽样的个数。
示例说明：生成一个100w个字段的hash键：hkey，每字段的value长度是从1~1024字节的随机值。
127.0.0.1:6379> hlen hkey // hkey有100w个字段，每个字段的value长度介于1~1024个字节
(integer) 1000000
127.0.0.1:6379> MEMORY usage hkey //默认SAMPLES为5，分析hkey键内存占用521588753字节
(integer) 521588753
127.0.0.1:6379> MEMORY usage hkey SAMPLES 1000 //指定SAMPLES为1000，分析hkey键内存占用617977753字节
(integer) 617977753
127.0.0.1:6379> MEMORY usage hkey SAMPLES 10000 //指定SAMPLES为10000，分析hkey键内存占用624950853字节
(integer) 624950853
要想获取key较精确的内存值，就指定更大抽样个数。但是抽样个数越大，占用cpu时间分片就越大。
redis-rdb-tools 是一个 Python/ target=_blank class=infotextkey>Python 的解析 rdb 文件的工具，在分析内存的时候，我们主要用它生成内存快照。可以把 rdb 快照文件生成 CSV 或 JSON 文件，也可以导入到 MySQL 生成报表来分析。
使用 PYPI 安装：
pip install rdbtools
生成内存快照：
rdb -c memory dump.rdb > memory.csv
在生成的 CSV 文件中主要有以下几列：
可以在MySQL中新建表然后导入进行分析，然后可以直接通过SQL语句进行查询分析。
CREATE TABLE `memory` (
`database` int(128) DEFAULT NULL,
`type` varchar(128) DEFAULT NULL,
`KEY` varchar(128),
`size_in_bytes` bigint(20) DEFAULT NULL,
`encoding` varchar(128) DEFAULT NULL,
`num_elements` bigint(20) DEFAULT NULL,
`len_largest_element` varchar(128) DEFAULT NULL,
PRIMARY KEY (`KEY`)
);
例如，查询内存占用最高的3个 key：
mysql> SELECT * FROM memory ORDER BY size_in_bytes DESC LIMIT 3;
+----------+------+-----+---------------+-----------+--------------+---------------------+
| database | type | key | size_in_bytes | encoding | num_elements | len_largest_element |
+----------+------+-----+---------------+-----------+--------------+---------------------+
| 0 | set | k1 | 624550 | hashtable | 50000 | 10 |
| 0 | set | k2 | 420191 | hashtable | 46000 | 10 |
| 0 | set | k3 | 325465 | hashtable | 38000 | 10 |
+----------+------+-----+---------------+-----------+--------------+---------------------+
3 rows in set (0.12 sec)
当发现存在Big Key问题时，我们需要及时采取措施来解决这个问题。下面列出几种可行的解决思路：
将Big Key拆分成多个小key。这个方法比较简单，但是需要修改应用程序的代码。就像是把一个大蛋糕切成小蛋糕一样，有点费力，但是可以解决问题。
或者尝试将Big Key转换成Redis的其他数据结构。例如，将Big Key转换成Hash，List或者Set等数据结构。
如果大key的产生原因主要是由于对象序列化后的体积过大，我们可以考虑使用压缩算法来减小对象的大小。需要在客户端使用一些压缩算法对数据进行压缩和解压缩操作，例如LZF、SnAppy等。
如果你使用的是Redis 4.0+的版本，可以直接使用 unlink命令去异步删除大key。4.0以下的版本 可以考虑使用 scan命令，分批次删除。
无论采用哪种方法，日常使用中都需要注意以下几点：
最后，结束本文时，我们要明确的是，Redis Big Key问题是所有使用Redis作为数据存储方案的开发者都需要密切关注的重要话题。大Key可能会对Redis的性能产生严重影响，或者导致意外的内存问题。
因此，开发者应该充分利用现有的工具和策略来检测和避免Big Key。在使用Redis时，需要注意避免使用过大的value和不必要的数据结构，以及定期清理过期的key。
另外，我们还应持续探索更高效、更可靠的解决方案，来优化我们的Redis实例，使其更稳定地为我们的应用提供服务。最后，不断学习和实践才是提高我们对Redis使用的理解，并准确处理Redis Big Key问题的最佳方式。
京公网安备 11010802035086号