Redis 数据类型有哪几种？

2025年12月26日

面试考察点

面试官提出这个问题，主要是考察以下几个层面：

Redis 主要提供了以下 9 种数据类型，包含 5 种基本类型，以及 4 种高级拓展类型：

String（字符串）：最基本的数据类型，可存储文本、数字或二进制数据。
List（列表）：基于双向链表或压缩列表实现的字符串元素集合，按插入顺序排序，支持两端插入和弹出。
Set（集合）：无序、唯一的字符串元素集合。
Hash（哈希表/字典）：由 field-value 对组成的映射表，适合存储对象。
ZSet（Sorted Set，有序集合）：与 Set 类似，但每个元素都关联一个 score（分数），用于排序。元素唯一，但 score 可以重复。
Bitmaps（位图）：本质上是 String 类型上的一组面向位的操作，用于高效处理位信息（如用户签到）。
HyperLogLog（基数统计）：用于高效（使用固定极小内存）估算集合中唯一元素数量的概率性数据结构。
Geospatial（地理位置）：基于 ZSet 实现，用于存储和操作地理位置信息（经纬度）。
Stream（流）：Redis 5.0 引入，用于实现高性能的消息队列，支持多消费者组和消息持久化。

此外，通过 Redis 模块（如 RedisJSON， RediSearch），还可以支持 JSON、全文搜索等更复杂的数据类型。

String：不仅是简单的文本。其值可以是数字（整数或浮点数），并支持原子性的自增/自减操作。其底层会根据值的类型和长度，采用 int、 embstr 或 raw 三种编码格式来优化内存和性能。
List：早期版本在元素较少且较小时，采用内存紧凑的 ziplist（压缩列表）编码；否则采用双向链表 linkedlist。新版本中， quicklist（快速列表，一种 ziplist 组成的链表）成为了统一的底层实现，兼顾了内存效率和操作性能。
Hash：底层使用 ziplist（元素少时）或 hashtable（哈希表）。相比于将整个对象序列化成 JSON 后存入一个 String，使用 Hash 可以独立访问或修改单个字段，更节省网络开销和内存。
ZSet：其核心在于排序。内部使用一个 dict（哈希表）来保证元素 member 的唯一性，同时使用一个 skiplist（跳跃表）来根据 score 维护有序性。跳跃表支持平均 O(log N) 复杂度的范围查询。
Stream：作为消息队列，其核心结构是追加日志。每个消息有唯一的 ID，支持阻塞式读取，并借鉴了 Kafka 的设计，提供了消费者组的概念，允许同一消息被多个组独立消费，组内多个消费者负载均衡。

String：
- 场景：缓存简单值、计数器（INCR）、分布式锁（SET key value NX PX timeout）。
- 最佳实践：对于可能频繁更新的对象，考虑拆分为 Hash。
Hash：
- 场景：存储用户信息、商品信息等对象，尤其是当需要频繁修改其中部分字段时。
- 对比：与将所有字段序列化成 JSON String 相比，Hash 在部分更新时优势明显。
List：
- 场景：简单的消息队列（LPUSH/RPOP）、最新 N 条动态（LTRIM）。
- 注意：基于 List 的队列没有 ack 机制，消息可能丢失。对于可靠性要求高的场景，应使用 Stream。
Set：
- 场景：共同关注、共同好友（SINTER）、随机推荐（SRANDMEMBER）。
ZSet：
- 场景：实时排行榜（ZREVRANGE）、延迟队列（将执行时间作为 score）。
Bitmaps：
- 场景：用户每日签到统计（位偏移对应日期）、活跃用户统计。
- 优势：极其节省空间，1 亿用户的签到状态仅需约 12MB。
HyperLogLog：
- 场景：统计网站的独立访客（UV）总数。
- 注意：有约 0.81% 的标准误差，且只能统计总数，无法取出单条数据。

掌握 Redis 数据类型，关键在于不仅要记住 5 种基础类型和 4 种扩展类型，更要深入理解其底层数据结构的实现原理与各自最匹配的业务场景，从而在系统设计中做出最合理、最高效的选择。

发布于2022年12月20日|18:26:29