Redis 的基础数据结构有哪些，各自用于什么场景？

核心回答

Redis 常见的五种基础数据类型是 String、Hash、List、Set 和 Sorted Set（Zset）。选择时看需要怎样访问和修改数据：

• String：保存一个字节串，适合缓存整份 JSON、保存令牌或使用原子自增计数。
• Hash：在一个键下组织多组字段和值，适合用户信息、商品属性、购物车等需要按字段读写的对象。
• List：有顺序、允许重复的字符串序列，支持两端插入和弹出，适合近期记录、简单待处理列表等。
• Set：无序且成员唯一，支持成员判断和交并差，适合去重、标签集合、共同关注。
• Zset：成员唯一，每个成员关联一个分数，适合按分数排序、取排名或查范围，例如积分榜和按时间排序的任务索引。

这里说的是对外的数据模型，不等于底层编码。Redis 也有 Bitmap、HyperLogLog、GEO、Stream 等其他能力，不能把“五种基础类型”理解成所有版本只有五种类型。

对象缓存：String 和 Hash 怎么选？

如果商品详情通常整份读取、整份更新，可以把序列化 JSON 存成 String，读写方式简单。但 Redis 把这份 JSON 当字节串，普通 String 命令不会按 JSON 路径理解内部字段。

如果经常只读取名称、修改库存展示值或更新某个属性，Hash 可以直接按字段访问，减少整份对象的传输和序列化。购物车也可以把商品 ID 作为 field、数量作为 value，利用字段更新和增量操作管理内容。

两种方式都不是普遍更省内存：字段数量、内容长度、底层编码、键的组织方式都会影响占用。Hash 也不是任意嵌套的对象数据库，复杂结构仍需要合适的序列化或其他模型。

并发修改时还要考虑动作本身。多个客户端分别读整份 JSON、修改不同字段再覆盖，可能互相丢失更新；按字段操作可以缩小影响范围，但涉及多个字段的业务条件，仍要使用合适的原子操作或并发控制。

List、Set 和 Zset 的“顺序”有什么不同？

List 的顺序由插入位置和后续操作决定，成员可以重复。 例如聊天消息按一端写入，再按约定顺序读取历史。两端操作是常用优势；按位置查找、取大范围记录仍有遍历与返回成本，不能把所有操作都当成常数时间。

Set 不承诺插入顺序，也不保存重复成员。 比如每个用户的关注人集合，可以做成员判断或求共同关注。适合“有没有、是否重复、两个集合有什么关系”，不适合直接表达先后顺序或分数排名。

Zset 的成员唯一，但分数可以相同。 同分时按成员的字节字典序进一步排序；如果要按“谁先达到分数”决定名次，需要另行表达该业务规则，不能默认同分按写入先后排序。更新同一成员的分数，会调整它的位置，不会自动增加一份相同成员。

例如积分榜用 Zset 能直接查名次和分数范围，用 List 则需要自己维护位置；反过来，完整记录每次积分变更事件时，不能只靠 Zset 中该成员当前的一项分数代替历史。

什么时候考虑 Bitmap、HyperLogLog 和 GEO？

它们服务于更具体的查询需求：

• Bitmap：用位表示某对象的某个二值状态，例如签到或是否活跃。它是在 String 上进行的位操作；偏移很大而对象很稀疏时，不一定省空间。
• HyperLogLog：估算去重后的数量，例如访问用户数。它不保存可供逐个取回的完整成员集合，不适合要求精确名单或精确去重数的场景。
• GEO：按地理位置查询附近成员、计算距离等；它提供地理语义，不等于任意复杂空间分析数据库。

如果需要可重复读取的事件记录或消费组等能力，可以进一步比较 Stream。用 List 弹出一个元素，只代表它已从列表取走，不自动代表对应业务已处理成功；消息可靠性还涉及确认、重试与持久化等设计。

常见追问

为什么计数用 INCR，不先 GET 再 SET？ 单条自增在 Redis 中原子完成，避免多个客户端读到相同旧值后相互覆盖。若计数还要和过期、额度或外部扣款一起形成业务动作，仍需分析这些操作之间的原子范围。

Redis Hash 与整个 Redis 的键空间有什么区别？ 键空间是键到 Redis 对象的映射，值可以是 String、List、Hash 等；Hash 则是某一个键对应的字段集合。不能因为都涉及映射，就把所有 Redis 值都叫 Hash。

同一种类型为什么还会有多种底层结构？ Redis 会根据版本、数据规模和配置选择紧凑编码或其他结构，平衡内存与访问开销。面试先说明对外语义和主要操作，再按具体版本展开实现；不要把历史版本的编码表当成永远不变的对应关系。

对应教程

参考资料