redis五大核心数据结构各司其职：1.string适用于简单值、原子计数与轻量缓存；2.hash适合结构化对象字段级操作；3.list用于有序队列与时间线；4.set解决去重、标签与关系判定；5.zset支撑带权重排序与范围查询。
Redis 常用核心数据结构有五种：String、Hash、List、Set、Sorted Set（ZSet）。它们不是功能重叠的备选，而是针对不同业务逻辑设计的“工具”，选对结构直接影响性能、内存占用和代码可维护性。
String：适合简单值、原子操作与轻量缓存
String 是最基础的数据类型，本质是二进制安全的动态字符串（底层为 SDS 结构），支持整数编码优化、原子增减、过期控制等。
适用业务场景：
- 缓存单个对象（如用户 token、HTML 片段、JSON 序列化后的用户信息）
- 计数器类需求（文章阅读量、接口调用次数、库存扣减）
- 分布式锁（
SET key value NX PX 30000） - 全局唯一 ID 生成（
INCR global:seq）
注意点：
- 存储大对象（>10KB）会影响网络吞吐和响应延迟，建议拆分或改用 Hash
- 避免用
GET + SET实现计数，应直接用INCR/DECR保证原子性
Hash：适合结构化对象的字段级操作
Hash 把一个 key 映射为多个 field-value 对，类似内存中的 Map，支持单独读写某个字段，不需序列化整个对象。
适用业务场景：
- 用户资料存储（
HSET user:1001 name "Alice" age 28 email "a@b.com"） - 商品信息缓存（字段可独立更新：价格、库存、状态）
- 配置中心（各模块开关、灰度比例等字段可单独修改）
优势体现：
-
HINCRBY user:1001 score 5直接给某字段加积分，无需反序列化 -
HMGET user:1001 name avatar批量获取指定字段，减少带宽消耗 - 比 String 存 JSON 更省内存（尤其字段多但每次只读部分时）
List：适合有序队列与时间线类数据
List 是双向链表实现，支持头/尾 O(1) 插入与弹出，天然适合“先进先出”或“最新优先”的顺序场景。
适用业务场景：
- 简单消息队列（
LPUSH生产，BRPOP消费，适合低吞吐异步任务） - 用户动态/评论/通知时间线（
RPUSH新内容，LRANGE分页查最近 N 条） - 任务待办列表（高优任务
LPUSH，低优RPUSH，消费时按优先级调度）
关键技巧：
- 用
LTRIM key 0 99自动截断长度，防止无限增长 - 不适合随机索引访问（
LINDEX是 O(N)），大量随机读建议换 ZSet
Set：适合去重、标签、关系判定
Set 是无序唯一集合，底层哈希表实现，支持快速判断成员存在性，以及交、并、差集合运算。
适用业务场景：
- 用户行为去重（如“今日活跃用户”
SADD active:20260829 uid1001） - 标签系统（
SADD tag:java uid1001 uid1002，SINTER tag:java tag:spring查共有人群） - 权限组管理（用户所属角色集合，快速校验是否含某权限）
注意点：
- 不保证插入顺序，也不支持排序，需要排序请用 Sorted Set
- 成员必须是字符串，数字需转成字符串存储（如
"123"而非123）
Sorted Set（ZSet）：适合带权重的排序与范围查询
ZSet 在 Set 基础上为每个成员关联一个分数（score），按 score 排序，支持按分数范围、排名区间高效查询。
适用业务场景：
- 排行榜（用户积分、游戏胜率，
ZADD rank:week uid1001 9850） - 延迟队列（score 设为执行时间戳，
ZRANGEBYSCORE queue -inf now拉取到期任务） - 时间范围统计（日志按毫秒时间戳存 score，查某分钟内所有事件）
实用命令：
-
ZREVRANGE rank:week 0 9 WITHSCORES—— 获取 Top10 及分数 -
ZCOUNT rank:week 8000 10000—— 查分数在区间内的用户数 -
ZREM rank:week uid1001—— 移除某用户（比 List 删除更高效）
每种结构都有明确的边界和不可替代性。实际选型时，先问三个问题：
- 数据是否需要排序或范围查询？→ 优先考虑 ZSet
- 是否要按字段独立操作？→ 选 Hash
- 是否强调顺序、头尾操作、轻量队列？→ 选 List
- 是否核心诉求是去重、集合运算、标签匹配？→ 选 Set
- 其余大多数缓存、计数、锁、简单键值场景 → String 足够且最高效
不复杂但容易忽略
