---
title: Redis 设计 12 大维度
type: system
domain: redis
tags: [redis, design, architecture, trade-off, capacity-planning]
status: learning
created: 2026-09-20
last_reviewed: 2026-09-20
method: c4
related_questions:
  - "如果设计一个缓存，需要考虑哪些方面？"
related_knowledge:
  - ./redis-single-thread.md
  - ./cache-three-failures.md
  - ./cache-consistency.md
  - ./redis-expiration-eviction.md
visualizations: []
anki_cards: 4
interview_rounds:
  - "2026-09-20-round-1-Q10"
---

# Redis 设计 12 大维度

> 设计缓存要覆盖 12 个维度，每个都要给**量化目标 + trade-off**，只列名词不够。

## TL;DR（30 秒扫完）

- **12 大维度**：性能 / 数据结构 / 淘汰过期 / 持久化 / 高可用 / 扩展 / 一致性 / 并发 / 网络 / 安全 / 监控 / 业务集成
- **每个维度必给量化目标**：QPS 10w / P99 < 5ms / 可用性 99.99% / RPO 1min
- **每个维度必讲 trade-off**：如 RDB 快但丢数据，AOF 安全但写慢
- **演进路径**：先单机+主从 → Cluster → + 本地缓存

## 关键结论

- **结论 A**：设计题核心是**量化目标 + trade-off**，只列名词 = 2/5 分
- **结论 B**：12 维度按 6 层组织（性能存储 / 可靠性扩展 / 一致性并发 / 网络安全 / 可观测性 / 业务集成）
- **结论 C**：演进路径很重要——不要一上来就上 Cluster，先单机+主从验证
- **结论 D**：监控是最后一道防线——没有告警的缓存等于没有缓存

## 完整讲解（费曼四步）

### STEP 1 · 概念

**Redis 设计 12 大维度**：设计一个缓存系统时需要考虑的 12 个关键维度，每个维度都要给出**量化目标**和**trade-off 分析**。

### STEP 2 · 大白话

**装修房子比喻**：
设计缓存就像装修房子，不能只说"要好看、要结实、要省电"，必须说清楚：
- 好看 → P99 延迟 < 5ms
- 结实 → 可用性 99.99%
- 省电 → 内存占用 ≤ 32GB
- 还要考虑：电路（网络）、锁（安全）、报警器（监控）、邻居（业务集成）

### STEP 3 · 底层

#### 12 大维度框架（6 层组织）

**第一层：性能与存储**

| 维度 | 量化目标 | trade-off |
|------|---------|-----------|
| ① **性能模型** | QPS 10w / P99 < 5ms / 内存 ≤ 32GB | 先定目标再用 `redis-benchmark` 建基准 |
| ② **数据结构** | String/Hash/List/Set/ZSet | 小数据用 listpack 紧凑，大数据自动升级 |
| ③ **淘汰与过期** | allkeys-lru 或 allkeys-lfu；TTL 加随机抖动 | LRU 防热点被挤走，LFU 防新数据挤走热点 |

**第二层：可靠性与扩展**

| 维度 | 量化目标 | trade-off |
|------|---------|-----------|
| ④ **持久化** | RPO 1min / RTO 30s | RDB 快但丢 15min，AOF everysec 安全但写慢，混合最佳 |
| ⑤ **高可用** | 可用性 99.99% | 主从+Sentinel 自动故障转移，脑裂防护 `min-replicas-to-write` |
| ⑥ **扩展** | 16384 哈希槽 | 在线重平衡迁 slot；平滑扩容先加节点再迁数据 |

**第三层：一致性与并发**

| 维度 | 量化目标 | trade-off |
|------|---------|-----------|
| ⑦ **一致性** | 最终一致 | Redis 是 AP 系统，牺牲一致性保可用；读已写 vs 读多数 |
| ⑧ **并发** | 命令原子性 | 单线程保证命令原子；Lua 脚本批量原子；MULTI 慎用 |

**第四层：网络与安全**

| 维度 | 量化目标 | trade-off |
|------|---------|-----------|
| ⑨ **网络** | epoll + RESP 协议 | 连接复用（Lettuce Netty）；Pipeline 批量减少 RTT |
| ⑩ **安全** | ACL + TLS | 6.0+ 细粒度权限；内网隔离 + 防火墙白名单 |

**第五层：可观测性**

| 维度 | 量化目标 | trade-off |
|------|---------|-----------|
| ⑪ **监控** | QPS/延迟/内存/evicted_keys | SLOWLOG（默认 10ms）；Prometheus + Grafana 告警 |

**第六层：业务集成**

| 维度 | 量化目标 | trade-off |
|------|---------|-----------|
| ⑫ **业务集成** | 穿透/击穿/雪崩防御 | 布隆过滤器 + 互斥锁 + TTL 抖动；多级缓存 + Canal + TTL 兜底 |

#### 容量规划（关键量化）

```
缓存容量 = 热点数据量 × 单条大小 × 副本数 × 安全系数（1.5-2）

例：
- 热点商品 10w 条 × 2KB/条 × 3 副本 × 1.5 = 900MB
- 加 20% 余量 → 申请 1GB 内存
```

**采样验证**：`MEMORY USAGE` 抽样 1000 个 key 看平均大小

#### 演进路径

| 阶段 | 架构 | 适用场景 |
|------|------|---------|
| 1 | 单机 + 持久化 | 验证阶段，QPS < 1w |
| 2 | 主从 + Sentinel | 生产入门，QPS < 10w |
| 3 | Cluster 分片 | 大数据量，QPS > 10w |
| 4 | + 本地缓存（Caffeine） | 极致性能，热点数据 |
| 5 | + 多级缓存 + Canal | 强一致需求 |

