Redis万能指南：每一个应用场景背后，都藏着架构的智慧

那天是个周五的晚上，整个技术群静悄悄。突然，运维小王在群里发了一张监控截图——数据库QPS暴涨到平时的十倍，MySQL的CPU直接飙到95%，整个系统卡得像蜗牛。

我当时一看，心里“咯噔”一下。因为这套系统，是我三个月前刚上线的电商项目。要是挂了，我得先挨老板一通“灵魂拷问”。

Redis救场的那一夜

赶紧登录服务器一看，主要的瓶颈在商品详情页。每次用户点击商品时，系统都从MySQL拉一大坨数据：基本信息、库存、优惠价、评论数……再拼装返回。

平时没问题，但那天平台搞活动，流量直接翻了好几倍。数据库自然顶不住。

怎么办？那一刻，我想起Redis。于是我在商品详情接口加了一级缓存：

当用户请求商品时，先查Redis，没有就查数据库，然后再写回Redis。5分钟TTL，让数据有点“呼吸感”，既不太旧，也不太频繁。

改完部署后，MySQL的压力瞬间降了一大半。那一刻，我对Redis的好感度直接+100。

后来我总结这次事故，给组里写了份文档，标题叫：

“Redis：不只是缓存，而是性能的守护神”。

Redis到底是干嘛的？

面试时，当面试官问你“Redis的应用场景”，其实他不只是想听你说“缓存”。

他想听你能不能结合业务场景，讲出为什么这么用、怎么设计、怎么避免坑。

Redis，本质上是一个基于内存的高性能key-value数据库。

快，是它的核心竞争力。它不像MySQL那样每次都得落盘查询磁盘，而是把数据放在内存中，毫秒级响应。

所以，它能做的事，远比“缓存”多得多。

接下来，我给你讲讲Redis的六大经典应用场景。每一个，我都遇到过“血的教训”或“惊喜瞬间”。

场景一：缓存（Cache）

Redis最常见的用途，当然是做缓存。

比如用户信息、商品详情、热榜数据、配置项这些读多写少的数据，就特别适合放在Redis中。

但，别以为缓存只是“查不到再查数据库”这么简单。

缓存的设计里有三大灵魂问题：

我记得我第一次线上遇到缓存击穿，系统直接挂了半小时，从那以后，TTL我都加上随机抖动，再也不敢偷懒。

场景二：分布式锁（Distributed Lock）

后来我们系统做促销活动，大家疯狂抢券。结果，一个用户短时间内多次点击领取，居然拿到了好几张优惠券。

根本原因：并发下操作没加锁。

在分布式环境中，你不能用Java的synchronized，因为那只是单JVM内有效。这时候Redis的分布式锁就派上用场了。

用法其实很优雅：

SET lock_key value NX EX 5

释放锁时，只能删除自己加的那把，防止误删别人的锁。不过，这里要注意一个坑：

Redis的分布式锁不是强一致的锁，如果你追求更高的可靠性，可以用Redisson，它基于Lua脚本和Watchdog自动续期机制，更稳。

场景三：计数器（Counter）

我第一次在项目里用Redis计数，是为了做接口限流。比如一个用户1分钟只能访问接口10次。

实现方式超简单：

Redis天然支持高并发计数，而且原子性操作，让限流逻辑优雅又高效。

除了限流，Redis计数还常用在：

有一次老板说：“为什么我们后台数据和前端PV不对？”

结果我一查，发现前端PV是直接统计Redis计数器，后台是隔夜同步的MySQL表……于是，我又写了个脚本，每天0点把Redis的计数同步落库，从此一致性不再打架。

场景四：排行榜（Sorted Set）

我们做内容推荐系统时，常需要展示热度排行榜。

Redis的Sorted Set完美适配这种需求。每个内容有个score，可能是点赞数、评论数、点击量的加权。用ZADD命令写入，ZREVRANGE就能快速取出前N名。

甚至还能实现“实时榜单”：

我记得那次我们做“每日热帖榜”，MySQL版本的SQL跑了3秒，而Redis版本不到0.01秒。老板看了监控，愣是夸了我整整三分钟，说：“这小子，干得漂亮！”

场景五：消息队列（List / Stream）

别忘了，Redis也能做消息队列！

很多人用List结构实现简单的任务队列，用LPUSH + BRPOP就能搞定。生产者放消息，消费者阻塞取消息。

后来Redis推出了Stream结构，功能更强大：

我们当时做异步任务处理，用Redis Stream代替了RabbitMQ的小部分功能。部署简单、延迟低，适合中小项目快速落地。

场景六：会话与Token存储（Session / Token）

做微服务登录认证时，Redis也常被用作Session存储。

尤其在集群环境中，Tomcat自带的Session就不太行了。把Session放Redis中，不管你请求哪个节点，都能共享登录状态。

同时Redis还能轻松实现：

我记得有次我们App上线新版本，用户反馈“登录后几分钟自动掉线”。查了半天才发现，我们Session TTL只设了10分钟，后来改成Redis持久化存储+滑动过期，问题一举解决。

Redis的更多妙用

除了上面这些经典用法，Redis还能干很多有趣的事情：

这些功能组合起来，简直像积木一样能搭出各种“黑科技”。

面试官真正想听的是什么？

当面试官问你：“Redis有哪些应用场景？”他其实不想听你背书。他想听到这样的回答：

“比如我们系统中用Redis做商品缓存，解决了高并发场景下数据库压力的问题；用分布式锁防止库存超卖；用ZSet做热度榜单；用Stream处理异步消息；用INCR做接口限流。同时，我们还防止了缓存穿透、击穿、雪崩等问题。”

这样的回答，面试官一定会点头。因为你不是在背知识点，而是在讲“真实战斗经验”。

写在最后：Redis不是银弹，但很香

我始终记得那句老话：“没有Redis，很多系统不是慢死，就是宕死。”

Redis的魅力在于，它让复杂的问题变得简单、优雅、高效。但用得不好，也可能带来一致性问题、缓存失效风暴、锁死进程。

所以，Redis不是银弹，但它让系统更有呼吸感。

就像那天晚上，当我用Redis挡住流量洪峰的那一刻，我突然明白：

架构，不只是技术的堆叠，更是对系统生命力的呵护。

END

我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！