Redis 与 MySQL、MongoDB、Memcached 有什么区别？如何选择？
Redis、MySQL、MongoDB、Memcached 是后端开发中最常用的四种数据存储方案，面试中经常被放在一起考察。它们的设计目标完全不同，理解本质差异才能做出正确的技术选型。
核心区别：一张表看懂
| 维度 | Redis | MySQL | MongoDB | Memcached |
|---|---|---|---|---|
| 存储介质 | 内存为主，可持久化 | 磁盘为主 | 磁盘（内存映射） | 纯内存 |
| 数据模型 | Key-Value + 多种数据结构 | 关系型表 | 文档型（BSON） | Key-Value（仅String） |
| 事务支持 | 有限事务（MULTI/EXEC） | 完整ACID | 4.0起支持多文档事务 | 无 |
| 持久化 | RDB + AOF | 天然持久化 | 天然持久化 | 无，宕机即丢 |
| 查询能力 | 按Key操作，有限范围查询 | SQL，复杂关联聚合 | MQL，支持索引和聚合 | 仅GET/SET |
| 单机QPS | 10万+ | 数千~数万 | 数万 | 10万+ |
| 一致性模型 | 最终一致性 | 强一致性 | 可配置（最终/强） | 无一致性保证 |
| 水平扩展 | Cluster分片 | 分库分表（复杂） | 原生分片 | 客户端一致性Hash |
Redis vs MySQL：缓存与持久化的抉择
本质区别在于存储介质和一致性模型。
Redis 数据驻留内存，读写延迟在亚毫秒级，但默认不保证数据持久化——即使开启 AOF，也存在最多 1 秒的数据丢失窗口。MySQL 数据落盘，通过 redo log 和 doublewrite 机制保证数据安全，但读写延迟在毫秒到十毫秒级。
面试中常问的一个问题：Redis 能否替代 MySQL？
答案是不能。两者的定位完全不同：
- Redis 适合做缓存层和实时数据层，数据可以丢失或从源头重建
- MySQL 适合做持久化存储层，数据不能丢失且需要事务保证
生产中的经典架构是 Redis + MySQL 组合：读请求先查 Redis，命中则直接返回；未命中则查 MySQL，结果回写 Redis。但这里有几个关键问题需要注意：
- 双写一致性：先更新 MySQL 再删缓存，存在短暂不一致窗口。对一致性要求高的场景，可用 Canal 监听 binlog 同步更新 Redis
- 缓存穿透：查询不存在的数据，绕过缓存直击数据库。用布隆过滤器或缓存空值解决
- 缓存击穿：热点 Key 过期瞬间大量请求涌入数据库。用互斥锁或永不过期+异步刷新
- 缓存雪崩：大批 Key 同时过期。用随机过期时间打散
Redis vs MongoDB：两种 NoSQL 的不同思路
Redis 和 MongoDB 虽然都属于 NoSQL，但设计哲学完全不同。
Redis 追求极致性能，数据全在内存中，数据结构精心设计，每种操作的时间复杂度都有明确保证。它更像一个高性能的数据结构服务器。
MongoDB 追求灵活性，文档模型允许 schema 自由变化，嵌套文档减少了关联查询的需要。它更像一个增强版的 MySQL。
关键区别：
- 数据量：Redis 受内存限制，通常存热点数据；MongoDB 可存储 TB 级数据
- 查询复杂度：Redis 只支持基于 Key 的操作；MongoDB 支持条件查询、聚合管道
- 适用场景：Redis 做缓存/计数器/排行榜/分布式锁；MongoDB 做内容管理/日志/IoT 数据/用户画像
Redis vs Memcached：缓存之争的终局
这组对比面试频率极高。核心结论：新项目直接选 Redis，没有理由选 Memcached。
Memcached 的仅存优势：
- 多线程架构，在 value 超过 100KB 时吞吐量更高
- 更简单的部署，适合纯缓存场景
Redis 全面碾压的点：
- 支持丰富数据结构（Memcached 只有 String）
- 支持持久化（Memcached 宕机数据全丢）
- 支持主从复制和集群（Memcached 靠客户端分片）
- 支持发布订阅、Lua 脚本、Stream（Memcached 无）
- 单线程模型反而简化了并发控制，小数据性能更优
Memcached 在 2015 年之前还有市场份额，现在基本已被 Redis 完全取代。面试中回答"选 Redis"即可，但要说清楚为什么。
技术选型：根据场景做决策
选型不是二选一，而是根据业务特征匹配最合适的工具。
选 Redis 的场景：需要亚毫秒级响应、数据可以容忍短暂丢失、操作模式简单（按 Key 读写）。典型用例：缓存、Session、排行榜、计数器、分布式锁、限流器。
选 MySQL 的场景：数据必须持久化且保证一致性、需要复杂关联查询和事务、业务模型稳定。典型用例：用户系统、订单系统、支付系统。
选 MongoDB 的场景：数据结构频繁变化、单文档较大且需要灵活查询、需要水平扩展。典型用例：CMS、日志分析、IoT、用户画像。
选 Memcached 的场景：基本没有了。除非维护旧系统，否则没有理由新项目选 Memcached。
生产架构中的组合模式
实际项目中几乎不会只用一种存储，常见的组合方案：
Redis + MySQL（最经典）：Redis 缓存热点数据，MySQL 持久化存储。注意做好双写一致性、缓存穿透/击穿/雪崩的防护。
Redis + MySQL + MongoDB：Redis 做缓存，MySQL 存核心业务数据，MongoDB 存非结构化数据（日志、配置、内容）。
Redis + MySQL + Elasticsearch：Redis 缓存，MySQL 存储，ES 负责全文检索和复杂搜索。
无论哪种组合，核心原则是：每种存储只做它最擅长的事，不要让 MySQL 做缓存，也不要让 Redis 做持久化。
追问：缓存与数据库的一致性如何保证？
这是上述选型之后必然的追问，也是面试高频考点。
先更新数据库，再删缓存 是最常用的策略。为什么是删缓存而不是更新缓存？因为更新可能涉及复杂计算，且并发场景下容易产生脏数据。
一致性保证的三个层级：
- 弱一致性：先更新DB再删缓存，容忍短暂不一致，适合大多数业务
- 最终一致性：通过消息队列或 Canal 监听 binlog 异步更新缓存，保证最终一致
- 强一致性：读写都走数据库，或使用分布式锁，牺牲性能换一致性，仅金融等场景使用
面试时回答到第二层即可，重点是说清楚各方案的 trade-off。