Redis vs Memcached：缓存选型与高级数据结构完全对比

1. 数据结构：KV 简洁 vs 丰富生态

Memcached 的哲学是极简主义：只支持一种数据类型——字节串（Byte String）。存进去什么，取出来就是什么，完全由应用层负责序列化和反序列化。

Redis 则相反，原生支持 8+ 种数据结构。最常见的包括：

• String：最基础的 KV，还支持原子的 INCR（计数）、APPEND（追加）。
• Hash：对象级缓存，比 JSON 字符串更高效。例如存储用户信息的多个字段。
• List：双向链表，支持 PUSH/POP/LRANGE，常用于消息队列、最近浏览历史。
• Set：无序集合，支持集合运算（UNION、INTER、DIFF），用于去重、标签、粉丝列表。
• ZSet（Sorted Set）：有序集合，每个元素有 score，支持范围查询，是排行榜的标准方案。
• Bitmap：位数组，用于大规模二值状态（用户签到、IP 去重）。
• HyperLogLog：估计基数（Cardinality），用于 UV 统计，超高效。
• Stream：消息日志，带消费者组和自动重试（Redis 5.0+）。

这些结构的威力在于，很多复杂的业务逻辑都能直接用 Redis 的数据结构实现，无需在应用层逐行处理。例如，排行榜用 Memcached 需要：读取所有用户分数 → 应用层排序 → 返回 Top 10。用 Redis ZSet，一行命令搞定：

选型建议：简单 KV 缓存（HTML 页面、API 响应）——Memcached 够用；需要计数、排行、队列、标签集合——Redis 高级数据结构是必需。

2. 持久化机制：无 vs RDB/AOF

Memcached 完全不支持持久化。机器重启，所有数据灰飞烟灭。这看起来很糟糕，但其实是设计哲学的体现：Memcached 就是短期缓存，本来就不应该依赖它存长期数据。

Redis 则提供了两种持久化方式。RDB（快照）是定期生成一个内存镜像，文件紧凑、恢复快，但每次快照间隔内的数据会丢失；AOF（日志）记录每个写命令，可恢复到任意时间点，但文件大、恢复慢。生产环境通常结合使用：

持久化能力意味着什么？意味着 Redis 可以用来做 Memcached 做不了的事情：临时数据不丢失、宕机恢复、跨机房同步。很多团队甚至把 Redis 当"跨进程共享内存"用，而不仅仅是缓存。

但代价是：RDB 生成时会 fork 进程（内存加倍），可能触发 FullGC；AOF 重写也会产生临时磁盘占用。运维需要监控磁盘和内存。Memcached 则永远不用担心这些。

选型建议：纯缓存、丢失可接受——Memcached；数据需要持久化、宕机快速恢复——Redis。

3. 发布订阅与消息队列

Memcached 是完全被动的：客户端请求它才返回数据。它对"主动推送"一无所知。

Redis 的 Pub/Sub 模式允许一个客户端发布消息到一个频道（channel），其他订阅这个频道的客户端会收到通知。这在很多场景下非常有用：

• 聊天系统：用户 A 发送消息，其他在线用户实时收到。
• 实时通知：订单状态变化通知买家、卖家。
• 缓存失效广播：中央服务器告诉所有缓存节点，某个数据过期了。

但 Redis Pub/Sub 有一个致命缺陷：没有持久化。如果订阅者掉线，消息永久丢失。这也是为什么 Redis 5.0 引入了 Stream 数据结构——它是"消息队列的正确答案"，支持消费者组、自动重试、持久化：

Stream 的出现，让 Redis 可以替代轻量级消息队列（如 RabbitMQ 的部分功能），尤其是在中小型项目中。Memcached 永远做不到。

选型建议：简单 Pub/Sub（实时性 > 可靠性）——Redis Pub/Sub；需要消息持久化和重试——Redis Stream；企业级消息队列——用专业的 RabbitMQ/Kafka。

4. Lua 脚本与原子操作

分布式系统中，最常见的问题是"检查再修改"（Check-Then-Act）的竞态条件。例如，分布式锁：

在 Memcached 中，这两步之间可能有另一个客户端也拿到了锁，造成竞态。Memcached 的 CAS（Compare-And-Swap）可以解决，但仅适用于简单的 KV 更新。

Redis 的 Lua 脚本直接了当：把多个命令打包成一个原子事务，服务器执行脚本期间不会有其他命令打断。分布式锁的正确实现：

这样，检查所有权 + 删除锁在 Redis 层面是原子的，完全避免竞态条件。基于 Lua 脚本，衍生出了很多强大的模式：限流算法（令牌桶）、分布式锁、去重、库存扣减。这都是 Memcached 无法胜任的领域。

