为什么我的项目里不用 Redis

先说结论

我现在的项目里，缓存直接用数据库的查询缓存，会话存在数据库里，限流用 Nginx，消息队列用数据库表模拟。没有 Redis，系统跑得好好的。

我知道这话说出来肯定有人要喷。但你先别急，听我说完。

那些「必须用 Redis」的场景，其实都不必须

1. 缓存

最常见的理由：需要缓存，所以要用 Redis。

但问题是，你的数据库本身就有缓存。MySQL 的 Query Cache（虽然 8.0 移除了，但 InnoDB Buffer Pool 还在），PostgreSQL 的 Shared Buffers，都能做缓存。而且这些缓存是自动的，不需要你写代码。

我现在的做法是：热点数据用数据库的缓存，配合合理的索引。如果发现某个查询真的慢，再考虑加一层应用层缓存。但大多数情况下，数据库缓存就够了。

2. Session 存储

很多人说 Session 存在 Redis 里，性能好。但问题是，你的 Session 数据有多少？一个用户 Session 也就几 KB，存数据库里完全没问题。

我现在的做法是：Session 存数据库，定期清理过期数据。如果用户量真的很大，再考虑迁移到 Redis。但说实话，我还没遇到过这种情况。

3. 限流

限流确实可以用 Redis 的计数器。但 Nginx 的 limit_req 模块也能做限流，而且更简单，不需要写代码。

我现在的做法是：在 Nginx 层面做限流，应用层再做一层业务限流。两层限流，基本够用了。

4. 消息队列

这个可能是最「必须」的场景了。但如果你只是简单的异步任务，用数据库表也能做。

我现在的做法是：创建一个 jobs 表，用数据库事务保证原子性，用定时任务轮询处理。虽然性能不如真正的消息队列，但对于大多数场景来说，够用了。

Redis 的问题

1. 增加系统复杂度

每多一个组件，系统就复杂一分。Redis 需要部署、监控、备份、故障恢复。这些都是成本。

而且，Redis 和数据库之间的一致性也是个问题。缓存失效、数据同步，都需要考虑。

2. 内存成本

Redis 是内存数据库，内存比磁盘贵。如果你的数据量不大，用数据库就够了。如果数据量很大，那确实需要考虑 Redis，但大多数项目的数据量都不大。

3. 运维成本

Redis 需要运维。虽然 Redis 很稳定，但总会有问题。内存满了、连接数满了、持久化失败，都需要处理。

而且，Redis 的集群、主从复制、哨兵模式，都是需要学习和维护的。

什么时候才真的需要 Redis

说了这么多，那什么时候才真的需要 Redis？我觉得是这几个场景：

• 高并发场景：QPS 真的很高，数据库扛不住，需要 Redis 做缓存
• 实时性要求高：比如实时排行榜、实时计数，需要 Redis 的原子操作
• 复杂数据结构：需要用到 Redis 的 Set、Sorted Set、Hash 等数据结构
• 分布式锁：需要跨进程的分布式锁，Redis 是个不错的选择

但说实话，大多数项目都不需要这些。你的项目 QPS 可能就几百，数据库完全扛得住。你的业务逻辑可能很简单，用不到复杂的数据结构。

我的建议

如果你在考虑要不要用 Redis，我的建议是：

1. 先不用：先用数据库和 Nginx，看看能不能满足需求
2. 遇到瓶颈再考虑：如果真的遇到性能瓶颈，再考虑引入 Redis
3. 评估成本：引入 Redis 的成本（开发、运维、内存）是否值得
4. 渐进式引入：如果真的需要，先从简单的场景开始，比如缓存，再逐步扩展

不要为了用 Redis 而用 Redis。技术选型应该基于实际需求，而不是「别人都在用」。

最后

我知道这篇文章可能会引起争议。但我想说的是，技术选型没有标准答案，只有适合不适合。

如果你的项目真的需要 Redis，那就用。但如果你的项目不需要，那就别用。不要被「最佳实践」绑架，也不要被「技术栈」绑架。

简单、够用，就是最好的。