3. Redis vs Memcached 架构对比
本章从架构方案视角对比 Redis 和 Memcached 在数据结构、持久化、集群、内存管理及适用场景上的核心差异。内容围绕系统边界、分层职责、组件职责、数据流与信任链路展开，并给出选型权衡、风险点、落地步骤与验收标准，帮助你在真实业务中做出合理决策。
3.1 系统边界与分层职责
缓存层在整体架构中位于应用层与持久化层之间，职责是降低数据访问延迟和数据库压力。Redis 和 Memcached 作为缓存组件，其边界不同：
- Memcached：纯粹的内存键值缓存，不支持持久化，数据丢失后完全从下游恢复。职责限定在高速读取热数据。
- Redis：内存数据库 + 缓存，内置持久化（RDB/AOF）、多种数据结构及 Lua 脚本。职责可延伸至会话存储、消息队列、实时排行榜等。
3.2 组件职责与数据结构差异
| 维度 | Redis | Memcached |
|---|---|---|
| 数据结构 | String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Stream | 仅支持简单 Key-Value（最大 1MB） |
| 持久化 | RDB（快照）+ AOF（追加日志），可选关闭 | 无持久化 |
| 集群模式 | Redis Cluster（无中心化分片）、Sentinel（高可用）、Proxy（Twemproxy/RedisShard） | 客户端分片（一致性哈希），无原生集群 |
| 内存管理 | jemalloc 分配，支持 maxmemory + 淘汰策略（LRU/LFU/TTL 等 8 种） | slab allocator，固定 chunk 大小，可能存在内存浪费 |
| 适用场景 | 复杂数据结构、持久化需求、分布式锁、发布订阅、实时分析 | 简单键值缓存（如 Session、静态数据），对持久化无要求的场景 |
架构权衡：如果应用需要原子递增、集合操作或消息队列，Redis 是唯一选择；如果只是纯 KV 缓存且希望最小化运维复杂度，Memcached 更轻量。
3.3 数据流与信任链路
在典型读缓存数据流中，应用先查询缓存，未命中则回源数据库并回填缓存。两种组件的信任链路差异在于：
- Memcached：缓存视为“可能丢失”的加速层，应用必须容忍缓存 miss 后从数据库重建。
- Redis：持久化后可以视作“可靠存储”，但在集群模式下仍存在数据不一致窗口（主从异步复制）。信任链路建议：写操作直接写 Redis 主节点，读操作可读从节点（允许秒级延迟）。
经验建议：无论使用哪款缓存，都不应将其作为唯一数据源。缓存层应始终设计为可降级、可重建。
3.4 集群模式与内存管理对比
以下 SVG 展示了 Redis Cluster 与 Memcached 客户端分片的架构对比：
3.5 选型权衡
- 数据结构复杂度：如果需要 Sorted Set 做排行榜、Hash 做对象缓存、List 做消息队列，选 Redis。只存字符串选 Memcached。
- 持久化需求：缓存数据可丢失则 Memcached；允许秒级数据恢复（RDB）或全量不丢（AOF + 同步写）则 Redis。
- 集群可管理性：团队运维能力强且需要自动分片用 Redis Cluster；希望客户端控制分片逻辑或已有一致性哈希库用 Memcached。
- 内存效率：Redis 使用 jemalloc 碎片较少；Memcached slab 预分配可能浪费内存，但 key 过期回收机制更简单。
3.6 风险点
以下是使用两种缓存时的常见风险：
| 风险域 | Redis | Memcached |
|---|---|---|
| 内存溢出 | 设置 maxmemory 并选择合理淘汰策略，否则 OOM | slab 内部 LRU 自动淘汰，但可能内存浪费 |
| 数据不一致 | 主从异步复制（<1s 窗口），故障切换可能丢少量数据 | 无复制，实例宕机数据全丢 |
| 热点 Key | Redis Cluster 支持多节点但不能分散单 Key 流量，需要本地缓存降级 | 客户端可通过虚拟节点分散，但仍需应用层限流 |
| 运维复杂度 | 哨兵/集群配置、持久化文件管理、慢查询排查 | 几乎零运维，但缺乏监控工具 |
风险警示：不要在生产环境使用 Redis Sentinel + 异步复制作为“可靠存储”；Memcached 的过期数据在 GET 时立即删除，但不会通知客户端，需应用自行容忍 miss。
3.7 落地步骤与验收标准
落地步骤（团队可参照执行）
- 需求梳理：确认缓存数据结构需求、持久化要求、预期 QPS、数据量及可用性目标。
- 集群选型：根据需求选择 Redis Cluster（>10GB/需要持久化）或 Memcached 客户端分片（<10GB/纯KV）。
- 部署与配置：准备硬件（Redis 建议 >8GB 内存，Memcached 建议 SSD 小容量）。如适用，配置示例：
# Redis 单节点配置示例（如适用）
# redis.conf
maxmemory 4gb
maxmemory-policy allkeys-lru
appendonly yes
appendfsync everysec# Memcached 启动示例（如适用）
memcached -m 4096 -p 11211 -c 1024 -l 0.0.0.0- 客户端集成：Java 推荐 Lettuce（Redis）/ Spymemcached（Memcached）；Python 推荐 redis-py / pymemcache。
- 监控与告警：接入 metrics（内存使用、命中率、延迟 P99），设置阈值告警。
- 混沌测试：模拟节点宕机、网络抖动，验证降级逻辑和缓存重建流程。
验收标准
- 缓存命中率 ≥95%（热数据场景）或达到业务预期值。
- 读延迟 P99 ＜ 5ms（内网环境），P99 ＜ 20ms（跨机房）。
- 故障切换时间：Redis Sentinel ≤ 30s；Memcached 依赖客户端重新哈希，通常 < 1s。
- 持久化 RDB 恢复时间：10GB 数据恢复 ≤ 5min（如适用）。
- 内存碎片率（Redis INFO）≤ 1.5；Memcached slab 浪费率 ≤ 10%。
验收小技巧：在压测阶段同时开启慢日志（Redis SLOWLOG / Memcached -v 输出），定位热点 Key 和慢查询，确保上线前优化。