选型建议：需要原子操作、分布式锁、复杂业务逻辑——Redis 的 Lua 脚本是必需；简单计数、无冲突场景——Memcached CAS 够用。

5. 高可用：Sentinel vs Cluster

Memcached 的高可用方案是：多副本 + 应用层故障转移。应用程序维护一个 Memcached 节点列表，如果一个节点宕机，就自动切到另一个。这种方式简单，但问题也明显：缓存无法跨节点备份（数据丢失风险）、应用层逻辑复杂。

Redis 提供了两种不同的高可用方案。

Sentinel 模式：主从 + 自动故障转移。一个主库（Master），多个从库（Slave），Sentinel 守护进程监控主库健康，如果宕机自动提升一个从库为主。应用层无感知，写请求自动转到新主库。这种方案运维相对简单，适合大多数应用。

Cluster 模式：数据分片存储。整个数据集分成多个分片，每个分片可以有多个副本。支持水平扩展，当单机容量达到极限时，直接添加新节点扩容。但运维复杂：需要考虑分片策略、跨分片查询、故障转移。通常 QPS 超过单机极限（百万级）才考虑 Cluster。

Memcached 也有集群方案（如一致性 Hash），但原生不支持主从备份和自动故障转移。

选型建议：99% 的应用用 Redis Sentinel 够用；超大规模互联网公司、百万级 QPS——才考虑 Cluster；中小型团队、Memcached——自行维护节点列表。

6. 内存效率与存储密度

Memcached 的内存占用率通常更高效。因为它是纯 KV 存储，没有复杂的数据结构开销。对于小对象（< 1 KB），Memcached 能达到 70-80% 的内存利用率。

Redis 因为支持复杂数据结构，会多占用一些内存用于元数据和指针。例如，一个包含 100 个元素的 List，Memcached 可能占用 10 KB，Redis 可能占用 12-15 KB。对于大对象和高频访问数据，差异不明显；但在缓存密集、对象众多的场景下，差异能达到 20-30%。

但这个 20-30% 的额外成本，换来了 Redis 的数据结构能力，通常是值得的。而且，很多团队会用 Redis 的 SET 或 ZSet 代替多个 Memcached Key，这样反而节省内存。

选型建议：内存紧张（树莓派、边缘计算）——Memcached；现代云环境、内存成本不是瓶颈——Redis。

7. 性能对比与真实场景基准

单机单线程的简单 GET/SET 操作上，Memcached 确实快一点——通常快 10-20%。这是因为 Memcached 用纯 C 实现，路径短；Redis 是单线程 C 实现，但要处理更复杂的数据结构操作。

但现实中，这个差异几乎不重要。原因有两个：

• 网络延迟 >> 处理延迟：往返延迟通常 1-5 毫秒，单机处理都是微秒级，Memcached 快 10 微秒对总延迟的改善可以忽略。
• Redis 6.0+ 多线程：Redis 6.0 引入了 I/O 多线程，性能已经可以和 Memcached 相媲美，甚至在某些场景更快（因为命令管道化）。

真实基准（Redis 6.0 vs Memcached，每秒请求数）：

• 简单 GET：Redis ~100K ops/sec，Memcached ~110K ops/sec（差异 < 10%）
• SET + GET 混合：两者相近（~80K ops/sec）
• 管道化请求（10 个命令一批）：Redis 胜（因为网络效率）
• 复杂数据结构操作：Redis 胜（无可比性）

选型建议：性能不是主要考虑因素（网络往返才是瓶颈），功能和易用性更重要。用 Redis。

8. 运维复杂度与社区生态

Memcached 的运维非常简单：启动一个进程，丢给应用层处理连接和故障转移，完全无状态。缺点就是无状态，宕机数据全丢，应用层要自己处理故障。

Redis 的运维相对复杂：要考虑持久化配置（RDB/AOF 何时生成）、内存限制和驱逐策略（当内存满了怎么办）、复制参数（主从延迟）、Sentinel 监控。但好处是有状态，故障转移自动化，持久化保证数据不丢。

社区生态上，Redis 已经压倒性领先。Redis 的客户端库（Node-redis、Jedis、Predis）成熟度最高，文档、最佳实践、开源工具（Redis Commander、RedisInsight）都很丰富。Memcached 的生态相对冷清。

现在，大多数团队选择 Redis，即使只用其中的 KV 功能。原因很简单：Redis 的额外功能（Lua、Pub/Sub、Stream、Sentinel）让它的价值更高，学习成本一次性投入，之后收益持久。

选型建议：新项目 100% 选 Redis；维护老 Memcached 项目，逐步迁移 Redis。