为什么使用 Redis，而不是直接使用 MySQL？

核心回答

使用 Redis，通常是为了让合适的高频访问复用已算好的结果、减轻数据库压力，或高效维护短期共享状态，不是因为 MySQL 不能处理这些数据。

如果讨论的是“Redis 缓存加 MySQL”，常见分工是：MySQL 保存业务权威数据，Redis 保存可重建的热点结果。这样有三个主要收益：

• 减少重复查询和计算：缓存命中时，可以跳过关联查询、聚合或对象组装，而不只是少读一次磁盘。
• 降低热点流量对数据库的压力：大量请求读取同一结果时，用较简单的键值访问承接这部分流量，让数据库资源留给写事务和未命中的查询。
• 方便维护共享状态：Redis 提供过期、计数、集合等能力，多个应用实例可以共同访问；限流窗口计数、短期状态等场景，往往比持续写关系表更直接。

代价是增加内存、网络和运维成本，还要处理数据一致性、过期重建与故障回源。因此，要根据访问模式和新鲜度要求选，不能仅凭“Redis 在内存、MySQL 在磁盘”就决定加缓存。

进一步解释

MySQL 也有内存缓存，Redis 为什么还有价值？

以 MySQL 8.4 的 InnoDB 为例，Buffer Pool 会把表和索引页保留在内存中，热数据查询不一定每次访问磁盘。

Redis 作为结果缓存，价值在于进一步绕过重复的 SQL 执行、扫描、关联、计算和组装过程。比如一个商品摘要由多张表组合而成，多次请求可以复用同一份序列化结果。比较时应看两条实际请求路径，而不是只比较内存和磁盘的硬件速度。

Redis 本身也有网络往返、序列化、内存分配等成本。如果原查询已通过索引快速完成、负载很低，缓存收益可能不足以覆盖复杂度。

一个商品摘要缓存怎样工作？

下面是参考设计：商品数据仍保存在 MySQL，以 product:123:summary 为缓存键，值为允许短时间陈旧的摘要，并按业务新鲜度设置 TTL。

读取时先查 Redis，命中就返回；未命中再读 MySQL、组装摘要并回填。写入时先完成 MySQL 事务，提交后删除相关缓存，让后续读取重建。

这是常见的最终一致策略。删除失败、并发旧值回填、数据库副本延迟仍可能导致陈旧值，需要相应重试、失效事件或版本约束；TTL 只是兜底。对结算价格、余额等敏感决策，应明确权威校验路径，不能只凭可能陈旧的展示缓存作决定。

缓存过期或服务不可用时，还要控制回源并发，避免所有请求同时压向数据库。缓存命中率高并不意味着数据库可以按平时很低的回源量配置，而完全忽略失效时的负载。

为什么限流计数不一定要直接写 MySQL？

限流状态通常按用户或接口高频更新，只需要保留一个时间窗口。Redis 的计数、过期和原子执行能力很适合表达这类共享状态。

用 MySQL 也能实现，但需要设计窗口记录、并发更新和清理，热点行还可能产生竞争。选择 Redis 的理由是这类操作与数据结构、生命周期更匹配，而不是“MySQL 一定做不到”。涉及多个 Redis 操作的判断与更新，也要保证组合操作的原子性。

如果状态丢失会造成不可接受的业务后果，就要进一步评估持久化、故障切换和降级策略。缓存、限流状态与业务账本的恢复要求不同，不能混用同一种丢失假设。

常见追问

什么时候可以直接用 MySQL？

数据访问量和查询成本可控、写多读少、结果复用率低，或者每次读取都要求满足明确的事务一致性时，直接用数据库通常更简单。先处理索引、SQL、连接池等已知瓶颈，再判断是否需要结果缓存。

Redis 能不能直接作为主要存储？

可以承担适合其模型的存储职责，但要单独确认数据结构、容量、持久化、备份恢复及故障条件。Redis 有持久化能力，不等于它与 MySQL 的关系模型、约束和事务语义可以直接互换；同样也不能把 Redis 一概说成“只能当缓存”。

怎样验证引入 Redis 有收益？

比较相同请求和负载下的延迟分布、数据库查询量与资源占用，同时看命中率、回源量、Redis 内存和淘汰情况。还应检查写后新鲜度、热点失效和缓存不可用时的服务表现，不能直接套用固定 QPS 或性能倍数。

对应教程

参考资料