第3章 L2缓存(Remote Cache)的架构边界：Redis/Memcached集群、分布式存储、网络开销与容量上限
两级缓存架构中，L2（远程缓存）位于本地缓存与持久化存储之间，承担跨进程共享数据、降低数据库负载、提供缓存高可用性的核心职责。典型实现包括 Redis 集群和 Memcached 集群。本章将深入分析 L2 缓存的架构边界、分层位置、组件职责、数据流与控制流、选型权衡、风险点及落地验收标准。
关键边界指标：L2 缓存应承载 TTL 在秒~小时级、可被多个服务共享且更新频率不高的数据。单对象大小超过 1MB 建议压缩或分片，避免网络开销陡增。
3.1 架构边界与分层位置
L2 的边界由“共享性”和“网络距离”共同定义。与 L1 进程内缓存不同，L2 必须通过网络访问，同机房延迟约 1~5ms，跨机房可达 10~50ms。容量上限受限于集群内存总量或混合存储（如 Redis on Flash），通常可达 TB 级。下图展示了 L2 缓存在整体架构中的位置与关键边界要素。
网络开销是 L2 缓存最关键的边界参数。在 100 万 QPS 下，每增加 1ms 延迟可能使整体响应时间飙升。建议同机房部署，并启用连接复用、Pipeline 或客户端侧批量接口。
3.2 组件职责
L2 缓存主要组件包括缓存节点、集群管理、数据分片、高可用复制及监控。下表对比 Redis 与 Memcached 在 L2 场景中的职责差异：
| 职责 | Redis | Memcached |
|---|---|---|
| 数据结构 | String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog | 仅支持 String (Key-Value) |
| 持久化 | RDB / AOF 支持，可恢复数据 | 无持久化，重启即丢 |
| 集群模式 | Redis Cluster 原生分片 + Sentinel 高可用 | 客户端一致性哈希，无内置集群 |
| 一致性保障 | 强最终一致性（主从异步复制） | 无复制，依赖客户端 |
| 最大 Key/Value | 512 MB | 1 MB |
| 多线程模型 | 6.0 前单线程，后续多线程 I/O | 原生多线程，高并发友好 |
| 热升级 | Cluster 模式支持动态增删节点 | 需重启集群 |
3.3 数据流与控制流
读路径： Application → 查 L1 (命中则返回) → 未命中查 L2 → 未命中查 Database → 回写 L2 并设置 TTL → 回写 L1。
写路径： Application → 写 Database → 删除或更新 L2 (异步刷新时先更新 L2 再异步写 DB) → 通知其他节点淘汰 L1 中的对应 key。
控制流关键点：
- TTL 管理： L2 的 TTL 通常比 L1 长 2~5 倍，避免 L1 过期后缓存穿透直接到 DB。
- 淘汰策略： Redis 支持 LRU、LFU、TTL 等；Memcached 仅 LRU。
- 缓存穿透 / 击穿 / 雪崩防护：
- 穿透：L2 中缓存空值（short TTL，如 30s）或使用布隆过滤器。
- 击穿：热点 key 重建时加互斥锁（SETNX）或使用分布式锁。
- 雪崩：TTL 增加随机偏移（±10%～±30%）。
3.4 信任链路
L2 缓存信任 L1 的 TTL 设置和淘汰通知，但需额外处理以下场景：
- L1 脏数据： L1 中存储的数据可能因本地 TTL 过期而无法被主动淘汰，L2 应提供显式 invalidation 通信（如 Pub/Sub 消息或共享状态）。
- 网络不可靠： L2 与 L1 之间丢失 invalidation 消息会导致不一致，建议在 L2 写入后延迟很短时间（如 10ms）再允许客户端从 L1 读取。
- 故障切换： Redis Cluster 故障转移期间，旧 Master 的写入可能丢失，L2 应容忍短暂不一致。
3.5 选型权衡：Redis vs Memcached
选择依据不仅限于性能，更取决于数据模型、运维能力和一致性需求。下表进一步细化关键决策点：
| 决策维度 | 倾向 Redis | 倾向 Memcached |
|---|---|---|
| 数据结构复杂度 | 需要 Hash/List/Sorted Set 等 | 仅 String，简单场景 |
| 数据持久化要求 | 缓存不可丢失（如 Session 存储） | 缓存允许重算（如纯性能加速） |
| 集群规模 | 50+ 节点，需动态扩缩容 | 小型集群（≤20 节点），手动分片 |
| 延迟敏感性 | 支持 Pipeline 减少网络往返 | 多线程，单点吞吐更高 |
| 运维成本 | 需管理 Cluster/Sentinel，较复杂 | 无状态，部署简单 |
| 社区活跃度 | 高，持续更新 | 低，已停止核心开发 |
3.6 风险点
- 网络抖动导致 P99 延迟飙升： 单次超时可能引发客户端重试风暴，建议设置合理的超时（如 200ms）和退避策略。
- 大 Key 阻塞 Redis： 单个 Key 超过 10MB 会导致慢查询，建议拆分为多个小 Key 或使用压缩。
- 热点 Key 倾斜： 频繁访问的 Key 集中在同一分片，造成局部负载过高，可通过本地缓存（L1）或增加副本分散读请求。
- 容量规划不足： 内存打满后触发 OOM 或 eviction 导致命中率骤降，需配置 maxmemory 和合理的淘汰策略，并预留 20% 安全水位。
- 集群扩缩容数据迁移： Redis Cluster 槽迁移期间会阻塞部分请求，建议在低峰期操作并开启 cluster-slave-validity-factor 确保副本可用。
特别注意：L2 缓存容量上限并非越高越好。超过内存物理容量后需开启混合存储（如 Redis on Flash），但写入性能会下降 10～50 倍。务必根据业务数据量及增长曲线提前规划内存预算。
3.7 落地步骤
- 数据筛选： 识别适合放入 L2 的数据（高频读、低更新、可容忍最终一致性），制定缓存 key 命名规范及 TTL 策略。
- 集群选型与部署：
- Redis：部署 3 个 Master 节点（至少 3 个，奇数），每个 Master 带 1～2 个 Replica。配置示例：
redis-cli --cluster create \
192.168.1.1:6379 192.168.1.2:6379 192.168.1.3:6379 \
--cluster-replicas 1- 客户端配置： 连接池大小（通常 8～16）、超时时间（connect: 500ms, read: 200ms）、重试策略（最多 2 次，退避 100ms）、序列化协议（MessagePack 或 protobuf 减少带宽）。
- 预热与压测： 使用生产流量回放或批量离线加载，观察 L2 命中率及 P99 延迟。压测指标需覆盖热点 Key 场景。
- 监控告警： 部署 Redis Exporter / Memcached Exporter + Prometheus，监控 latency、eviction rate、hit rate、内存使用率。关键告警项：内存 > 80%、命中率 < 80%、延迟 > 5ms。
- 故障演练： 模拟网络分区、Master 宕机、槽迁移，验证客户端自动切换及降级逻辑。
3.8 验收标准
| 验收指标 | 目标值 | 备注 |
|---|---|---|
| L2 命中率（剔除 L1 命中） | ≥ 90% | 长期运行统计，排除预热期 |
| P99 读延迟（同机房） | ≤ 5ms | 包含网络 + 序列化 |
| 集群吞吐量（3 Master + 3 Replica） | ≥ 50k QPS | 按业务模型混合 |
| 缓存雪崩防护 | 数据库瞬间流量不超过正常值的 2 倍 | TTL 随机化后模拟大量过期 |
| 故障转移耗时 | ≤ 10s | Redis Cluster 自动 failover |
| 数据最终一致性窗口 | ≤ 1s | 主从异步复制 + 客户端容忍 |