Redis 和 Memcached 的区别是什么？

Redis 和 Memcached 的区别是什么？

面试考察点

此题主要是考察以下几个方面：

1. 对缓存中间件的本质理解：不仅仅是罗列功能特性，更是考察你是否理解两者作为缓存解决方案的核心设计哲学、定位与权衡。
2. 技术选型与架构设计能力：能否根据具体的业务场景（如数据结构复杂度、数据持久性要求、集群规模、性能瓶颈）做出合理的技术选型。
3. 知识广度与深度：是否深入了解两者在数据结构、持久化、集群模式、线程模型、内存管理等核心机制上的差异。

核心答案

Redis 和 Memcached 都是高性能的分布式内存数据存储，常被用作缓存。但 Redis 功能更丰富，是一个支持多种数据结构的 “数据结构服务器”，而 Memcached 是一个设计目标极为聚焦的 “高性能分布式内存键值缓存”。

主要区别在于：

1. 数据结构：Redis 支持 String、List、Set、Hash、Sorted Set 等丰富结构；Memcached 仅支持简单的 String 键值对。
2. 数据持久化：Redis 支持 RDB 快照和 AOF 日志两种持久化机制，可将数据存于磁盘中；Memcached 不支持，数据纯存在内存中。
3. 集群与高可用：Redis 原生支持主从复制、哨兵模式和功能强大的 Redis Cluster 分片集群；Memcached 需依赖客户端（如一致性哈希）实现分片，本身无内置集群方案。
4. 线程模型：Redis 6.0 之前是单线程处理命令（内存操作，避免锁竞争），6.0 后引入多线程处理网络I/O；Memcached 是多线程模型，利用多核优势。
5. 内存管理：Memcached 使用 Slab Allocation 机制预先分配内存池，减少碎片，但可能造成空间浪费；Redis 在原生字符串上使用动态 SDS，在高端版本中引入了类似的内存池优化。

简单总结：如果需要缓存复杂的业务对象、有持久化需求、或需要实现队列、排行榜等高级功能，选 Redis。如果缓存的对象都是简单的、巨大的字符串（如大型 HTML 片段），且追求极致的简单性和在多核 CPU 下的吞吐量，Memcached 仍然是经典选择。

深度解析

1. 核心特性对比

特性维度	Redis	Memcached
数据结构	丰富 (String, List, Hash, Set, Sorted Set, Bitmaps等)	单一 (仅 String 键值对)
数据持久化	支持 (RDB, AOF)	不支持 (纯内存，重启丢失)
主从复制	原生支持 (异步/半同步)	不支持
分片集群	原生支持 (Redis Cluster)	依赖客户端实现
线程模型	单线程（核心命令处理） + 多I/O线程	多线程 (利用多核)
内存管理	动态分配 + 内存优化策略	Slab Allocation + LRU
网络IO模型	多路复用 (epoll/kqueue)	多路复用 + 多线程
事务	支持 (MULTI/EXEC)	不支持
发布订阅	支持	不支持
Lua脚本	支持	不支持
适用场景	缓存、会话存储、消息队列、排行榜等	简单的键值缓存

2. 原理与机制详解

• 数据结构差异：Redis 的 Hash 可以完美映射一个 Java 对象，List 可作为轻量级队列，Sorted Set 可直接实现排行榜。Memcached 存储复杂对象需要序列化为 String（如 JSON），增加了序列化/反序列化开销和网络流量。

  // Redis 示例：存储和操作一个用户对象（Hash）
  // hset user:1001 name "张三" age 30 city "北京"
  // hget user:1001 name -> "张三"
  // hincrby user:1001 age 1 -> 31
  
  // Memcached 示例：存储同一个用户对象
  // 需要先将对象序列化（如使用Jackson转为JSON字符串）
  User user = new User("张三", 30, "北京");
  String userJson = objectMapper.writeValueAsString(user);
  // set user:1001 userJson
  // get user:1001 后还需反序列化
  

• 持久化与高可用：Redis 的持久化使其可用于缓存降级——当数据库故障时，部分持久化数据仍可提供服务。Redis Sentinel 和 Redis Cluster 提供了官方的、成熟的高可用与水平扩展方案。Memcached 的集群完全由客户端库（如 spymemcached）通过一致性哈希算法构建，服务端节点互不知晓，扩容时需要重哈希，可能导致大量缓存失效。

• 内存管理：

  • Memcached 的 Slab Allocation 将内存划分为不同大小的 Chunk，每个 Slab Class 管理相同大小的 Chunk。这能有效减少内存碎片，但可能因存储对象大小与 Chunk 不匹配导致内存浪费（如 100字节 的对象存入 128字节的 Chunk）。
  • Redis 早期版本主要依赖系统的内存分配器（如 glibc 的 malloc），在频繁更新场景下可能产生碎片。后续版本引入了 jemalloc 作为默认分配器，并提供了 MEMORY PURGE 等命令和内存优化配置来缓解此问题。

• 线程模型与性能：

  • Redis 的单线程优势：避免了多线程的锁竞争和上下文切换，保证了命令的原子顺序执行。其性能瓶颈通常在网络 I/O 或 内存访问速度，而非 CPU。6.0 后引入的多线程 I/O（默认关闭）用于分担网络读写的压力，但核心命令逻辑仍是单线程。
  • Memcached 的多线程优势：利用多核，每个线程独立处理连接，在存储大Value（如超过 1MB）或极高并发纯Set/Get的场景下，理论吞吐量可能超过 Redis 的单线程模型。

3. 最佳实践与选型建议

• 选择 Redis，如果：
  • 需要缓存结构化数据（如用户信息、商品详情）。
  • 业务逻辑需要复杂操作（如交集、排序、自增）。
  • 需要数据持久化防止缓存雪崩后无法恢复。
  • 需要构建高可用集群，且希望有官方成熟方案。
  • 希望用同一个技术实现缓存、分布式锁、轻量队列等多种功能。
• 选择 Memcached，如果：
  • 缓存的数据项非常大（例如巨型文本或图片二进制），且生命周期短。
  • 应用场景极其简单，只有 set/get/delete。
  • 拥有大量多核 CPU，并且希望充分利用每一个核心的缓存性能。
  • 追求极致的简单性和运维的轻量。

4. 常见误区

• “Redis 在所有方面都比 Memcached 快”：错误。对于超大的 Value（如 1MB 以上）的读写，Memcached 的多线程模型可能表现更好。
• “Memcached 已经过时了”：不完全正确。在一些特定场景（如仅缓存大块静态内容）和追求极致简单性的架构中，Memcached 依然有其用武之地。
• “Redis 的集群方案可以无缝线性扩展”：需要谨慎。Redis Cluster 的 slot 分配、跨节点事务/命令限制（如要求所有 key 在同一 slot 的 mget）需要在应用层进行设计适应。

总结

Redis 是一个功能强大的内存数据存储，其丰富的数据类型和持久化特性使其超越了单纯缓存的范畴；而 Memcached 则是一个设计纯粹的分布式内存缓存，在特定简单场景下仍具备性能和简洁性优势。技术选型的核心在于契合业务场景，而非盲目追求技术的新潮或功能的繁多。