Redis 核心数据结构选型：String、Hash、List、Set、Sorted Set 在缓存场景的适用性

在微服务并发瓶颈调优中，选错数据结构是导致缓存性能劣化的首要原因。Redis 提供五种核心数据结构，每种都有独特的底层编码、时间复杂度与适用边界。本章从缓存场景的读写模式、内存效率、并发安全三个维度，逐一剖析选型依据。

一、数据结构全景对比

二、String：最轻量的缓存原子

String 是 Redis 最基础的数据结构，最大 512 MB。在缓存场景中，它适合存储独立、不可拆分的值，例如序列化后的 JSON、Session ID、计数器。

• 并发优势：单键操作天然原子性，INCR/DECR 适合秒杀库存、访问计数。
• 内存陷阱：大量小键值对会膨胀 Redis 内存（每个键约 50 字节元数据），建议用 Hash 聚合。
• 典型反模式：将整个用户对象序列化为一个 String，每次只更新一个字段却要整体读写，浪费带宽与 CPU。

// 正确：计数器场景
SET article:123:views 0
INCR article:123:views

// 错误：对象全量更新
SET user:1001 '{"name":"Alice","age":30,"email":"a@b.com"}'
// 只改 age 字段仍需 GET 反序列化 → 修改 → SET 序列化

三、Hash：对象级缓存的正确姿势

Hash 将对象的多个字段存储在同一键下，支持单字段 O(1) 读写，避免 String 全量序列化的开销。在微服务中，用户资料、商品 SKU、配置参数等结构化数据首选 Hash。

• 内存优化：当字段数 < 512 且每个字段值 < 64 字节时，自动使用 ziplist 编码，内存效率接近 String。
• 并发安全：HINCRBY 支持字段级原子增减，适合积分、余额等高频更新。
• 注意事项：避免单个 Hash 存储过多字段（建议 < 1000），否则全量 HGETALL 会阻塞。

// 用户资料缓存
HSET user:1001 name "Alice" age 30 email "a@b.com"
HGET user:1001 name        // O(1) 单字段读取
HINCRBY user:1001 age 1    // 原子年龄更新

四、List：队列与时间线场景

List 基于 quicklist（压缩链表 + 双向链表）实现，头尾操作 O(1)，适合先进先出（FIFO）或后进先出（LIFO）场景。在缓存中常用于消息队列、最新动态列表。

• 并发模型：LPUSH + BRPOP 实现生产者-消费者模式，BRPOP 阻塞等待减少空轮询。
• 长度控制：使用 LTRIM 限制列表长度，防止无限增长导致内存泄漏。
• 性能瓶颈：索引访问 O(n)，不适合随机读取；大量元素时 LINDEX 性能急剧下降。

// 最新 100 条评论
LPUSH comments:article:456 "Great post!"
LTRIM comments:article:456 0 99

// 阻塞消费
BRPOP task:queue 5   // 等待 5 秒，超时返回 nil

五、Set：去重与集合运算

Set 基于哈希表或整数集合，增删查 O(1)，天然去重。在缓存中适合标签系统、用户关注关系、IP 白名单等需要快速判断成员存在的场景。

• 并发优势：SADD/SREM 原子操作，适合秒杀去重、每日签到。
• 集合运算：SINTER（交集）、SUNION（并集）、SDIFF（差集）在数据量 < 5000 时性能可接受，大数据量建议在应用层分片。
• 内存注意：所有元素为字符串，大集合（百万级）会占用数百 MB 内存，需评估容量。

// 用户标签系统
SADD user:1001:tags "tech" "redis" "microservice"
SISMEMBER user:1001:tags "redis"   // O(1) 判断

// 共同关注
SINTER user:1001:follows user:1002:follows

六、Sorted Set：排序与范围查询之王

Sorted Set 使用跳表 + 哈希表双结构，插入、删除、按分数查询均为 O(log n)。在缓存中，排行榜、延时队列、滑动窗口限流等场景不可替代。

• 核心能力：ZRANGEBYSCORE 按分数范围获取元素，ZREVRANK 获取排名，适合实时排行榜。
• 延时队列：将任务执行时间戳作为 score，消费者轮询 ZRANGEBYSCORE 获取到期任务。
• 内存代价：每个元素约 40-60 字节额外开销（跳表指针 + 哈希表指针），大数据量时内存膨胀明显。

// 实时排行榜
ZADD leaderboard:game1 1000 "player_A"
ZADD leaderboard:game1 850  "player_B"
ZREVRANGE leaderboard:game1 0 9 WITHSCORES  // 前十名

// 延时队列
ZADD delay:queue 1700000000 "task:123"
ZRANGEBYSCORE delay:queue 0 1700000000  // 获取到期任务

七、选型决策流程

下图总结了从业务需求到数据结构的决策路径，帮助你在微服务缓存设计中快速定位最优结构。

八、并发场景下的选型建议