本文已收录至Github，引荐阅览 Java随想录

微信大众号：Java随想录

摘要

Redis是一款功能强劲的内存数据库，可是在运用过程中，咱们或许会遇到Big Key问题，这个问题就是Redis中某个key的value过大，所以Big Key问题本质是Big Value问题，导致Redis的功能下降或许溃散。本文将向大家介绍如何排查和处理这个问题。

Big Key问题介绍

在Redis中，每个key都有一个对应的value，假如某个key的value过大，就会导致Redis的功能下降或许溃散，比玄学更玄学，因为Redis需求将大key悉数加载到内存中，这会占用很多的内存空间，会降低Redis的响应速度，这个问题被称为Big Key问题。不要小看这个问题，它可是能让你的Redis瞬间变成“乌龟”，因为Redis单线程的特性，操作Big Key的通常比较耗时，也就意味着堵塞Redis或许性越大，这样会形成客户端堵塞或许引起故障切换，有或许导致“慢查询”。

一般来说，下面这两种状况被称为大 key：

  • String 类型的 key 对应的value超过 10 MB。
  • list、set、hash、zset等调集类型，调集元素个数超过 5000个。

以上对 Big Key 的判别规范并不是唯一，仅仅一个大体的规范。在实际事务开发中，对 Big Key的判别是需求依据详细的运用场景做不同的判别。比如操作某个 key 导致恳求响应时间变慢，那么这个 key 就能够判定成 Big Key。

在Redis中，大key通常是由以下几种原因导致的：

  • 目标序列化后的巨细过大
  • 存储很多数据的容器，如set、list等
  • 大型数据结构，如bitmap、hyperloglog等

假如不及时处理这些大key，它们会逐渐耗费Redis服务器的内存资源，最终导致Redis溃散。

Big Key问题排查

当呈现Redis功能急剧下降的状况时，很或许是因为存在大key导致的。在排除大key问题时，能够考虑采纳以下几种办法：

运用BIGKEYS指令

Redis自带的 BIGKEYS 指令能够查询当时Redis中所有key的信息，对整个数据库中的键值对巨细状况进行统计剖析，比如说，统计每种数据类型的键值对个数以及均匀巨细。此外，这个指令履行后，会输出每种数据类型中最大的 bigkey 的信息，关于 String 类型来说，会输出最大 bigkey 的字节长度，关于调集类型来说，会输出最大 bigkey 的元素个数

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)

需求留意的是，因为BIGKEYS指令需求扫描整个数据库，所以它或许会对Redis实例形成一定的担负。在履行这个指令之前，请确保您的Redis实例有满足的资源来处理它，主张在从节点履行。

Debug Object

假如咱们找到了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

serializedlength表明key对应的value序列化之后的字节数

memory usage

在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

redis-rdb-tools 是一个 python 的解析 rdb 文件的工具，在剖析内存的时候，咱们主要用它生成内存快照。能够把 rdb 快照文件生成 CSV 或 JSON 文件，也能够导入到 MySQL 生成报表来剖析。

运用 PYPI 安装

pip install rdbtools

生成内存快照

rdb -c memory dump.rdb > memory.csv

在生成的 CSV 文件中有以下几列：

  • database key在Redis的db
  • type key类型
  • key key值
  • size_in_bytes key的内存巨细
  • encoding value的存储编码方式
  • num_elements key中的value的个数
  • len_largest_element key中的value的长度

能够在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问题处理思路

当发现存在大key问题时，咱们需求及时采纳措施来处理这个问题。下面列出几种可行的处理思路：

1. 切割大key

将Big Key拆分红多个小的key。这个办法比较简略，可是需求修改应用程序的代码。就像是把一个大蛋糕切成小蛋糕相同，有点费力，可是能够处理问题。

或许测验将Big Key转换成Redis的数据结构。例如，将Big Key转换成Hash，List或许Set等数据结构。

2. 目标紧缩

假如大key的巨细主要是因为目标序列化后的体积过大，咱们能够考虑运用紧缩算法来减小目标的巨细。Redis本身支持多种紧缩算法，例如LZF、Snappy等。

3. 直接删去

假如你运用的是Redis 4.0+的版别，能够直接运用 unlink指令去异步删去。4.0以下的版别 能够考虑运用 scan ,分批次删去。

不管采用哪种办法，都需求留意以下几点：

  1. 防止运用过大的value。假如需求存储很多的数据，能够将其拆分红多个小的value。就像是吃饭相同，一口一口的吃，不要贪多嚼不烂。

  2. 防止运用不必要的数据结构。例如，假如只需求存储一个字符串，就不要运用Hash或许List等数据结构。

  3. 定时整理过期的key。假如Redis中存在很多的过期key，就会导致Redis的功能下降。就像是家里的垃圾，需求定时整理。

  4. 目标紧缩

总结

Big Key问题是Redis中常见的问题之一，可是经过合理的排查和处理思路，咱们能够有效地防止这个问题。在运用Redis时，需求留意防止运用过大的value和不必要的数据结构，以及定时整理过期的key。

本篇文章就到这里，感谢阅览，假如本篇博客有任何错误和主张，欢迎给我留言纠正。文章继续更新，能够重视大众号第一时间阅览。