Appearance
Redis 和 Memcached 都是流行的高性能内存数据存储方案，常用于缓存、会话管理等场景。尽管它们有相似的用途，但在架构、功能和适用场景上存在显著差异。
1. 架构区别
| 特性/维度 | Memcached | Redis |
|---|---|---|
| 数据模型 | 简单键值对 (String -> String)：仅支持字符串（或字节数组）的键和值。 | 丰富的数据结构：支持字符串、列表 (lists)、哈希 (hashes)、集合 (sets)、有序集合 (sorted sets)、流 (streams)、位图 (bitmaps)、HyperLogLogs、地理空间索引 (geospatial) 等。 |
| 持久化 | 无持久化：数据完全存储在内存中。服务器重启或进程终止会导致数据丢失。 | 支持持久化： 1. RDB (快照)：周期性地将内存中的数据保存到磁盘。 2. AOF (Append Only File)：将每个写操作命令追加到文件中，服务器重启时通过重放 AOF 文件恢复数据。 |
| 并发模型 | 多线程：通常采用多线程模型，每个连接或操作可以使用独立的线程来处理，提高并发能力（对于简单的GET/SET操作）。 | 单线程事件循环 (Event Loop)：核心处理逻辑是单线程的，使用 I/O 多路复用（如 Epoll, Kqueue）来处理大量并发连接。这避免了锁竞争，简化了内部实现，并保证了操作的原子性。但对于 CPU 密集型任务，单线程可能会成为瓶颈（尽管 Redis 的操作大多是内存操作，速度非常快）。 |
| 复制与高可用 | 无内置复制/高可用机制：不提供服务器端的复制、故障转移或集群功能。分布式通常由客户端进行一致性哈希 (Consistent Hashing) 来实现。如果一个节点宕机，客户端需要负责处理请求重试或数据丢失。 | 内置强大的复制/高可用/集群机制： 1. 主从复制 (Master-Slave)：支持数据从主节点异步复制到多个从节点，用于读写分离和数据备份。 2. Sentinel (哨兵)：自动监控主从节点，并在主节点宕机时自动进行故障转移，提升高可用性。 3. Cluster (集群)：提供了数据分片 (Sharding) 和自动故障转移的能力，实现水平扩展。 |
| 事务 | 无事务支持 | 支持事务：通过 MULTI, EXEC, DISCARD, WATCH 命令实现原子性操作序列。 |
| 高级功能 | 极少，主要就是基本的键值操作。 | 丰富的高级功能： 1. 发布/订阅 (Pub/Sub)：实现消息队列。 2. Lua 脚本：服务器端执行脚本，实现复杂业务逻辑，保证原子性。 3. 键过期 (Expiration)：为键设置过期时间。 4. 淘汰策略 (Eviction Policies)：多种内存淘汰策略（LRU, LFU 等）。 5. 地理空间索引、HyperLogLog、位图等。 |
| 内存管理 | 简单 LRU 淘汰策略。 | 更细致的内存管理，支持多种淘汰策略 (volatile-lru, allkeys-lru, noeviction 等)，并能配置最大内存。 |
2. 优缺点
Memcached
优点：
- 极度简单和高性能：由于其简单的数据模型和操作，Memcached 对于单纯的键值缓存操作速度非常快。
- 多线程优势：在处理大量简单并发请求时，多线程模型能更好地利用多核 CPU。
- 内存效率高：相对于 Redis，Memcached 内部结构更简单，对于相同的纯字符串数据量，其内存开销通常更小。
- 易于部署和使用：没有复杂的功能，学习曲线平缓。
- 成熟稳定：作为老牌缓存系统，非常成熟和稳定。
缺点：
- 无持久化：数据完全在内存中，服务重启数据即丢失，不适合作为持久性存储。
- 功能单一：仅支持字符串类型，缺乏复杂数据结构和高级功能（如事务、发布/订阅等）。
- 无内置高可用性：需要客户端实现分布式逻辑，不提供服务端的数据复制和故障转移。
- 客户端负责一致性哈希：客户端需要维护节点列表和一致性哈希算法，增加了客户端的复杂性。
Redis
优点：
- 丰富的数据结构：支持多种复杂数据结构，使得 Redis 不仅仅是一个缓存，还能用于实现队列、排行榜、计数器、实时分析等多种应用场景。
- 数据持久化：支持 RDB 和 AOF 两种持久化方式，保证数据在重启后不丢失，使其可以作为主数据存储使用。
- 高可用和集群：内置主从复制、Sentinel 和 Cluster 机制，提供了强大的高可用、故障转移和水平扩展能力。
- 原子性操作：单线程模型保证了每个操作的原子性，无需担心并发问题。同时支持事务和 Lua 脚本，可以原子性地执行多个命令。
- 功能强大：支持发布/订阅、Lua 脚本、事务、键过期、内存淘汰策略等高级功能，大大扩展了其应用范围。
缺点：
- 相对复杂：功能丰富也意味着配置和管理更复杂，学习曲线较 Memcached 陡峭。
- 单线程限制：虽然单线程处理速度非常快，但在执行 CPU 密集型命令（如大数据量的 SORT、Lua 脚本执行时间过长）时，可能会阻塞整个服务，影响其他请求。
- 内存占用：由于支持更复杂的数据结构和额外的元数据，相同的纯字符串数据量下，Redis 的内存占用通常会略高于 Memcached。
- 故障转移和集群管理：虽然内置了这些机制，但配置和维护起来仍然需要一定的专业知识。
3. 适用场景
Memcached 适用场景
- 纯粹的分布式缓存：当你的应用需要一个简单、高性能的分布式缓存层，且数据丢失不是关键问题时（例如，缓存数据库查询结果或页面片段）。
- 大规模、高并发的简单键值存储：在请求量巨大，且对数据结构没有复杂要求（只存取字符串）的场景下，Memcached 能够提供极高的吞吐量。
- 临时会话存储：存储用户会话数据，但如果会话数据丢失不影响用户体验（例如，登录状态可以通过重新登录恢复）。
- 快速获取静态或半静态数据：例如，文章内容、商品信息等，这些数据从数据库加载耗时，但更新频率不高。
Redis 适用场景
- 高级缓存需求：可以完全替代 Memcached 的所有缓存场景，并且提供更多功能（如键过期、LRU 淘汰策略、持久化等）。
- 实时排行榜/计数器：使用 Sorted Sets 实现游戏排行榜，使用原子递增实现点赞数、访问量统计、商品库存等。
- 会话管理：存储用户会话信息，由于支持持久化，即使服务器重启也能保证会话不丢失。
- 消息队列/实时系统：使用 List（BLPOP/BRPOP）作为简单队列，或使用 Pub/Sub 实现发布/订阅模式的消息系统，或使用 Streams 实现更复杂的消息处理。
- 地理空间应用：存储地理位置信息并进行半径查询等。
- 社交网络功能：关注/粉丝列表（使用 Set），新鲜事时间线（使用 List 或 Sorted Set）。
- 实时统计与分析：使用 HyperLogLog 进行去重计数，或结合其他数据结构进行实时数据分析。
- 分布式锁：利用其原子操作特性实现可靠的分布式锁。
- 全页缓存 (FPC)：存储整个渲染好的 HTML 页面，配合过期时间或更新策略。
总结
选择 Redis 还是 Memcached，主要取决于你的具体需求：
- 如果你需要一个简单、纯粹、高性能的分布式缓存，并且对数据结构、持久化和高可用没有复杂要求，那么 Memcached 是一个非常好的选择。
- 如果你需要更丰富的数据结构、数据持久化、内置高可用、事务、发布/订阅等高级功能，并将内存数据库用于更多应用场景，那么 Redis 无疑是更强大、更灵活的选择。
在多数现代应用开发中，Redis 因其强大的功能和更广泛的适用性，已成为首选的内存数据存储解决方案。Memcached 则更常用于那些对内存占用和简单缓存性能有极致要求的场景。