Redis中的Key结构

已于 2024-07-29 21:49:58 修改
阅读量612 收藏 4
点赞数 7
CC 4.0 BY-SA版权
分类专栏： Redis 文章标签： redis bootstrap 数据库
于 2024-07-29 21:35:44 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/xycxycooo/article/details/140781860

Redis中的Key结构

概述

在Redis中，没有类似关系型数据库中的表（Table）概念，因此我们需要通过特定的命名规范来区分不同类型的键（key）。为了避免键的冲突，我们可以使用层级结构来命名键，通过添加前缀来区分不同类型的数据。

Key的命名规范

Redis的键允许有多个单词形成层级结构，多个单词之间用冒号（:）隔开。推荐的格式如下：

项目名:业务名:类型:id

这个格式可以根据实际需求进行调整，但目的是为了使键的命名更加清晰和有组织。

示例

假设我们的项目名称叫 heima，需要存储用户（user）和商品（product）信息。我们可以这样定义键：

  • 用户相关的键：heima:user:1
  • 商品相关的键：heima:product:1

这样，即使用户ID和商品ID相同，也不会发生冲突。

存储Java对象

如果需要存储Java对象，例如一个User对象，可以将对象序列化为JSON字符串后存储。例如：

KEY VALUE
了解本专栏 订阅专栏 解锁全文 超级会员免费看
redis 查看key的结构类型_Redis-1 数据类型与数据结构
weixin_32110907的博客
01-24 5070
1 Redis 简介Redis 是一个key-value的存储系统，使用ANSI C语言编写，key的类型是字符串，value的类型有：string字符串类型，list列表类型，set集合类型，sortset有序集合类型，hash类型，bitmap类型，geo地图坐标类型，stream流类型。Reids的命令不区分大小写，key value 区分大小写2 Redis 底层数据结构2.1 Redis...
Redis中的bigkey的介绍及影响
weixin_50055999的博客
06-23 1696
Redis中的大key问题（BigKey）是指某个key对应的value占用内存过大或元素数量过多，导致性能下降、内存碎片化、网络阻塞等一系列问题。大key通常定义为字符串类型value超过1MB或集合类型元素超过1万个。主要影响包括Redis单线程阻塞、内存不均衡、持久化风险及集群运维困难。解决方案包括合理设计数据结构、拆分大key、设置过期时间、启用内存淘汰策略、数据压缩及渐进式删除等。通过定期监控和优化，可有效缓解大key问题，保障Redis高性能运行。
Redis命令-Key的层级结构
qq_28770419的博客
03-28 1306
一旦我们向redis采用这样的方式存储，那么在可视化界面中，redis会以层级结构来进行存储，形成类似于这样的结构，更加方便Redis获取数据。例如，需要存储用户.商品信息到redis，有一个用户id是1，有一个商品id恰好也是1，此时如果使用id作为key，那就会冲突了，该怎么办？HSETNX：添加一个hash类型的key的field值，前提是这个field不存在，否则不执行。HGETALL：获取一个hash类型的key中的所有的field和value。### 4.5 Redis命令-Hash命令。
Redis篇--数据结构篇8--Redis数据结构架构篇（全局键空间，key存储结构，值存储结构，对象头）
weisian的博客
12-18 1799
字典（Dictionary）：Redis使用字典来存储键值对。字典是一个键到值的映射结构，支持快速查找、插入和删除操作。- 哈希表（Hash Table）：字典的底层实现是哈希表。每个哈希表由多个桶（bucket）组成，每个桶可以存储多个键值对。为了减少哈希冲突，Redis使用了拉链法（Separate Chaining），即当多个键的哈希值相同（发生冲突）时，它们会被存储在一个链表中。- 渐进式 rehash：为了应对哈希表扩展或收缩时的性能问题，Redis实现了渐进式rehash。
Redis：Redis的数据结构、key的操作命令
dengfengling999的博客
07-03 812
目录：（1）Redis的5种数据结构（2）key的操作命令1（3）key的操作命令2（4）key的操作命令3 （1）Redis的5种数据结构1.字符串类型 string字符串类型是Redis中最基本的数据结构，它能存储任何类型的数据，包括二进制数据，序列化后的数据，JSON化的对象甚至是一张图片。最大512M。2.列表类型 listRedis列表是简单的字符串列表，按照插入顺序排序，元素可以重复。你可以添加一个元素到列表的头部（左边）或者尾部（右边）,底层是个链表结构。3.集合类型 setRedis的Set
redis key设计技巧
plgy_Y的博客
05-15 2065
把表名转换为key前缀， 第二端放置表用于区分区key的字段–对应mysql中的主键的列名如userid。 3.放置主键值，如1，2，3，…..,a,b,c。 4.放要存储的列名 user表 userid user_name password email 1 zhangsan toor 666@abc.com set user:userid:1:user_name
【Redis】Redis命令-Key的层级结构
qq_39921135的博客
08-04 870
redis是键值型的数据库，因此它的键要求唯一，因此大多数情况下我们都会以数据的id来作为key，形成唯一标识。但是这里就会存在一个问题了：Redis没有类似MySQL中的Table的概念，没有表，所有数据都是存在一起的，那么我们该如何区分不同类型的key呢？例如，需要存储用户、商品信息到redis，有一个用户id是1，有一个商品id恰好也是1，此时如果使用id作为key，那就会冲突了，该怎么办？
精选资源
监听redis的key的变化
01-16
在IT行业中，Redis是一款广泛应用的内存数据存储系统，它支持多种数据结构如字符串、哈希、列表、集合、有序集合等。"监听Redis的key变化"是一个常见的需求，特别是在实时数据处理、事件驱动的系统中。这个主题涉及...
redis：Redis Big Key问题深度解析与解决方案
weixin_43290370的博客
07-03 1438
预防为主：建立完善的监控和预警机制拆分优先：采用垂直/水平拆分方案渐进处理：使用SCAN系列命令逐步操作智能治理：结合自动压缩和本地缓存建立Key规范（如：String≤10KB，Hash≤1000元素）实现实时监控大盘（Grafana+Prometheus）开发自动处理工具（自动拆分/压缩/迁移）定期执行Big Key扫描（redis-cli --bigkeys）关键操作添加熔断保护（Hystrix/Sentinel）
redis key有冒号(:) 双引号 通过redis-client
kongkong的专栏
05-07 5892
hget 7193278945204828bd306e5d43154ca4:workflow:node "\"782C7004788A4B8F9480240AA180027C:2\"" hget "7193278945204828bd306e5d43154ca4:workflow:node" "\"782C7004788A4B8F9480240AA180027C:2\""...
【Redis】Redis使用“：”对key进行分类存储
lisheng19870305的专栏
08-25 919
通常存在redis中的key值是这个样子的，只看key值，我们很难知道这个key值是干什么的，有什么用处。 所以需要我们对key值进行一定的分类： 使用“：”冒号来体现层次。 例如：set intern:user:user_code 123456 得到形式如下： 原文地址：https://blog.youkuaiyun.com/n950814abc/article/details/94199597 ...
Redis key的使用
chy-x 的博客
05-27 1562
目录库操作key常用命令key的有效期查找所有满足匹配规则的keybig key问题key命名建议   redis命令的关键字不区分大小写。   库操作 redis默认有16个数据库，第一个数据库是db0，第16个数据库是db15，可在redis.conf中指定数据库个数。 select 0 #选择、切换数据库，不指定时默认使用db0 dbsize #返回当前数据库中key的数量 flushdb #清空当前数据库 flushall #清空所有数据库   key常
redis设置已文件夹形式展示key，value
彦楠的博客
10-17 2313
1，存储key时候可以使用 : 将其隔开，就是建立文件夹 2，执行命令 set 1:2:3:4 v 3，执行效果 其实key就是1:2:3:4 值是v 只是在RDM中可以按文件夹显示 就是
Redis通用命令和key的层级结构
qq_59212867的博客
11-17 2463
redis数据结构、redis通用命令及redis命令-key的层级结构
Redis——key命名规范及redis容量预估
热门推荐
娜娜米的博客
04-12 1万+
Redis——命名规范及容量预估
Redis数据结构01key
weixin_45012397的博客
05-31 188
【代码】Redis数据结构01key。
Redis基础教程（四）：redis键(key)
菜鸟小码的博客
06-30 1658
Redis 的键（Key）是其数据模型的核心组成部分，几乎所有的数据操作都是围绕键来进行的。键在 Redis 中用于唯一标识数据，可以存储各种类型的数据，包括字符串、哈希、列表、集合、有序集合等。
关于redis key命名规范的设计
weixin_43398591的博客
10-27 1006
关于redis key命名规范的设计 https://www.cnblogs.com/joshua317/p/11995197.html 一、实现目标 简洁，高效，可维护 二、键值设计规约 1 、 Redis key命名风格 【推荐】Redis key命名需具有可读性以及可管理性，不该使用含义不清的key以及特别长的key名； 【强制】以英文字母开头，命名中只能出现小写字母、数字、英文点号(.)和英文半角冒号(????； 【强制】不要包含特殊字符，如下划线、空格、换行、单双引号以及其他转义字符； 2 、
redis中key可以多长
最新发布
09-21
<think> 我们正在讨论Redis的key的长度限制问题。根据引用[2]中的信息："Redis的key和value大小限制： key：最大长度为512MB，可以是任意字符串，包括二进制数据。" 但是这里需要注意的是，512MB实际上是value的限制（对于String类型），而key的最大长度是多少呢？ 实际上，引用[2]中明确提到key的最大长度是512MB，但这是一个非常不常见的说法。通常，我们讨论的是key的字符串长度（以字节为单位）而不是内存占用大小。 然而，在Redis中，key的长度限制实际上是以字节为单位的最大长度。根据Redis官方文档，key的最大长度是512MB这个说法并不准确。实际上，Redis的key的最大长度限制是512MB？这显然不合理，因为一个key如果占用512MB内存，那么整个Redis实例可能也存不了几个key。 实际上，在Redis中，key的最大长度是512MB这个说法是错误的。我们重新审视引用[4]："内存分配机制 Redis 使用 zmalloc 内存分配器，单个 Key 超过 512MB 时会触发内存分配失败"。这里指的是value的大小（String类型）不能超过512MB，而不是key。 那么key的长度限制是多少呢？根据Redis官方文档（以及引用[2]中的说法实际上是错误的），key的最大长度是512MB？不，实际上key是一个字符串，它的最大长度（以字节计）应该是2^32-1（即4GB）？但是实际上Redis并没有这样设置。 实际上，Redis的key是一个二进制安全的字符串，理论上最大长度为512MB。但是，这个512MB指的是什么？是内存大小还是字符串长度？因为字符串长度和内存大小在字符串中是一一对应的（每个字节一个字符）。 然而，在Redis中，key的最大长度被限制为512MB（即512*1024*1024字节）？这显然是不合理的，因为一个key占用512MB内存，那么存储一个key就需要非常大的连续内存，这在实际中几乎不可能。 实际上，根据Redis的源代码和官方文档，key的最大长度是512MB这个说法并不准确。更准确地说，Redis中字符串类型的value最大为512MB，而key的最大长度实际上也是受同一个限制：即一个字符串最大为512MB，所以key的最大长度也是512MB（即最多512*1024*1024个字节）。但是，这个限制在现实中几乎不会遇到，因为没有人会使用一个长达几百兆的key。 所以，回答用户问题：Redis中key的长度限制是多少？ 根据引用[2]和引用[4]的信息，我们总结： Redis的key最大长度为512MB（以字节为单位），即一个key可以是一个最大512MB的字符串。但是，这个限制实际上和字符串值的限制是一样的。然而，在实际应用中，我们几乎不会使用这么长的key。 另外，需要注意的是，虽然理论上key可以很大，但是过大的key（BigKey）会带来很多问题，如引用[3]、[4]、[5]中提到的：内存占用大、删除耗时、阻塞请求等。因此，实践中我们应该避免使用过长的key。 所以，回答如下： 在Redis中，key的最大长度限制为512MB（即536,870,912字节）[^2][^4]。这意味着一个key可以是任意二进制数据，但总长度不能超过512MB。然而，在实际应用中，我们强烈建议使用短小且具有语义的key，原因如下： 1. **内存效率**：过长的key会占用大量内存空间 2. **性能影响**：大key的查找、删除操作会显著增加延迟 3. **集群限制**：在Redis集群模式下，过大的key可能导致数据分片不均 例如，以下是不推荐的超大key： ```bash # 不推荐：使用1MB的key（实际场景中仍过大） SET "巨型键名_此处省略1MB数据..." "值" ``` 建议采用简洁的key命名方式： ```bash SET user:10001:profile "{...json数据...}" ``` > 注意事项：当key长度接近512MB时，操作将触发`ERR string exceeds maximum allowed size`错误[^4] 相关问题： 1. Redis中value的大小限制根据数据类型有何不同？ 2. 如何检测和处理Redis中的大Key(BigKey)？ 3. Redis集群对大Key有什么特殊限制？ </think> ### Redis Key 长度限制详解 #### 一、核心限制规范 根据 Redis 官方文档和实际实现机制： 1. **最大字节长度**： Redis Key 最大允许 **512MB**（即 512 × 1024 × 1024 字节）的二进制安全字符串[^2][^4] 2. **存储机制**： 所有 Key 均以二进制安全字符串存储，支持任意字符（包括 `\0`） $$ \text{Key} \in \{ \text{byte array} \mid \text{length} \leq 512\text{MB} \} $$ > 示例数值： > - 512MB = 536,870,912 字节 > - 可存储约 2.68 亿个汉字（GBK编码）或 5.36 亿个 ASCII 字符 #### 二、内存分配原理 Redis 使用 **zmalloc 内存分配器**实现 Key 存储： 1. 单个 Key > 512MB 时触发分配失败 ```bash SET giant_key [513MB数据] # 返回错误：(error) ERR string exceeds maximum allowed size ``` 2. 内存碎片限制：连续内存块不足时，即使 <512MB 也可能分配失败[^4] #### 三、实际应用约束 | 场景 | 推荐阈值 | 风险说明 | |---------------|---------------|--------------------------| | 生产环境 Key | ≤ 1KB | 避免内存碎片和检索延迟[^3] | | 危险边界 | > 100KB | 显著增加操作延迟[^5] | | 绝对上限 | 512MB | 触发系统级错误[^4] | #### 四、大 Key 处理策略 当 Key 过大时（如 > 10KB），建议： ```java // Java 示例：拆分大 Key public void splitBigKey(RedisTemplate template, String bigKey, int chunkSize) { byte[] data = template.opsForValue().get(bigKey.getBytes()); for (int i = 0; i < data.length; i += chunkSize) { byte[] chunk = Arrays.copyOfRange(data, i, Math.min(i + chunkSize, data.length)); template.opsForValue().set(bigKey + ":chunk_" + i/chunkSize, chunk); } template.delete(bigKey); // 删除原始大 Key } ``` **优化效果**： - 删除 100 万元素的 Hash 耗时可从 1000ms 降至 50ms 以下[^3] #### 五、关键建议 1. **命名规范**： - 使用 `user:1234:profile` 层级结构替代长字符串 2. **监控工具**： ```bash redis-cli --bigkeys # 扫描大 Key MEMORY USAGE key_name # 查看具体 Key 内存占用 ``` 3. **数据类型选择**： - >10KB 数据优先用 Hash/List 而非 String[^5] > 📌 注意：512MB 是**理论极限值**，实际生产环境应保持 Key <1KB 以确保性能[^3][^5] ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

需要重新演唱

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值