Redis 与 Memcached 的区别：别只问谁更快，要先看缓存要做什么

Redis 和 Memcached 经常被放在一起比较，因为它们都能做缓存，都能把热点数据放到内存里，帮助应用少访问数据库。可如果一上来就问“哪个更快”，很容易把问题带偏。真正应该先问的是：这个缓存只需要简单读写 key-value，还是要承载更多业务动作？数据丢了能不能接受？是否需要持久化、高可用、复杂数据结构？

相关基础内容 对两者的区别说得很集中：Redis 支持更多的数据结构，Memcached 主要关注简单的键值存储；Redis 支持数据持久性，Memcached 重启服务会导致数据丢失；Redis 通常比 Memcached 更快，部分原因是 Redis 采用单线程模型，而 Memcached 使用多线程处理并发请求；总结来看，Redis 适用于需要丰富数据结构和功能、需要持久性支持、对高可用有要求的场景，Memcached 适用于简单键值对缓存。

这几句话足够搭出一套清晰的选型框架。Memcached 的优势在简单，Redis 的优势在能力更完整。简单不是缺点，完整也不等于任何时候都应该上。缓存选型最怕只看工具名，不看业务要缓存的到底是什么。

Memcached 主要是简单 key-value 缓存。应用把一个 key 对应的 value 写进去，下次按 key 取出来。这个模型很直接，适合缓存数据库查询结果、页面片段、配置内容、短期对象序列化结果。业务只关心“有没有这个缓存”“拿出来能不能用”，Memcached 就够用了。

Redis 也能做 key-value，但它没有停在这里。String、Hash、List、Set、Zset 这些结构让缓存层可以直接表达更多动作。计数器可以用 String 的自增命令；对象局部字段可以放在 Hash 里；去重、交集、关注关系可以用 Set；排行榜和按分数排序的列表可以用 Zset。很多时候，Redis 缓存的不只是一段结果，而是一种业务状态。

这就是两者最容易被忽略的差别。Memcached 更像一块很快的临时存储区，应用自己负责解释 value。Redis 更像一组带操作语义的内存数据结构，应用可以把一部分高频动作下沉到 Redis 命令里完成。业务越复杂，这个差别越明显。

文中明确说，Redis 支持数据的持久性，而 Memcached 重启服务会导致数据丢失。这个区别决定了它们对故障的容忍方式不同。Memcached 的思路很纯粹：缓存就是缓存，没了就没了，重新从数据库或后端服务构建。只要回源能力够强，缓存丢失不是灾难。

Redis 则提供 RDB、AOF 等持久化机制，可以把内存中的数据保存到磁盘。重启后，Redis 有机会恢复之前的数据。它仍然常被用作缓存，但持久化让它能承担更多场景，比如会话状态、队列、计数、排行榜、分布式锁辅助信息等。不是所有这些场景都必须持久化，但有这个能力，系统设计空间就更大。

不过要注意，支持持久化不等于 Redis 可以随手替代数据库。持久化有性能成本，也有配置和恢复策略。对纯缓存来说，丢了重建可能比持久化恢复更简单。对无法轻易重建的数据，Redis 即使用了持久化，也要想清楚是否还需要 MySQL、消息队列或日志系统兜底。

已有内容提到 Redis 通常比 Memcached 更快，部分原因是 Redis 采用单线程模型，而 Memcached 使用多线程处理并发请求。这里容易被误读成一句绝对结论：单线程一定比多线程快。实际不是这样。Redis 的单线程核心模型减少了上下文切换和锁竞争，配合内存数据结构和 I/O 多路复用，在很多短命令场景下表现很好。

Memcached 使用多线程处理并发请求，它的设计目标也很清楚：用简单协议和简单数据模型承接大量 key-value 读写。多线程可以利用多核 CPU，但也要处理线程调度和共享资源管理。因为 Memcached 的功能边界窄，线程模型带来的复杂度相对可控。

所以线程模型不是选型时唯一的锤子。Redis 快，是因为它的内存操作、数据结构、事件模型和命令执行方式组合得好；Memcached 直接，是因为它把功能压得很窄。业务如果只是缓存一段字符串或序列化对象，两者都能胜任；业务如果要排行榜、集合计算、原子计数，Redis 的结构能力会省掉很多应用层代码。

简单缓存的特点是 value 可以整体取出、整体替换，不需要在缓存内部做太多操作。比如商品详情页的基础信息、某个接口的聚合结果、后台配置、短时间内不会频繁变化的页面片段。Memcached 很适合这类场景：写进去、设过期、读出来，逻辑短，运维和心智负担也小。

复杂缓存的特点是缓存本身要参与业务动作。比如文章点赞数要原子递增，热门榜单要按分数排序，用户关注关系要做集合判断，消息列表要按顺序推入和弹出。这些场景如果用 Memcached，应用往往要把整个 value 取出来、修改后再写回去，并自己处理并发覆盖问题。Redis 的数据结构和命令更贴近这些需求。

