很多人做产品时一听到性能优化就想到 Redis。好像只要系统慢了加一层 Redis 就能解决问题。但 Redis 不是性能问题的万能药。它很强但也会带来新的复杂度缓存一致性、过期策略、内存成本、故障处理、数据丢失风险、部署维护和调试难度。对独立开发者来说问题不是“Redis 好不好”而是“什么时候值得引入 Redis”。早期产品通常不需要 Redis如果你的产品还没有稳定用户数据库查询也不慢接口响应正常流量很小那么大概率不需要 Redis。早期更重要的是把数据模型、索引、分页、接口结构和核心流程做好。很多性能问题不是因为没有 Redis而是因为查询写得差、索引缺失、一次返回太多数据、重复请求太多。Redis 应该用来解决真实瓶颈而不是用来制造架构安全感。在没有明确问题前引入 Redis只会让系统多一个需要维护的组件。先优化数据库和查询在考虑 Redis 之前先确认数据库本身是否已经做到基本合理。比如是否有合适索引是否做了分页是否避免 N1 查询是否减少不必要字段是否避免在循环中访问数据库是否把慢查询找出来分析。很多早期 SaaS 只要补索引、改查询、减少重复请求就能解决大部分性能问题。如果数据库查询本来就不合理直接加 Redis 只是把问题藏起来。等缓存失效或数据量变大问题还会回来。适合上 Redis 的第一个场景热点缓存Redis 最常见的用途是缓存经常访问但不经常变化的数据。比如首页配置、价格方案、权限配置、公共模板、热门文章、统计结果、用户基础信息、第三方 API 返回结果。这些数据如果每次都查数据库或调用外部服务会浪费资源也会拖慢响应。放进 Redis 后可以显著降低重复查询成本。但缓存一定要设计过期时间和更新策略。否则用户看到旧数据问题会很难排查。第二个场景会话和登录状态如果你的系统需要管理大量短期状态比如登录会话、验证码、一次性 token、临时授权、设备状态Redis 很适合。这些数据通常有明确过期时间不需要永久保存访问频繁读写速度要求高。比如验证码 5 分钟过期临时登录 token 10 分钟过期某个导入任务状态 1 小时后清理。这些场景用 Redis 比放在主数据库里更自然。注意关键业务数据不要只放 Redis。Redis 适合短期状态不适合当唯一事实来源。第三个场景限流和防刷当你的接口开始被频繁请求或者需要防止恶意刷接口、刷登录、刷验证码、刷 AI 调用时Redis 很适合做限流。限流需要快速记录某个用户、IP、设备或 API Key 在一段时间内请求了多少次。Redis 的过期键和计数能力非常适合这类场景。比如每个 IP 每分钟最多请求 60 次每个用户每天最多生成 100 次每个邮箱 10 分钟内最多发送 3 次验证码。这类限制如果只靠数据库会增加写入压力如果没有限制又容易被滥用。第四个场景队列和后台任务很多 SaaS 都会出现不能在用户请求里同步完成的任务。比如发送邮件、生成报表、处理上传文件、调用 AI、同步第三方数据、批量导入、图片处理、通知推送。这些任务如果放在用户请求里执行会让接口等待太久也容易因为超时失败。Redis 可以作为轻量队列的基础配合任务处理器把耗时任务放到后台慢慢执行。用户请求只负责提交任务和返回状态。但如果任务非常关键、量很大、需要复杂重试和审计后面可能需要更专业的队列系统。第五个场景实时状态和排行榜Redis 也适合处理一些变化快、读取频繁、允许短期存储的数据。比如在线用户状态、实时计数、排行榜、房间状态、协作光标、短期活动统计。这些数据如果全部写主数据库会产生大量写入压力但如果只需要短期存在或可重建Redis 会很合适。不过要分清楚哪些数据丢了可以重建哪些数据必须永久保存。不能把重要业务结果只存在 Redis 里。Redis 不应该解决哪些问题Redis 不适合用来掩盖糟糕的数据模型也不适合替代主数据库。如果你的表结构混乱、索引缺失、权限设计错误、接口重复请求太多、前端无限刷新Redis 只能暂时缓解不会根治。Redis 也不适合作为订单、支付、用户资产、关键业务记录的唯一存储。它可以参与流程但最终事实应该落到可靠的持久化数据库里。不要把 Redis 当成“性能胶水”。它是一种工具不是架构补丁。引入 Redis 前要问的几个问题你可以用下面清单判断是否真的需要 Redis是否已经确认真实瓶颈 数据库索引和查询是否已经优化 是否存在高频读取的热点数据 是否存在大量短期状态 是否需要限流或防刷 是否有耗时任务需要后台执行 Redis 数据丢失是否可接受 是否设计了过期和更新策略 是否有人能维护和排查 Redis如果大部分答案都是“不确定”先不要急着上。一个稳妥的引入顺序对独立开发者来说可以按这个顺序引入 Redis第一步先不用 Redis优化数据库、索引和接口 第二步出现热点读取后用 Redis 做缓存 第三步需要验证码、临时 token、限流时用 Redis 做短期状态 第四步出现耗时任务时用 Redis 队列或任务系统 第五步需要实时状态、排行榜、协作状态时再扩展使用这样做的好处是每一步都有明确问题和收益而不是为了架构好看而增加复杂度。写在最后Redis 很有用但不应该太早成为系统标配。早期 SaaS 更应该先把关系型数据库用好把查询写好把索引建好把业务流程跑顺。等出现明确的热点、短期状态、限流、队列或实时需求再引入 Redis。好的技术引入不是“我可能会需要”而是“我现在有一个明确问题它刚好适合解决”。下一篇我们继续聊接口设计第一个接口怎么设计。原文链接Redis 应该什么时候上 | Harries Blog™
