没并发为什么用 Redis？别只知道说快！¶

面试官突然问了一句：为什么你项目要用 Redis，你们也没什么并发？这个问题千万别上来就说因为 Redis 快，这个回答太浅了。真正的关键是，你要告诉面试官：我们用 Redis 不只是为了扛高并发，而是为了解决系统里的性能、状态、流量和体验问题。

Redis 的五种典型使用场景¶

首先，如果项目真的没什么访问量，Redis 不是必须的，数据库也能跑。但在实际项目里，用不用 Redis 不只看并发高不高，还要看有没有这些场景：

所以 Redis 更像是一个高性能的内存组件，不是只有大厂高并发项目才能用。

像商品详情、首页配置、字典表、用户权限、系统参数，这些数据读多写少。如果每次请求都查数据库，其实很浪费。哪怕并发不高，数据库也不应该承担这种重复查询压力。

我们把这些数据放到 Redis 里，接口响应会更快，数据库压力也更小。这个时候 Redis 的价值不是救命，而是优化系统结构。

比如短信验证码、邮箱验证码、登录 token、图形验证码、临时授权码。这类数据有一个共同特点，就是过一段时间自动失效。

如果放数据库就要设计过期字段，还要定时清理，逻辑会变重。但是 Redis 天然支持过期时间，写进去的时候设置三分钟、五分钟、半小时，到点自动失效，非常适合这种临时状态管理。

单机项目里很多东西可以放本地内存，但项目一旦部署多台机器，本地内存就不可靠了。比如用户登录状态、接口访问次数、幂等 token、重复提交标记，如果只存在某一台服务器里，请求打到另一台机器就读不到。

所以 Redis 可以作为多实例之间共享状态的地方，解决多服务部署下的数据一致访问问题。

就算系统整体并发不高，也可能存在局部风险。比如登录接口被刷、验证码接口被刷、提交订单按钮被疯狂点击，某个用户短时间内重复请求。这个时候我们可以用 Redis 记录用户或者 IP 在一段时间内的访问次数，比如一分钟最多请求十次，超过就拒绝。

这个不是为了追求高并发，而是为了保护接口。

比如用户支付回调、订单状态变更、优惠券领取、库存扣减。这些逻辑不一定每天都有巨大并发，但一旦发生重复提交或者并发竞争，就可能造成脏数据。

Redis 可以用来加一把轻量级的分布式锁，或者存一个请求流水号，保证同一笔业务只处理一次。这里 Redis 解决的是一致性风险，而不只是性能问题。

当然还要补一句：不是所有数据都适合放 Redis。

我们一般只放读多写少、允许短时间不一致，或者天然需要过期的数据。核心交易数据、强一致数据还是要以数据库为准。Redis 只是加速层和状态层，不应该替代数据库。

Redis 不是只有高并发项目才需要。它本质上解决的是四类问题：缓存热点数据管理、临时状态共享、分布式状态保护、关键接口限流。

面试里你只要把这个逻辑讲清楚，面试官就知道你不是为了用技术而用技术，而是真的理解 Redis 在项目里的工程价值。