Hash List Set ZSet
Hash、List、Set 和 Sorted Set 是 Redis 建模的主力结构。它们分别面向对象字段、顺序队列、去重集合和有序集合，很多业务可以通过组合它们高效实现。
# 1. 学习定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 数据结构进阶 |
| 核心目标 | 先会用，再理解机制，最后能做工程取舍和故障分析 |
| 学习方法 | 带着业务场景看命令、SQL、数据结构、日志和运行时指标 |
# 2. 核心地图
Hash List Set ZSet
├─ Hash 字段
├─ List 双端队列
├─ Set 去重
├─ Sorted Set 排名
├─ 集合运算
├─ 范围查询
└─ 内部编码
# 3. 小章节深度讲解
下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。
# 3.1. Hash 字段
# 是什么
Hash 字段 属于 Redis 数据结构或内部编码。Redis 的性能来自“用合适结构表达合适问题”，而不是把所有内容都塞进一个大字符串。
# 开发人员怎么用
开发人员要根据访问模式选型：整体缓存用 String，局部字段用 Hash，排行用 ZSet，可靠消息用 Stream，近似统计用 HyperLogLog 或概率结构。
# 运维人员怎么看
运维人员要观察单 key 大小、元素数量、编码转换、内存占用和慢命令。内部编码从紧凑结构转换为哈希表或跳表后，内存和耗时可能阶跃变化。
# 常见风险
常见风险是 key 粒度失控：过细导致 key 数爆炸，过粗形成大 key。专家级建模要在访问效率和运维可控之间取平衡。
# 3.2. List 双端队列
# 是什么
List 双端队列 属于 Redis 数据结构或内部编码。Redis 的性能来自“用合适结构表达合适问题”，而不是把所有内容都塞进一个大字符串。
# 开发人员怎么用
开发人员要根据访问模式选型：整体缓存用 String，局部字段用 Hash，排行用 ZSet，可靠消息用 Stream，近似统计用 HyperLogLog 或概率结构。
# 运维人员怎么看
运维人员要观察单 key 大小、元素数量、编码转换、内存占用和慢命令。内部编码从紧凑结构转换为哈希表或跳表后，内存和耗时可能阶跃变化。
# 常见风险
常见风险是 key 粒度失控：过细导致 key 数爆炸，过粗形成大 key。专家级建模要在访问效率和运维可控之间取平衡。
# 3.3. Set 去重
# 是什么
Set 去重 属于 Redis 数据结构或内部编码。Redis 的性能来自“用合适结构表达合适问题”，而不是把所有内容都塞进一个大字符串。
# 开发人员怎么用
开发人员要根据访问模式选型：整体缓存用 String，局部字段用 Hash，排行用 ZSet，可靠消息用 Stream，近似统计用 HyperLogLog 或概率结构。
# 运维人员怎么看
运维人员要观察单 key 大小、元素数量、编码转换、内存占用和慢命令。内部编码从紧凑结构转换为哈希表或跳表后，内存和耗时可能阶跃变化。
# 常见风险
常见风险是 key 粒度失控：过细导致 key 数爆炸，过粗形成大 key。专家级建模要在访问效率和运维可控之间取平衡。
# 3.4. Sorted Set 排名
# 是什么
Sorted Set 排名 属于 Redis 数据结构或内部编码。Redis 的性能来自“用合适结构表达合适问题”，而不是把所有内容都塞进一个大字符串。
# 开发人员怎么用
开发人员要根据访问模式选型：整体缓存用 String，局部字段用 Hash，排行用 ZSet，可靠消息用 Stream，近似统计用 HyperLogLog 或概率结构。
# 运维人员怎么看
运维人员要观察单 key 大小、元素数量、编码转换、内存占用和慢命令。内部编码从紧凑结构转换为哈希表或跳表后，内存和耗时可能阶跃变化。
# 常见风险
常见风险是 key 粒度失控：过细导致 key 数爆炸，过粗形成大 key。专家级建模要在访问效率和运维可控之间取平衡。
# 3.5. 集合运算
# 是什么
集合运算 属于 Redis 具体数据结构能力或缓存策略。它的价值取决于访问模式、数据规模、误差边界和失败补偿。
# 开发人员怎么用
开发人员要明确它服务的是计数、范围查询、近似统计、缓存回源、降级还是一致性控制，并写清楚异常和重复执行时的语义。
# 运维人员怎么看
运维人员要观察命令复杂度、返回大小、内存增长、命中率、回源量和慢命令。近似结构还要关注误差是否被业务接受。
# 常见风险
常见风险是把策略名当答案。比如 Cache Aside 仍要处理删缓存失败，近似统计不能用于财务精确结果，复杂搜索不能和核心缓存混用。
# 3.6. 范围查询
# 是什么
范围查询 属于 Redis 具体数据结构能力或缓存策略。它的价值取决于访问模式、数据规模、误差边界和失败补偿。
# 开发人员怎么用
开发人员要明确它服务的是计数、范围查询、近似统计、缓存回源、降级还是一致性控制，并写清楚异常和重复执行时的语义。
# 运维人员怎么看
运维人员要观察命令复杂度、返回大小、内存增长、命中率、回源量和慢命令。近似结构还要关注误差是否被业务接受。
# 常见风险
常见风险是把策略名当答案。比如 Cache Aside 仍要处理删缓存失败，近似统计不能用于财务精确结果，复杂搜索不能和核心缓存混用。
# 3.7. 内部编码
# 是什么
内部编码 属于 Redis 数据结构或内部编码。Redis 的性能来自“用合适结构表达合适问题”，而不是把所有内容都塞进一个大字符串。
# 开发人员怎么用
开发人员要根据访问模式选型：整体缓存用 String，局部字段用 Hash，排行用 ZSet，可靠消息用 Stream，近似统计用 HyperLogLog 或概率结构。
# 运维人员怎么看
运维人员要观察单 key 大小、元素数量、编码转换、内存占用和慢命令。内部编码从紧凑结构转换为哈希表或跳表后，内存和耗时可能阶跃变化。
# 常见风险
常见风险是 key 粒度失控：过细导致 key 数爆炸，过粗形成大 key。专家级建模要在访问效率和运维可控之间取平衡。
# 3.8. 本篇学习实验
建议准备一个独立 Redis 实例，构造小 key、大 key、热点 key、过期 key 和慢命令，观察 INFO、SLOWLOG、LATENCY、内存变化和客户端超时。每个实验都要记录命令复杂度和返回数据量。
开发侧实验重点是理解数据结构和命令边界，运维侧实验重点是理解延迟、内存和复制如何变化。真正掌握本篇内容，应该能从延迟尖刺反推大 key、慢命令、持久化或网络问题。
# 4. 核心机制
- Hash 适合保存对象字段，小对象通常有紧凑编码，大对象会转为哈希表编码。
- List 适合两端插入弹出，现代 Redis 内部常用 quicklist/listpack 组合实现。
- Set 支持去重和交并差集，适合标签、关系和随机抽样。
- Sorted Set 通过 score 排序，常用于排行榜、时间线和延迟队列。
# 5. 工程实践
- 用户资料缓存可用 Hash，但大字段或复杂嵌套结构要谨慎。
- 简单任务队列可用 List，可靠消费优先考虑 Stream。
- 标签、关注关系可用 Set，但集合运算要控制规模。
- 排行榜 ZSet 要规划周期 key，例如日榜、周榜、总榜分开。
# 6. 常见坑
- Hash 里塞入大量字段，形成难迁移大 key。
- List 消费失败无法确认，消息可靠性不足。
- Set 交集运算作用在超大集合上阻塞主线程。
- ZSet score 设计不稳定，导致排序语义混乱。
# 7. 专家视角
- 这些结构要按命令复杂度和返回结果大小使用，不能只看功能匹配。
- 专家会为集合类 key 设置拆分策略和归档策略。
- ZSet 是 Redis 最有工程价值的结构之一，但延迟队列、排行榜和时间线的边界完全不同。
# 8. Tips 快问快答
Q：Hash 能替代对象表吗？
A：不能。它适合缓存或轻量对象存储，不提供关系约束和复杂查询。
Q：List 适合可靠消息吗？
A：只适合简单队列，可靠消费更推荐 Stream 或专业消息队列。
Q：ZSet 分数可以重复吗？
A：可以。分数相同再按成员字典序排序，业务要考虑并列情况。
# 9. 阶段小结
Hash List Set ZSet 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。