Redis 和 Memcached 有什么区别该选哪个

**选 Redis 还是 Memcached，只看一件事：你要的是"缓存"还是"带数据结构的内存数据库"。纯 KV 缓存、value 小于 1MB、不需要持久化和高可用、想榨干多核 CPU，选 Memcached；其余绝大多数场景，选 Redis。** 2024 年新项目里，除非你已经有一套 Memcached 集群要维护，否则默认选 Redis 几乎不会错。

Redis 和 Memcached 最核心的区别是什么？

结论：Memcached 是一个纯粹的内存 KV 缓存，Redis 是一个支持多种数据结构、可持久化、可分布式部署的内存数据库。

具体差异可以用几个硬指标说清：

• 数据结构：Memcached 只有 String 一种类型，value 是二进制块，服务端不理解内容；Redis 支持 String、Hash、List、Set、ZSet（有序集合）、Bitmap、HyperLogLog、GEO、Stream 九种结构，服务端能直接对结构做运算。
• 键值大小：Memcached 的 key 上限 250 字节，value 默认上限 1MB（可用 -I 调大，最大到 128MB）；Redis 的 key 和 value 上限都是 512MB。
• 持久化：Memcached 没有任何持久化，进程重启数据全丢；Redis 支持 RDB（快照）和 AOF（追加日志），Redis 7.0 之后是 multi-part AOF。
• 集群能力：Memcached 服务端不做集群，分片靠客户端一致性哈希；Redis 自带主从复制、Sentinel 哨兵和 Cluster（16384 个哈希槽，最少 3 主 3 从）。
• 过期时间：Memcached 的 TTL 上限是 30 天（2592000 秒），超过这个值会被当成绝对 Unix 时间戳解释；Redis 的 EXPIRE 没有这个坑。
• 额外能力：Redis 有 MULTI/EXEC 事务、Lua 脚本、发布订阅、Stream 消息队列、键空间通知；Memcached 只有 gets/cas 提供的单 key 乐观锁。

性能上 Memcached 真的比 Redis 快吗？

结论：在高并发、小 value、多核机器上，Memcached 的吞吐通常更高；在单核或大 value 场景，Redis 反而更稳。

原因在线程模型：

• Memcached 是多线程的，多个 worker 线程共享监听端口，能随 CPU 核数扩展，16 核机器就能吃满 16 核。
• Redis 6.0 之前命令执行完全单线程；6.0 引入 io-threads（最多可配 128）只是把网络读写和协议解析并行化，命令执行仍然是单线程，所以单实例的写吞吐上限基本锁死在一个核上。Redis 7.0 沿用了这个模型。
• Redis 的另一个优势是内存效率的编码优化：小 Hash 用 listpack、小 Set 用 intset，几万个字段的小对象能压到极省内存。而 Memcached 的 slab allocator（按固定大小分块的分配器，默认 chunk 增长因子 1.25、page 1MB）在面对尺寸差异大的 value 时会出现"slab 固化"，内存利用率反而下降。

所以"Memcached 更快"只在特定条件下成立：value 小、纯 GET/SET、多核、无复杂命令。一旦你要用 ZADD、HSET、LPUSH，Memcached 得自己把整个结构取回来、改完、再写回去，网络往返和并发问题会让性能优势荡然无存。

什么情况下应该选 Memcached？

结论：只有同时满足"纯 KV 缓存 + 无持久化需求 + 多核高吞吐 + 已有运维体系"这四条时，Memcached 才值得选。

典型场景是：把数据库查询结果整块塞进缓存，key 是 SQL 的哈希，value 是序列化后的数组，读完就走，重启丢了也无所谓，下次回源查库即可。这种"缓存击穿后能回源"的场景，Memcached 的简单性就是优点：协议简单、无持久化意味着没有 fork 写盘的抖动、无主从意味着不用担心主从延迟读到旧数据。

另外，Memcached 的默认端口是 11211，stats 命令输出的指标很少，排查问题比 Redis 的 INFO、SLOWLOG、MONITOR 简单得多。

什么情况下应该选 Redis？

结论：只要涉及分布式锁、排行榜、计数器、限流、消息队列、会话共享中的任意一项，就必须用 Redis，Memcached 做不了。

几个具体例子：

• 分布式锁：SET lock_key uuid NX PX 30000，一条命令原子加锁并带超时；解锁要用 Lua 脚本比对 value 再删，避免误删他人的锁。Memcached 的 add 也能加锁，但没有原生的安全释放机制。
• 排行榜：ZADD rank 100 user1 + ZREVRANGE rank 0 9 WITHSCORES，O(log N) 完成；Memcached 得全量拉回客户端排序。
• 限流：INCR 配合 EXPIRE，或者用 Lua 做令牌桶，天然原子。
• 会话共享：Redis 的 Hash 可以只更新 session 里的某个字段，Memcached 必须整体覆盖。

代价是 Redis 的运维复杂度更高：要配 maxmemory-policy（推荐 allkeys-lru 或 allkeys-lfu，Redis 4.0 起支持 LFU），要防大 key 和热 key，要监控主从延迟。但换来的能力上限，Memcached 一辈子都追不上。

从 Memcached 迁到 Redis 要注意什么？

结论：迁移动代码不多，但三个坑必须提前处理——TTL、value 大小、key 长度。

1. TTL 语义变了：Memcached 里传大于 2592000 的值是"绝对时间戳"，Redis 的 EXPIRE 一律是相对秒数。迁移时要把老的绝对时间戳换算成 时间戳 - now，否则缓存会立刻全部过期。
2. value 上限变了：Memcached 默认 1MB，如果你的 -I 调过，迁到 Redis 后 512MB 上限通常没问题；反过来 Redis 迁 Memcached 才是灾难。
3. key 长度：Memcached 限制 250 字节，Redis 宽松，所以 Redis 迁 Memcached 时才需要关注。
4. 序列化格式：Memcached 客户端常直接存 PHP serialize 或 Java 序列化结果，Redis 客户端一般用 RESP 原生类型。迁移时建议先在双写阶段验证反序列化兼容性。

收个尾：判断标准其实就是一句话——**你要的是"更快的内存缓存"，用 Memcached；你要的是"更强的内存数据服务"，用 Redis。** 前者在 2024 年只剩下极窄的适用面，后者已经成为默认选项。真拿不准，就先按 Redis 设计，等压测证明单核是瓶颈、且业务确实只有 KV 读写时，再考虑把那一层缓存换成 Memcached。