5. Redis 数据类型总览

本节目标

• 记住 Redis 的「五大经典类型」：String、Hash、List、Set、Sorted Set
• 了解 Redis 8.x 新增/内置的扩展类型：JSON、向量集、概率类型、时间序列、Stream、Bitmap、Bitfield、Geospatial
• 掌握「什么业务场景该用哪个类型」的选型方法
• 理解为什么 Redis 是「数据结构服务器」而不是简单 KV

Redis 的核心是「数据结构服务器」：它不只是把任意字节串丢进一个桶，而是在 key 背后提供一组语义明确的数据结构。选对数据结构，很多业务需求能用一两条原生命令实现。

5-1 五大经典类型（必学）

这是绝大多数 Redis 应用的基石，后续章节会逐一深入。

类型	中文	本质	典型命令	典型场景
String	字符串	二进制安全的字节序列（文本/数字/对象）	SET GET INCR APPEND	缓存、计数器、分布式锁
Hash	哈希	字段-值映射表（类似对象）	HSET HGET HGETALL HINCRBY	存储对象、用户资料
List	列表	按插入顺序排序的字符串序列	LPUSH RPUSH LRANGE BLPOP	队列、栈、最新列表
Set	集合	无序、唯一的字符串集合	SADD SMEMBERS SINTER	去重、共同好友、标签
Sorted Set	有序集合	带 score 的唯一字符串集合	ZADD ZRANGE ZRANGEBYSCORE	排行榜、延迟队列

5-2 Redis 8 新增 / 内置的扩展类型

过去这些能力属于「Redis Stack」扩展包，需要单独安装；从 Redis 8 起，它们已作为内置模块随发行版一同提供，开箱即用。

• JSON：原生存储、查询、修改 JSON 文档，支持 JSONPath。适合存结构化配置、嵌套对象。
• 向量集（Vector Set，beta）：存储高维向量，基于 HNSW 算法做余弦相似度检索。是为 AI / 语义搜索 / RAG 准备的。
• 概率类型：用极小内存做近似统计——
  • Bloom Filter：判断「某元素是否可能在集合中」（去重、防穿透）
  • Cuckoo Filter：类似 Bloom，但支持删除和计数
  • Count-Min Sketch：估算某元素出现频次
  • Top-K：找出流里最频繁的 K 个元素
  • t-digest：估算海量数据的百分位数
  • HyperLogLog：估算集合基数（UV）
• 时间序列（Time Series）：按时间索引的数值点，适合监控指标。
• Geospatial：经纬度坐标，半径/矩形范围查询（附近的人、店）。
• Stream：追加式日志，支持消费组，是功能完备的消息队列/事件溯源结构。
• Bitmap / Bitfield：基于 String 的位操作，用于签到、权限位、紧凑计数器。

5-3 一张「选型地图」

不知道该用哪个类型时，按下面的思路判断：

1. 要不要缓存一个值 / 做一个计数器 / 存一个序列化对象？ → String。SET/GET/INCR 直接搞定。
2. 要不要存一个「对象」（多个字段，如用户资料）？ → Hash。整体或部分字段读写都很高效，比把整个对象序列化进 String 更灵活。
3. 要不要一个「有序/可重复」的序列，按时间进出？ → List。左进右出即队列，左进左出即栈；LRANGE 分页取最新 N 条。
4. 要不要「去重」或做集合运算（共同好友、标签交集）？ → Set。元素唯一，SINTER/SUNION/SDIFF 直接算。
5. 要不要「按分数排序」且去重（排行榜、热度榜）？ → Sorted Set。ZADD 加分、ZRANGE 取 Top N。
6. 要不要存结构化 JSON 文档并做字段级查询？ → JSON（v8 内置）。
7. 要不要做「近似去重 / 频次 / 基数 / TopK」且内存极小？ → 对应概率类型。
8. 要不要「消息队列 + 消费者组 + 持久化」？ → Stream。
9. 要不要「地理附近」查询？ → Geospatial。
10. 要不要做 AI 向量检索 / 语义搜索？ → 向量集（v8 beta）。

5-4 一个统一的小例子

同样一句「记录用户 antirez 的资料」，用不同结构表达：

# 1) 整个对象序列化进 String（简单但不好改单个字段）
127.0.0.1:6379> SET user:antirez '{"name":"antirez","age":55,"city":"Catania"}'
OK

# 2) 用 Hash 存（可读、可单独改字段、可原子自增）
127.0.0.1:6379> HSET user:antirez name antirez age 55 city Catania
(integer) 3
127.0.0.1:6379> HINCRBY user:antirez age 1
(integer) 56
127.0.0.1:6379> HGET user:antirez city
"Catania"

可以看到，Hash 在「对象 + 部分更新」场景下比 String 序列化更顺手——这就是「选对数据结构」的价值。

5-5 类型不可混淆

每个 key 在某一时刻只有一种类型；对错误类型执行不匹配的命令会报错：

127.0.0.1:6379> SET foo bar
OK
127.0.0.1:6379> HGETALL foo
(error) WRONGTYPE Operation against a key holding the wrong kind of value

遇到 WRONGTYPE 错误，先用 TYPE foo 查看它到底是什么类型，再决定是改命令还是先 DEL 重建。

5-6 数据类型与内存占用（先有概念）

选对类型不仅关乎「好不好写」，也关乎「省不省内存」。Redis 会对小对象做紧凑编码：小 Hash、小 List、小 Set、小 Sorted Set 内部用 listpack（旧版叫 ziplist）存储，远比真正的哈希表/跳表省内存；当元素数量或单值大小超过阈值（如 hash-max-listpack-entries 512），才自动转成常规结构。String 则区分「整数编码」「短字符串 embstr」「长字符串 raw」三种内部表示，整数和短串同样很省。理解了这一点，你就会明白：与其把几十个字段塞进一个大 JSON 字符串，不如用 Hash 让 Redis 帮你做紧凑编码与字段级操作——既省内存又灵活。具体的编码与「大 key」优化，本教程后续有专门章节展开。

5-7 常见误区

• 误区：Redis 只有 String。 错，它是数据结构服务器，五大经典类型 + 一批扩展类型。
• 误区：新类型都要自己装模块。 Redis 8 已内置 JSON、向量集、概率类型等，无需 MODULE LOAD。
• 误区：对象一律序列化进 String 最省事。 若常改其中某字段，用 Hash 更高效、更灵活。
• 误区：类型用错了命令会「自动转换」。 不会，类型不匹配直接 WRONGTYPE 报错。

5-8 小结

• 五大经典类型（String/Hash/List/Set/Sorted Set）是基本功，覆盖 90% 场景。
• Redis 8 把 JSON、向量集、概率类型、时间序列、Stream、Geospatial 等做成内置能力。
• 选型核心：缓存/计数用 String；对象用 Hash；有序序列用 List；去重/集合运算用 Set；排行榜用 Sorted Set；结构化文档用 JSON；队列用 Stream；AI 检索用向量集。
• 一个 key 同时只有一种类型，错用命令会 WRONGTYPE。

从下一章开始，我们逐个深挖数据类型。先从最基础也最常用的 String 讲起。