Redis 的应用

写完“Redis 为什么快”，读者最关心的自然是“这玩意儿除了当缓存还能干啥”。很多开发者对 Redis 的印象停留在 GET/SET，但它其实更像是一个分布式系统的“瑞士军刀”。

这篇博客我为你设计了从“经典”到“硬核”的场景演进，保证干货满满。

Redis 除了做缓存，它还能做什么？

在上一篇中我们聊了 Redis 极速的秘密。但如果仅仅把它当成一个“快一点的数据库缓存”，那真是大材小用了。在现代微服务架构中，Redis 几乎无处不在。

今天我们就来盘点一下，Redis 在真实业务场景中的 7 大核心应用。

1. 分布式缓存

这是 Redis 的起家本领。通过将高频访问的热点数据（如用户信息、商品详情）存入内存，可以极大地减轻后端数据库（MySQL）的压力。

• 核心价值：降低响应延迟，保护脆弱的数据库。
• 进阶关注：在写技术博客时，建议提一下缓存雪崩、击穿、穿透这“三座大山”，这是区分新手和老手的关键。

2. 状态管理：分布式 Session 存储

在多台服务器组成的集群中，用户的登录状态（Session）如果只存在本地，会导致“用户换台服务器就得重新登录”的尴尬。

• 解决方案：将 Session 统一存储在 Redis 中。
• 优势：无论负载均衡将请求分发到哪台机器，都能从 Redis 获取到一致的登录状态。

3. 并发利器：分布式锁

在分布式系统中，为了防止多个节点同时操作同一个资源（比如抢购同一件商品），我们需要一把“跨服务器的锁”。

• 实现方式：利用 SETNX (Set if Not Exists) 或者更完善的 Redlock 算法。
• 应用场景：防止超卖、防止重复扣款、定时任务幂等性校验。

4. 排行榜：ZSet 的降维打击

如果你要实现一个“全服战力排行榜”或“实时热搜榜”，用 SQL 的 ORDER BY 可能直接让数据库宕机。

• 秘密武器：ZSet (Sorted Set)。
• 性能：Redis 的 ZSet 内部使用跳表，插入和更新分数值的时间复杂度仅为 。无论是获取前 10 名，还是查询某个用户的精准排名，都是瞬间完成。

5. 流量控制：计数器与限流器

面对突发流量（如 API 被恶意刷票），Redis 是天然的屏障。

• 原子计数：利用 INCR 命令实现秒级计数。
• 限流算法：结合 Redis 的过期时间（TTL），可以轻松实现滑动窗口或令牌桶限流算法，保护下游服务不被冲垮。

6. 消息传递：轻量级消息队列

如果你不需要 RabbitMQ 或 Kafka 那么重的特性，Redis 也可以充当消息中间件。

• List (RPOPLPUSH)：简单的异步任务处理。
• Pub/Sub (发布订阅)：实时的消息推送。
• Stream (5.0+ 新特性)：支持持久化和消费组的消息流，功能已经非常接近专业 MQ。

7. 位图与地理位置

Redis 还有一些让人直呼“卧槽”的高级数据结构：

• Bitmap (位图)：用极小的空间记录状态。比如 “亿级用户签到统计”，每个用户只占 1 个 bit，1 亿用户一天只需要约 12MB 内存。
• GEO：存储地理位置坐标。实现 “附近的人” 或 “外卖骑手距离” 这种功能，Redis 只需要一条命令。

总结：如何选择数据结构？

为了方便大家记忆，我整理了一张“对号入座”表：

业务场景	推荐数据结构	核心命令
简单缓存/分布式锁	String	SET, GET, SETNX
购物车/简单队列	List	LPUSH, RPOP
用户标签/去重统计	Set	SADD, SINTER
对象存储/配置信息	Hash	HSET, HGET
排行榜/权重队列	ZSet	ZADD, ZRANGE
签到/布隆过滤器	Bitmap	SETBIT, GETBIT

写在最后：Redis 虽好，但不要把它当成永久数据库。记住，它首先是一个内存数据库，数据持久化和内存管理永远是你在应用它时需要头疼的下一个问题。