01.1 - Redis 设计哲学与适用场景
定位: 理解 Redis 的核心设计决策：为什么选择内存计算？为什么单线程？为什么丰富的数据结构？ 面试高频度: ⭐⭐⭐⭐ 考查方式: 架构对比、场景决策、问"为什么选 Redis 而不是 X？"
一、这是什么？为什么需要它？
是什么
Redis（Remote Dictionary Server）是一个基于内存的键值存储系统，被定位为数据结构服务器（Data Structure Server），而非简单的缓存。
为什么需要？
没有 Redis，人们面临的问题：
- 数据库磁盘 I/O 是瓶颈：每次读取要经历「磁盘寻道 → 旋转延迟 → 传输」毫秒级延迟
- 缓存层只有 Memcached：仅支持 String 类型，无法在服务端操作结构
- 自建缓存没有持久化：宕机后冷启动，数据库被打爆
- 缺少分布式协调的原语：分布式锁、计数器、排行榜要用 DB 或 ZK 实现
Redis 的解决思路：
定位
Redis 不做替代数据库的角色，而是做加速和补充——它是应用架构中的"高速公路"。
二、原理拆解
2.1 为什么设计为单线程？
设计动机：简化并发模型、极致性能
多线程方案（Memcached 6.x 以前）的代价：
Redis 的决策：既然瓶颈是内存/网络而非 CPU，用单线程换取：
- 无锁数据访问 —— 所有操作串行执行
- 可预测延迟 —— 不会因为锁等待发生 jitter
- 实现简单 —— 不需要复杂的并发控制
2.2 Redis 与数据库的定位差异
| 维度 | Redis | 传统数据库 | 说明 |
|---|---|---|---|
| 存储介质 | 内存（全量/热数据） | 磁盘（主存） | 速度差：ns vs ms |
| 数据模型 | Key-Value + 结构 | 关系型表/文档 | Redis 的操作就是数据结构操作 |
| 持久化 | 附加功能（RDB/AOF） | 核心功能 | Redis 不是为 ACID 设计的 |
| 查询能力 | 基于 Key + 结构操作 | SQL 复杂查询 | 各司其职 |
| 一致性 | 最终一致（主从） | 强一致（多数派） | Redis 为性能放弃严格一致性 |
2.3 适用场景决策树
三、图解全景：Redis vs 其他存储
| 维度 | Redis | SQL DB | 缓存 |
|---|---|---|---|
| 延迟 | ~100μs | ~10ms | ~1ms |
| QPS | 10万+ | 1万- | 5万-10万 |
| 数据结构 | 丰富 | 表结构 | 简单KV |
| 持久化 | 可选 | 必须 | 无 |
| 功能 | 数据结构服务器 | 关系数据管理 | 纯缓存 |
四、实战验证
4.1 Redis vs 数据库延迟对比
bash
# 1️⃣ Redis benchmark
redis-benchmark -n 100000 -q
# 输出示例：
# SET: 120000 requests/sec (约 8.3μs/op)
# GET: 125000 requests/sec (约 8.0μs/op)
# 2️⃣ 对比：MySQL 简单查询
# 在 MySQL 中执行 10 万次简单查询：
# 约 2000-5000 QPS（取决于数据量和索引）4.2 查看 Redis 运行时状态
bash
# 连接到 Redis 并查看服务器信息
redis-cli
127.0.0.1:6379> INFO server
# Server
redis_version:7.2.0
uptime_in_seconds:3600
127.0.0.1:6379> INFO stats
total_connections_received:100
total_commands_processed:500000
instantaneous_ops_per_sec:120000 # 当前 OPS4.3 内存与数据量估算
bash
# 生产上监控内存使用
127.0.0.1:6379> INFO memory
# Memory
used_memory_human:1.5G
used_memory_rss_human:2.1G
maxmemory_human:4G
# 查看 key 数量
127.0.0.1:6379> DBSIZE
(integer) 2500000五、面试视角
| 追问 | 答案要点 |
|---|---|
| Redis 为什么是单线程？ | 瓶颈在内存/网络不在 CPU；单线程避免锁、上下文切换、缓存行失效；6.0 网络 I/O 多线程但命令执行仍是单线程 |
| 单线程能处理那么多请求吗？ | 核心是 I/O 多路复用（epoll/epoll_wait），把等待 I/O 的时间用来处理已就绪的请求 |
| Redis 和 Memcached 的区别？ | 数据结构丰富度、持久化、高可用（Sentinel/Cluster）、单线程 vs 多线程、内存淘汰策略 |
| 什么场景不适合 Redis？ | 数据量远大于内存、需要复杂 SQL 查询、需要强一致性事务、需要存储大 blob |
| Redis 的"快"到底有多快？ | 单机 ~10万 QPS（GET/SET），pipeline 可达百万级，延迟 ~100μs 级别 |
| Redis 保证了强一致吗？ | 否，主从异步复制可能丢数据；Cluster 提供最终一致性；需要强一致用 ZooKeeper/etcd |
📚 相关链接
- **单线程与I/O多路复用详解** — 为什么单线程能满足高并发
- **RESP协议** — 通信层面的优化
- **数据结构概览** — 丰富结构的实现基础
- ← 返回 **Redis基础与架构索引**