一、核心定位：从诞生之初就不同
-
Memcached 是一个纯内存键值缓存系统 ，设计目标是 "为动态 Web 应用减轻数据库负载"，仅用于缓存热点数据，不支持持久化，重启即清空。它的核心是极致轻量化，只做最简单的键值读写，不引入额外复杂度。
-
Redis 是一个内存型 NoSQL 数据库，不仅能做缓存，还支持持久化、丰富的数据结构和事务能力，可直接作为存储层使用（比如会话存储、消息队列）。它的定位是 "高性能 + 多功能"，兼顾缓存和业务存储场景。
二、技术架构：线程模型决定性能特点
| 特性 | Memcached | Redis |
|---|---|---|
| 线程模型 | 多线程模型（网络 IO 和计算都用多线程），天然利用多核 CPU，适合高并发简单读写。 | 6.0 版本前是单线程计算 + 单线程网络 IO ；6.0 后改为单线程计算 + 多线程网络 IO，计算仍为单线程（避免多线程锁竞争，提升复杂操作效率）。 |
| 网络模型 | 基于 libevent 的事件驱动，支持多路复用。 | 基于自己实现的 ae 事件驱动框架，性能更优。 |
| 内存管理 | 采用 Slab 分配机制，把内存划分为固定大小的块，容易产生内存碎片，但分配速度快。 | 早期用 malloc 动态分配，4.0 后默认用 jemalloc 优化内存碎片，内存利用率更高。 |
三、功能特性：Redis 全面碾压
这是两者最核心的差距：
-
数据结构 Memcached 仅支持 ** 字符串（String）一种结构，所有值都必须序列化为字符串存储。 Redis 支持字符串、哈希（Hash）、列表（List）、集合（Set）、有序集合（ZSet）、位图（Bitmap）、地理空间（Geo）、流（Stream）** 等十几种结构，可直接实现排行榜、计数器、消息队列等复杂业务逻辑。
-
持久化 Memcached 无持久化能力，重启后数据完全丢失。Redis 支持RDB（快照持久化）和AOF（日志持久化），可定期将内存数据落地到磁盘，即使重启也能恢复数据，具备 "存储" 属性。
-
集群与高可用 Memcached 早期依赖客户端实现一致性哈希分片，官方集群方案（Memcached Cluster）生态薄弱，故障转移需依赖第三方工具。Redis 拥有原生 Cluster 模式，支持自动分片、副本同步和故障自动转移，生态成熟，社区工具丰富。
-
附加功能Redis 还支持事务、Lua 脚本、发布订阅、过期策略、内存淘汰机制等，功能远超 Memcached。
四、性能表现：场景决定胜负
-
简单键值读写场景Memcached 多线程模型更占优，理论 QPS 可达 10 万--20 万（理想场景下的 1M QPS 是极端优化后的结果，实际生产中很少达到）。Redis 单线程计算 + 多线程 IO 的模式，简单键值 QPS 约为 10 万--16 万，略低于 Memcached，但差距在 10%--20% 以内，远没有 "高 10 倍" 的夸张。
-
复杂操作场景Redis 单线程模型避免了多线程锁竞争，在处理哈希、集合等复杂数据结构的操作时，性能反而比 Memcached 更稳定、更快。
-
内存效率Redis 对小对象的压缩存储（如 ziplist 编码）比 Memcached 更高效，相同内存下能存储更多数据。
五、适用场景：按需选择
-
优先选 Memcached 的场景
- 仅需简单键值缓存，不需要复杂数据结构；
- 对内存分配效率要求极高（如大量小对象缓存）；
- 已有成熟的客户端分片方案，不需要官方集群支持。
-
优先选 Redis 的场景
- 需要复杂数据结构（如排行榜、秒杀计数器、社交关系链）；
- 需要持久化，避免重启丢失数据；
- 需要集群、高可用和完善的生态工具；
- 除了缓存，还要承担部分业务存储功能（如会话存储、消息队列）。
六、选型结论
目前绝大多数互联网公司的主流选择是 Redis，因为它的功能覆盖了 Memcached 的所有场景，且能支撑更复杂的业务需求。只有在 "极致轻量化 + 纯简单缓存" 的特定场景下，Memcached 才会被保留（比如早期静态页面缓存）。