Redis应用 数据结构 Redis多样集合类型初探，了解redis集合的主要种类

Redis多样集合类型初探：解锁数据存储的瑞士军刀 🔥

场景引入：当电商系统遇上数据混乱

想象一下,你正在运营一个日活百万的电商平台🛒，某个周五晚上8点大促活动开始后，你的系统突然开始报警：

• 用户购物车数据莫名其妙丢失🛒
• 热门商品排行榜更新延迟严重📊
• 秒杀活动的库存计数出现超卖💸

这时你的技术主管拍了拍你肩膀："用Redis集合类型重构存储层吧，每种数据结构都是为特定场景而生的瑞士军刀🔪！"

Redis集合类型全景图

Redis不是简单的键值存储,它提供了5种核心数据结构，就像数据工程师的工具箱🧰：

1. String（字符串） - 最简单的类型
2. List（列表） - 有序可重复集合
3. Set（集合） - 无序唯一集合
4. Hash（哈希） - 字段值对集合
5. Zset（有序集合） - 带分数的排序集合

今天我们就重点探索后四种集合类型的魔法✨

List：消息队列的基石

典型特征

• 有序的元素集合（插入顺序）
• 允许重复元素
• 双向操作（头尾都可操作）

# 基础操作示例
LPUSH orders "order123"  # 左侧插入
RPUSH orders "order456"  # 右侧插入
LRANGE orders 0 -1       # 获取全部元素

实战场景

• 最新消息展示：朋友圈动态时间线
• 消息队列：简易版订单处理系统
• 历史记录：用户最近浏览商品

⚠️ 注意：超长List（百万级）可能引发性能问题，需要分片处理

Set：去重小能手

典型特征

• 无序的唯一元素集合
• 极快的成员存在性检查
• 支持集合运算（并集/交集/差集）

SADD user:1001:favorites "item42"  # 添加收藏
SISMEMBER user:1001:favorites "item42"  # 检查收藏
SCARD user:1001:favorites  # 计数

实战场景

• 标签系统：文章标签管理
• 社交关系：共同好友计算
• 抽奖系统：确保用户不重复参与

💡 小技巧：SPOP命令可以实现随机抽奖功能

Hash：对象存储专家

典型特征

• 字段-值对的集合
• 适合存储对象
• 部分字段操作节省网络开销

HSET user:1001 name "张三" age 28 city "北京"
HGET user:1001 name  # 获取单个字段
HGETALL user:1001    # 获取全部字段

实战场景

• 用户画像：存储用户属性
• 商品信息：多维度商品详情
• 配置中心：系统参数管理

🚀 性能提示：HGETALL慎用大数据量，优先使用HMGET获取指定字段

Zset：排行榜背后的英雄

典型特征

• 唯一成员+分数(score)的有序集合
• 自动按分数排序
• 范围查询效率极高

ZADD leaderboard 5000 "player1"  # 添加带分数成员
ZREVRANGE leaderboard 0 2 WITHSCORES  # 获取TOP3
ZRANK leaderboard "player1"  # 获取排名

实战场景

• 实时排行榜：游戏积分榜
• 延迟队列：用时间戳作为score
• 带权重的标签：热搜词统计

🎮 游戏开发必备：每天用ZUNIONSTORE合并多个排行榜

如何选择合适的集合类型？

遇到存储需求时,问自己这几个问题：

1. 需要维护元素顺序吗？→ List/Zset
2. 需要确保元素唯一吗？→ Set/Zset
3. 需要快速判断元素存在吗？→ Set/Zset
4. 需要存储对象属性吗？→ Hash
5. 需要范围查询吗？→ Zset

性能对比速查表

高级技巧锦囊

1. 组合使用：用Zset存储排行榜，用Hash存储详细信息
2. 内存优化：小数据用ziplist编码（在配置中设置）
3. 过期策略：对集合整体设置过期时间，非单个元素
4. 管道操作：批量执行集合命令提升性能

选择比努力更重要

回到开头的电商问题,解决方案其实很清晰：

• 购物车 → Hash（存储商品ID和数量）
• 商品排行榜 → Zset（按销量排序）
• 秒杀库存 → String（原子操作）或Hash（分字段）

没有最好的数据结构,只有最适合的场景，下次设计Redis存储时，不妨先画个思维导图，让每种集合类型都能在它最擅长的位置发光发热🌟