**原则**：不要一上来就上 Cluster，先单机+主从验证业务模型。

#### 工程实践清单

**必做**：
- 容量规划（避免大促 OOM）
- SLOWLOG 监控（默认 10ms 阈值）
- evicted_keys 告警
- 脑裂防护配置
- 灰度发布 + 回滚预案

**推荐**：
- `redis-benchmark` 压测建基准
- 慢命令审计（`INFO commandstats`）
- 大 key 扫描（`--bigkeys`）
- 蓝绿部署

**选做**：
- 可视化（RedisInsight / Grafana）
- 自动扩缩容
- 混沌工程（故意宕机测试）

#### 常见坑

| 坑 | 后果 | 解决 |
|----|------|------|
| 没做容量规划 | 大促 OOM | 提前压测 + 容量告警 |
| 没设淘汰策略 | 写失败返回错误 | 显式配置 allkeys-lru |
| 用 KEYS 命令 | 阻塞主线程 | 改用 SCAN |
| 大 key DEL | 卡住主线程 | 改用 UNLINK 异步删除 |
| 没配 SLOWLOG | 不知道谁卡住 | 默认 10ms 阈值 |
| 没做脑裂防护 | 数据双写 | `min-replicas-to-write` |

### STEP 4 · 简化

**一句话总结**：设计缓存 = 12 维度 × (量化目标 + trade-off)。先单机验证，再 Cluster 扩展，监控是最后防线。

**记忆口诀**：
- 6 层组织：性能存储 / 可靠性扩展 / 一致性并发 / 网络安全 / 可观测性 / 业务集成
- 12 维度：性能/结构/淘汰/持久/高可用/扩展/一致性/并发/网络/安全/监控/业务
- 每个维度：量化目标 + trade-off
- 演进：单机 → 主从 → Cluster → + 本地缓存 → + Canal
- 必做：容量规划 + SLOWLOG + evicted_keys 告警 + 脑裂防护

## 常见误区

- **误区 1**：只列名词不给数字 → 2/5 分。设计题核心是量化目标 + trade-off
- **误区 2**：一上来就上 Cluster → 先单机+主从验证业务模型
- **误区 3**：忽略监控 → 没有告警的缓存等于没有缓存
- **误区 4**：忽略容量规划 → 大促 OOM 是常见坑
- **误区 5**：用 KEYS 命令 → 阻塞主线程，必须用 SCAN

## 延伸追问

1. **如何估算缓存容量？**
   - 热点数据量 × 单条大小 × 副本数 × 安全系数（1.5-2）；`MEMORY USAGE` 抽样
2. **一致性哈希如何解决数据倾斜？**
   - 虚拟节点（每物理节点 100-150 个虚拟节点）、MD5 散列均匀
3. **Redis Cluster 的脑裂如何防护？**
   - `min-replicas-to-write` + 多数派仲裁 + 老主库下线验证
4. **Redis 如何做蓝绿部署？**
   - 新版本部署 → 双写或同步旧数据 → 灰度切流 → 全量切换 → 回滚预案
5. **如何设计一个支持强一致缓存？**
   - Raft 协议（etcd 思路）+ 多副本同步 + 写多数；或业务层加锁
6. **缓存如何优雅降级？**
   - 熔断打开 → 走 DB（限流）→ 静态兜底数据 → 前端提示
7. **多级缓存的一致性如何解决？**
   - Cache-Aside + 发布订阅 + 本地缓存 TTL 极短 + 容忍短暂不一致
8. **Redis 6.0 的 io-threads 怎么调？**
   - 根据 CPU 核数，一般 2-4，不超过 4

## 速查表

```
12 维度: 性能/结构/淘汰/持久/高可用/扩展/一致性/并发/网络/安全/监控/业务
6 层: 性能存储 / 可靠性扩展 / 一致性并发 / 网络安全 / 可观测性 / 业务集成
量化: QPS 10w / P99 < 5ms / 内存 32GB / 可用性 99.99% / RPO 1min
演进: 单机 → 主从+Sentinel → Cluster → +本地缓存 → +Canal
必做: 容量规划 + SLOWLOG + evicted_keys 告警 + 脑裂防护
坑: KEYS→SCAN / 大DEL→UNLINK / 没容量规划→OOM
```

## 关联题目（题库）

- 《如果设计一个缓存，需要考虑哪些方面？》— 2026-09-20 Round 1 Q10, ⭐⭐（只答 4 维度，缺量化思维和结构化）

## 关联知识

- [Redis 为什么快 + 为什么单线程](./redis-single-thread.md)
- [缓存三失效（穿透/击穿/雪崩）](./cache-three-failures.md)
- [缓存一致性](./cache-consistency.md)
- [Redis 过期与淘汰策略](./redis-expiration-eviction.md)

## Anki 候选卡片

1. **正**：设计缓存的 12 大维度？**反**：性能/数据结构/淘汰过期/持久化/高可用/扩展/一致性/并发/网络/安全/监控/业务集成
2. **正**：缓存容量如何估算？**反**：热点数据量 × 单条大小 × 副本数 × 安全系数（1.5-2）
3. **正**：Redis 设计的演进路径？**反**：单机 → 主从+Sentinel → Cluster → +本地缓存 → +Canal
4. **正**：设计缓存必做的 4 件事？**反**：容量规划 + SLOWLOG 监控 + evicted_keys 告警 + 脑裂防护

---

*最后更新：2026-09-20*