1. Redis核心数据结构与实战指南

作为一名长期使用Redis的后端开发者，我见证了Redis从简单的缓存工具成长为功能丰富的内存数据库的完整历程。今天我想系统梳理Redis的五种核心数据结构（String、Hash、List、Set、Zset）以及它们的实际应用场景，这些知识都是我在电商和社交类项目中反复验证过的实战经验。

Redis之所以能在高并发场景下大放异彩，关键在于其精妙的数据结构设计。与传统关系型数据库不同，Redis将所有数据存储在内存中，通过高效的数据结构实现微秒级的读写速度。在日均PV过亿的系统中，合理使用Redis数据结构可以使QPS轻松突破10万大关。

1.1 String类型深度解析

String是Redis最基础的数据类型，但它的功能远不止存储字符串那么简单。在实际项目中，我主要用String实现以下场景：

• 缓存热点数据（用户信息、商品详情）
• 计数器（阅读量、点赞数）
• 分布式锁（配合SETNX命令）
• 临时验证码存储

原子性操作是String的最大亮点。比如商品库存扣减场景：

> SET item:1001_stock 100 > DECR item:1001_stock (integer) 99

这个DECR操作是原子性的，完全不用担心并发问题。我在618大促时就用这个方案扛住了每秒3万次的库存查询请求。

批量操作能显著提升性能。对比以下两种方式：

# 低效写法（网络开销大） SET user:1001:name "张三" SET user:1001:age 30 SET user:1001:gender "男" # 高效写法（一次网络IO） MSET user:1001:name "张三" user:1001:age 30 user:1001:gender "男"

重要提示：String的value最大能存512MB，但实际使用时建议控制在10KB以内。过大的value会导致网络传输和内存分配耗时增加，严重时可能阻塞Redis主线程。

1.2 Hash类型应用实践

Hash特别适合存储对象类型的数据。在我们的用户系统中，每个用户信息是这样存储的：

HSET user:1001 name "张三" age 30 gender "男" vip_level 5

与String相比，Hash有两个显著优势：

1. 字段级操作：可以单独更新某个字段，不用读取整个对象
2. 内存更节省：Redis会使用ziplist压缩存储小Hash

但要注意两个坑：

1. 不要滥用HGETALL，当字段很多时会导致网络阻塞，应该用HMGET按需获取
2. HSET的字段数不要超过5000，否则会从ziplist转为hashtable，内存占用激增

实战案例：电商购物车实现

# 添加商品 HSET cart:1001 item:5001 2 # 用户1001的商品5001数量为2 # 修改数量 HINCRBY cart:1001 item:5001 1 # 获取总价（需要配合商品服务计算） HGETALL cart:1001

1.3 List实现消息队列

List的LPUSH+BRPOP组合是轻量级消息队列的经典实现。我们在订单系统中用它来处理支付成功通知：

生产者：

LPUSH order:notify "{'order_id':10086,'status':'paid'}"

消费者：

BRPOP order:notify 30 # 阻塞30秒等待消息

实际踩过的坑：

1. 消息堆积时List会占用大量内存，要及时监控LLEN
2. 没有ACK机制，消息弹出后如果处理失败会丢失
3. 多个消费者时无法实现负载均衡

对于要求更高的场景，建议改用Redis Streams（Redis 5.0+特性）。

1.4 Set实现社交关系

Set最强大的能力是集合运算。在社交APP中，我们用Set实现了以下功能：

共同好友计算：

SINTER user:1001:friends user:1002:friends

可能认识的人推荐：

# 计算差集并排除已存在关系 SDIFF user:1002:friends user:1001:friends SREM @result user:1001:blocked # 排除黑名单

UV统计优化方案：

# 传统方案（内存占用高） SADD uv:20240501 1001 1002 1003... # 优化方案（HyperLogLog） PFADD uv:20240501 1001 1002 1003...

1.5 Zset实现排行榜

Zset是我们游戏排行榜系统的核心。以王者荣耀赛季榜为例：

实时更新分数：

ZADD season:2024s2 1850 player:9527 ZINCRBY season:2024s2 20 player:9527 # 胜利加分

榜单查询优化：

# 前100名（带分数） ZREVRANGE season:2024s2 0 99 WITHSCORES # 查询个人排名 ZREVRANK season:2024s2 player:9527 ZSCORE season:2024s2 player:9527

冷数据处理技巧：

# 赛季结束时归档历史数据 ZUNIONSTORE archive:2024s2 1 season:2024s2 EXPIRE season:2024s2 86400 # 保留1天供核对

2. 高级特性应用指南

2.1 地理空间索引实战

Redis的GEO功能在LBS服务中非常实用。以下是外卖APP的实现示例：

存储商家位置：

GEOADD restaurants 116.404269 39.91582 "全聚德" 116.408187 39.904816 "海底捞"

3公里内商家搜索：

GEOSEARCH restaurants FROMLONLAT 116.402 39.91 BYRADIUS 3 km ASC

性能提示：GEO底层使用Zset存储，查询复杂度O(logN)。建议对大城市数据按区域拆分，如geo:bj:chaoyang、geo:bj:haidian

2.2 位图实现用户签到

Bitmaps是节省空间的利器。每日签到功能可以这样实现：

# 用户1001在2024年5月签到记录 SETBIT sign:1001:202405 1 1 # 第2天签到（偏移量从0开始） SETBIT sign:1001:202405 7 1 # 第8天签到 # 统计当月签到天数 BITCOUNT sign:1001:202405 # 判断某天是否签到 GETBIT sign:1001:202405 7

3. 生产环境注意事项

3.1 内存优化策略

1. 控制key长度：user:1001:profile比u:1001:p多占7字节，在千万级数据下就是70MB差距
2. 合理设置过期时间：EXPIRE要分散过期，避免大量key同时过期导致卡顿
3. 监控大key：redis-cli --bigkeys定期扫描

3.2 集群使用规范

1. 避免跨slot操作：MSET等批量命令要确保所有key在同一个slot
2. 事务限制：集群模式下事务中的key必须位于同一节点
3. Lua脚本注意：所有操作的key必须属于同一个slot

4. 性能对比测试数据

在我的压力测试中（Redis 6.2，8核16G环境），不同数据结构的QPS表现：

这些数据可以帮助你在设计时做出合理选择。记住：没有最好的数据结构，只有最适合场景的设计。