定制网站设计高端网站建设,wordpress修改文章固定id,大连网站制作 姚喜运,液压电机东莞网站建设原创不易#xff0c;注重版权。转载请注明原作者和原文链接 文章目录 Big Key问题介绍Big Key问题排查BIGKEYS命令Debug Objectmemory usage redis-rdb-tools Big Key问题解决思路分割大key对象压缩直接删除 在处理大型数据时#xff0c;Redis 作为我们的非关系型数据库经常出… 原创不易注重版权。转载请注明原作者和原文链接 文章目录 Big Key问题介绍Big Key问题排查BIGKEYS命令Debug Objectmemory usage redis-rdb-tools Big Key问题解决思路分割大key对象压缩直接删除 在处理大型数据时Redis 作为我们的非关系型数据库经常出现在解决方案之中。然而在使用 Redis 的过程中有一些问题可能会悄无声息地影响我们的系统性能其中最具代表性的就是 Big Key 问题。 这个问题往往被低估Big Key会对 Redis 的效率和整体性能产生重大影响。在本文中我们将深入探索 Big Key 问题的源头讨论它如何影响系统性能并提供相应的解决策略。通过了解和解决 Big Key 问题我们可以更有效地利用 Redis优化我们的系统并提高性能。
Big Key问题介绍
在Redis中每个key都有一个对应的value如果某个key的value过大就会导致Redis的性能下降或者崩溃。
因为Redis需要将大key全部加载到内存中这会占用大量的内存空间会降低Redis的响应速度这个问题被称为Big Key问题。
不要小看这个问题它可是能让你的Redis瞬间变成“乌龟”由于Redis单线程的特性操作Big Key的通常比较耗时也就意味着Big Key阻塞Redis的可能性很大这样会造成客户端阻塞或者引起故障切换有可能导致“慢查询”或其他连锁反应。
一般而言下面这两种情况可以被称为Big Key
String 类型的 key 对应的value超过 10 MB。list、set、hash、zset等集合类型集合元素个数超过 5000个。 以上对Big Key的判断标准并不唯一只是一个大体的标准。在实际业务开发中对Big Key的判断是需要根据具体的使用场景做不同的判断。比如操作某个 key 导致请求响应时间变慢那么这个 key 就可以判定成 Big Key。 在Redis中Big Key通常是由以下几种原因导致的
对象序列化后的大小过大。存储大量数据的容器如set、list等。大型数据结构如bitmap、hyperloglog等。
如果不及时处理这些大key它们会逐渐消耗Redis服务器的内存资源最终导致Redis崩溃。
Big Key问题排查
当出现Redis性能急剧下降的情况时很可能是由于存在大key导致的。在排除大key问题时可以考虑采取以下几种方法
BIGKEYS命令
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 fields504 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中样本了506个键。这506个键总共占用了3452字节平均每个键占用6.82字节。最大的字符串键是’c’值有6字节。最大的列表键是’b’有100004个元素。最大的哈希键是’d’有3个字段。有504个字符串键总共1403字节占所有键的99.60%平均每个字符串键大小为2.78字节。有1个列表键包含100004个元素占所有键的0.20%平均每个列表键大小为100004个元素。没有集合(set)键。有1个哈希键包含3个字段占所有键的0.20%平均每个哈希键大小为3个字段。没有有序集合(zset)键。
这些信息可以帮助你理解Redis数据库的使用状态以便进行相应的优化或调整。
需要注意的是由于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:150redis 127.0.0.1:6379 DEBUG OBJECT key
(error) ERR no such key第一次运行命令时返回了 key 对应的具体信息。这些值的意思如下
Value at:0xb6838d20key 所在的内存地址。refcount:1引用计数表示该对象被引用的次数。encoding:raw编码类型这里是 raw 表示这个字符串对象的编码类型。serializedlength:9序列化后的长度。lru:283790LRU Least Recently Used信息即最近最少使用算法的相关信息在内存淘汰策略中会用到。lru_seconds_idle:150该 key 已空闲多久单位为秒也就是自从最后一次访问已经过去多少秒。
第二次运行命令时返回了 (error) ERR no such key说明在 Redis 中没有找到名为 ‘key’ 的键。
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的dbtype 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问题解决思路
当发现存在Big Key问题时我们需要及时采取措施来解决这个问题。下面列出几种可行的解决思路
分割大key
将Big Key拆分成多个小key。这个方法比较简单但是需要修改应用程序的代码。就像是把一个大蛋糕切成小蛋糕一样有点费力但是可以解决问题。
或者尝试将Big Key转换成Redis的其他数据结构。例如将Big Key转换成HashList或者Set等数据结构。
对象压缩
如果大key的产生原因主要是由于对象序列化后的体积过大我们可以考虑使用压缩算法来减小对象的大小。需要在客户端使用一些压缩算法对数据进行压缩和解压缩操作例如LZF、Snappy等。
直接删除
如果你使用的是Redis 4.0的版本可以直接使用 unlink命令去异步删除大key。4.0以下的版本 可以考虑使用 scan命令分批次删除。
无论采用哪种方法日常使用中都需要注意以下几点 避免使用过大的value。如果需要存储大量的数据可以将其拆分成多个小的value。就像是吃饭一样一口一口的吃不要贪多嚼不烂。 避免使用不必要的数据结构。例如如果只需要存储一个字符串就不要使用Hash或者List等数据结构。 定期清理过期的key。如果Redis中存在大量的过期key就会导致Redis的性能下降。就像是家里的垃圾需要定期清理。 对象压缩。
最后结束本文时我们要明确的是Redis Big Key问题是所有使用Redis作为数据存储方案的开发者都需要密切关注的重要话题。大Key可能会对Redis的性能产生严重影响或者导致意外的内存问题。
因此开发者应该充分利用现有的工具和策略来检测和避免Big Key。在使用Redis时需要注意避免使用过大的value和不必要的数据结构以及定期清理过期的key。
另外我们还应持续探索更高效、更可靠的解决方案来优化我们的Redis实例使其更稳定地为我们的应用提供服务。最后不断学习和实践才是提高我们对Redis使用的理解并准确处理Redis Big Key问题的最佳方式。