这也是 可以总结 Redis 适合“更丰富数据结构和功能”的原因。Redis 不是因为名气大才常见，而是它在缓存之外还能处理一部分轻量状态。只要这些状态本身适合放在内存里，且有清楚的失效、恢复和一致性策略，Redis 就能帮系统少绕很多路。

已有内容提到 Redis 适合对高可用有要求的场景。这个判断和 Redis 的生态有关。前面几篇已经讲过主从复制、哨兵、集群分片、槽位迁移等内容。Redis 不只是一个单机缓存进程，它有一套围绕复制、故障转移和扩容的机制。

Memcached 也可以做集群化部署，但它更常见的方式是客户端分片，把不同 key 分散到不同节点上。某个节点故障时，对应的一部分缓存失效，应用回源重建。这个模型简单，也符合“缓存丢了没关系”的思路。

所以高可用选型要看数据性质。纯缓存场景下，节点挂了就回源，Memcached 可以很干净。需要更连续的服务能力、希望缓存层支持复制和故障转移，或者缓存中承载了不容易马上重建的状态，Redis 的工具箱会更完整。

Redis 能做的事多，也更容易被用过头。一个常见问题是把大量业务逻辑塞进 Redis：复杂 Lua 脚本、过大的 Hash、难以治理的 key 设计、到处散落的过期策略。刚开始看起来接口快了，后来排查数据不一致、缓存膨胀、慢命令时会很痛苦。

Memcached 的简单反而会逼着系统保持清楚的边界：缓存只缓存结果，事实还在数据库，丢了就回源。这种简单对很多业务是好事。尤其是缓存内容很容易重建，且不需要集合、排序、计数这类操作时，不必为了“以后可能用得上”引入更重的模型。

好的缓存设计不是把工具用满，而是让缓存层刚好承担它该承担的压力。Redis 可以很强，但不应该变成第二个业务数据库；Memcached 很简单，但简单场景里它并不寒酸。

第一，看数据结构。如果只是 key 到 value 的映射，value 整体读写，Memcached 就是合理选择。如果需要 Hash、Set、Zset、List 这类结构，Redis 更自然。不要低估数据结构带来的差别，它会直接影响应用层代码复杂度和并发安全。

第二，看数据是否能丢。缓存重启后全部丢失也能接受，回源就能恢复，那 Memcached 的模型很轻。如果希望重启后能恢复一部分数据，或者缓存层承载了会话、计数、队列这类状态，就要认真考虑 Redis 的持久化和复制能力。

第三，看运维和团队熟悉度。Redis 功能多，配置项和使用禁忌也多；Memcached 简单，问题边界通常更窄。团队如果只是需要纯缓存，简单方案可能更稳。团队如果已经在用 Redis，并且有监控、慢命令治理、内存管理经验，那么继续用 Redis 承接复杂缓存会更顺手。

无论 Redis 还是 Memcached，放在 MySQL 前面时都要记住一个原则：缓存不是最终事实来源。读请求可以先查缓存，命中就返回；未命中再查 MySQL，并把结果写回缓存。写请求一般以 MySQL 为准，再处理缓存失效。

如果是 Memcached，常见做法就是缓存数据库查询结果，设置过期时间，失效后回源。它的职责比较窄，系统一致性逻辑也集中在应用和数据库之间。缓存层大多不保存复杂状态。

如果是 Redis，除了缓存查询结果，还可能缓存计数、集合、排行榜、会话等。这时要额外关注缓存与数据库的同步关系：哪些数据只是加速读取，哪些数据需要异步落库，哪些数据丢失可以重算，哪些必须有补偿。Redis 能做更多事，也意味着边界要写得更清楚。

如果被问 Redis 和 Memcached 的区别，可以先按 相关的四点回答。第一，数据结构不同：Redis 支持 String、Hash、List、Set、Zset 等多种结构，Memcached 主要是简单 key-value。第二，持久化不同：Redis 支持持久化，Memcached 重启后数据会丢失。第三，线程模型不同：Redis 核心处理通常采用单线程模型，Memcached 使用多线程处理并发请求。第四，场景不同：Redis 适合功能更丰富、需要持久化或高可用的场景，Memcached 适合简单键值缓存。

然后补一句选型判断：如果只是把数据库查询结果临时缓存起来，数据丢了可以回源重建，Memcached 很直接；如果缓存层需要计数、排行榜、集合运算、会话状态、持久化或高可用，Redis 更合适。

最后可以强调，不能只用“谁更快”做结论。性能会受数据大小、网络、客户端数量、部署方式、命令复杂度影响。更可靠的回答是先看缓存要做什么，再决定用简单的 Memcached，还是能力更完整的 Redis。