Redis中Big Key该如何解决？

原创

已于 2024-08-19 11:39:41 修改 · 2.3k 阅读

25 ·

CC 4.0 BY-SA版权

文章标签：

#redis #数据库 #缓存

于 2024-08-16 18:21:34 首次发布

Big Key 问题是指某个键（key）的值（value）过大，这会导致 Redis 的性能下降

1、Big Key的产生

业务设计不合理

在设计应用时，如果对数据结构的设计不够精细，可能会导致单个 key 存储的数据量过大，没有合理地拆分成多个较小的 key

如：存储了大量数据的字符串、哈希表（hash）、列表（list）等，这会导致在执行涉及该键的操作时消耗更多的时间和资源。

未及时清理无用数据

如：忘记设置过期时间，没有定期删除过期或不再需要的数据，List结构中数据持续增加而没有弹出数据的机制，那么数据会越来越多

数据类型选择不当

不同的数据类型有不同的内存使用特点。例如，使用字符串类型存储大量数据可能不如使用哈希（HASH）类型来得高效。
选择不适合的数据类型可能导致内存使用效率低下，进而产生 Big Key

如：文件二进制数据不使用 String 保存、使用 HyperLogLog 统计页面 UV、Bitmap 保存状态信息（0/1）

动态增长管理不当

某些数据结构可能随着时间和用户行为的变化而不断增长，如果没有适当的管理机制来控制其增长，就可能导致 Big Key 的出现。

如：日志记录、历史数据存储、某个明星热点粉丝列表或者评论的列表等功能如果没有合理的清理策略，可能会导致 key 的数据量逐渐增大

2、BigKey场景分析

以以下常见的场景分析Big Key的问题以及解决方案：

1. 用户行为日志记录

场景描述：应用程序记录用户的行为日志，如点击事件、浏览历史等，通常会将这些数据存储在一个用户的键中。
问题产生：随着用户行为的增多，单一用户的日志数据量会逐渐增大，形成 BigKey。
解决方案：分割日志数据到多个键中，例如按照日期分割。定期归档或清理旧的日志数据

2. 产品目录或商品信息

场景描述：电商平台或零售系统中，每个商品可能包含大量的属性信息，如规格、价格、库存等。
问题产生：如果将所有商品信息都存储在一个键中，随着商品数量的增加，键的大小也会增加。
解决方案：将商品信息拆分为多个键，例如按类别或品牌存储。使用更高效的数据结构，如使用哈希表存储商品的属性

3. 社交网络的好友关系

场景描述：社交应用中，每个用户都有自己的好友列表。
问题产生：当用户的好友数量非常多时，存储好友列表的键可能会变得非常大。
解决方案：将好友列表拆分为多个键，例如按照字母顺序或好友活跃度进行分组。使用有序集合（Sorted Set）存储好友列表，便于快速查找和排序

4. 会话状态存储

场景描述：Web 应用程序中，会话状态通常需要在服务器端存储。
问题产生：如果每个用户的会话状态包含了大量数据，如购物车、登录信息等，会话状态键可能会变得非常大。
解决方案：将会话状态拆分为多个键，例如将购物车和其他状态分开。定期清理过期的会话状态。

3、Big Key的危害

性能下降

对 BigKey 执行批量操作，如 HGETALL 或 HSETALL，这些命令的时间复杂度通常是 O(N)，其中 N 是键中元素的数量。当 N 很大时，这些操作会变得非常耗时，尤其是在 Redis 的单线程模型下

内存占用

BigKey 占用过多的内存，可能导致 Redis 的整体内存使用过高，从而触发内存淘汰策略，影响其他键的性能

网络拥塞

BigKey 在网络上传输时会占用较多带宽，特别是当客户端频繁读取或写入 BigKey 时，可能会导致网络拥塞。

超时阻塞

Redis 的主要命令执行是在单线程中完成的，这意味着在执行 BigKey 相关操作时，其他客户端的请求会被阻塞，直到该操作完成

最低0.47元/天解锁文章

200万优质内容无限畅学