# Redis 数据结构的艺术：从工具到思维的跃迁

# 前言：从会用到用好

刚开始接触 Redis 的时候，我和很多人一样，觉得它就是个缓存工具。SET 一下，GET 一下，完事了。但随着在项目中踩的坑越来越多，我慢慢意识到 Redis 远不止于此。

今天想聊聊 Redis 数据结构背后的一些思考，不是简单的命令罗列，而是我在实际项目中的一些感悟和经验总结。

# String：最简单的却最容易被误用

String 是 Redis 最基础的数据结构，但也是最容易被滥用的。我见过很多项目把复杂的 JSON 对象直接序列化成 String 存储，结果就是每次修改都要整个读出来、改完再写回去。

# 不推荐的做法
SET user:1 '{"name":"张三","age":25,"city":"北京"}'
# 想修改年龄，必须：
GET user:1
# 解析JSON，修改age，再序列化
SET user:1 '{"name":"张三","age":26,"city":"北京"}'

更好的做法是使用 Hash，这个后面再说。但 String 也有它的优势场景，比如计数器：

# 文章浏览量计数
INCR article:1001:views
# 用户积分
INCRBY user:1001:score 10

我在一个电商项目中，用 String 做商品库存管理，配合原子操作解决了超卖问题：

1
2
3

# 下单时检查并扣减库存
DECR goods:1001:stock
# 返回值如果是负数说明库存不足

# Hash：对象的正确打开方式

Hash 是我个人最喜欢的 Redis 数据结构，因为它完美契合了面向对象的思维。

# 用户信息存储
HSET user:1001 name "张三" age 25 city "北京"
HGET user:1001 name
HINCRBY user:1001 age 1

在社交项目中，我用 Hash 存储用户的基本信息，用 String 存储用户的动态数据。这样设计的好处是：

修改单个字段不需要读写整个对象
内存使用更高效（Redis 会优化小 Hash 的存储）
天然支持部分字段更新

但 Hash 也有坑，我记得在一个项目中，因为 Hash 的 field 太多（几千个），导致性能下降。后来才知道 Redis 的 Hash 在 field 数量很多时，会退化成普通字典结构。

# List：消息队列的轻量级选择

List 在 Redis 中是个双向链表，这个特性让它很适合做消息队列。

# 生产者
LPUSH task:queue "task1"
LPUSH task:queue "task2"

# 消费者
BRPOP task:queue 30

我在一个异步任务系统中用过 List，但后来遇到了重复消费的问题。原因是消费者处理完任务后没有确认机制。如果对可靠性要求高，还是建议用专业的消息队列。

List 还有个有趣的用法是做时间线：

# 用户动态时间线
LPUSH timeline:user:1001 "发布了新文章"
LPUSH timeline:user:1001 "点赞了视频"
LRANGE timeline:user:1001 0 9

# Set：去重和交集的神器

Set 是我觉得最神奇的数据结构，因为它能轻松实现一些复杂的业务逻辑。

# 用户标签
SADD user:1001:tags "技术" "阅读" "运动"
SADD user:1002:tags "技术" "音乐"

# 找共同好友
SINTER user:1001:friends user:1002:friends

# 推荐系统：找相似用户
SDIFF user:1001:tags user:1002:tags

在一个内容推荐项目中，我用 Set 实现了一个简单的协同过滤算法：

# 用户看过的文章
SADD user:1001:readed "article:1" "article:3" "article:5"
SADD user:1002:readed "article:1" "article:2" "article:3"

# 找相似用户（看过相同文章多）
SINTER user:1001:readed user:1002:readed
# 结果：article:1, article:3

# Sorted Set：排行榜的最佳选择

如果说 Set 是去重神器，那 Sorted Set 就是排行榜神器了。

# 游戏积分排行
ZADD game:score 1000 "player1" 1500 "player2" 800 "player3"
ZREVRANGE game:score 0 9 WITHSCORES

# 获取某个玩家的排名
ZRANK game:score "player2"

比如在直播项目中用 Sorted Set 做礼物排行榜，但遇到了一个内存问题：主播太多，每个主播都维护一个排行榜，内存占用太大。后来优化成只保留前 100 名：

1 2	# 只保留前100名 ZREMRANGEBY rank:room:1001 0 -101

# 数据结构选择的思考框架

经过这么多项目，我总结了一个选择数据结构的思考框架：

# 1. 数据特征分析

是否需要去重？→ Set
是否需要排序？→ Sorted Set
是否需要部分更新？→ Hash
是否需要队列特性？→ List
简单键值对？→ String

# 2. 操作模式分析

读写比例：读多用 Hash，写多考虑 List
数据大小：小对象用 Hash，大对象考虑分片
并发程度：高并发注意原子操作

# 3. 业务场景分析

缓存场景：String 或 Hash
计数场景：String 的 INCR 系列
排行榜：Sorted Set
消息队列：List（简单场景）或专业 MQ
社交关系：Set

# 实际项目中的一些踩坑经验

# 内存优化坑

曾经有个项目，用 Hash 存储用户信息，每个 Hash 有几十个 field。后来用户量上来后，内存占用爆炸。解决方案是：

冷热分离：经常访问的用 Hash，不常用的用 String
数据压缩：大字段考虑压缩存储
过期策略：设置合理的 TTL

# 性能优化坑

在一个高并发场景中，我用了大量的 KEYS 命令（生产环境千万别用），导致 Redis 阻塞。后来改成 SCAN：

# 危险的做法
KEYS user:*

# 安全的做法
SCAN 0 MATCH user:* COUNT 100

# 一致性坑

分布式环境下，Redis 的数据一致性是个大问题。我的经验是：

重要数据不要只依赖 Redis
使用合适的更新策略（Cache Aside、Write Through 等）
考虑使用 Redis 的事务或 Lua 脚本

# 总结：从技术到思维

学习 Redis 数据结构，我觉得有三个层次：

第一层次：会使用基本命令
第二层次：理解各种数据结构的适用场景
第三层次：能够根据业务特点选择合适的数据结构组合

我现在觉得，Redis 不仅仅是一个缓存工具，更是一个思维工具。它教会我们从数据特征出发思考问题，从操作模式优化设计。

希望这些思考对你有帮助。记住，技术是工具，思维才是核心。

Redis 数据结构架构思考