本文写于 2018 年 6 月——Redis 4.0 主线、Redis 5.0（Stream 类型）2018-10 发布前夜。

一、8 大数据类型应用场景

1.1 选型决策

graph TD
    A[需要存什么?] --> B{单个值?}
    B -->|是| C[String / BitMap / HyperLogLog]
    B -->|否| D{有序?}
    D -->|是| E[ZSet / List / Stream]
    D -->|否| F{唯一?}
    F -->|是| G[Set]
    F -->|否| H[Hash / List]

二、Redis 线程模型

2.1 单线程 vs 多线程

Redis 单线程指的是「接收客户端请求 → 解析请求 → 进行数据读写等操作 → 发送数据给客户端」这个过程是由一个线程（主线程）来完成的，这也是我们常说 Redis 是单线程的原因。

但是，Redis 程序并不是单线程的，Redis 在启动的时候是会启动后台线程（BIO）的：

• Redis 在 2.6 版本，会启动 2 个后台线程，分别处理关闭文件、AOF 刷盘这两个任务
• Redis 在 4.0 版本之后，新增了一个新的后台线程，用来异步释放 Redis 内存，也就是 lazyfree 线程

2.2 Redis 6.0 引入多线程 I/O

虽然 Redis 的主要工作（网络 I/O 和执行命令）一直是单线程模型，但是 在 Redis 6.0 版本之后，也采用了多个 I/O 线程来处理网络请求，这是因为随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 I/O 的处理上。

所以为了提高网络 I/O 的并行度，Redis 6.0 对于网络 I/O 采用多线程来处理。但是对于命令的执行，Redis 仍然使用单线程来处理。 所以大家不要误解 Redis 有多线程同时执行命令。

Redis 官方表示，Redis 6.0 版本引入的多线程 I/O 特性对性能提升至少是一倍以上。

2.3 6.0 线程数配置

1
2
3
4
5

// 读请求也使用 io 多线程
io-threads-do-reads yes

// io-threads N，表示启用 N-1 个 I/O 线程（主线程也算一个 I/O 线程）
io-threads 4

官方的建议是如果为 4 核的 CPU，建议线程数设置为 2 或 3，如果为 8 核 CPU 建议线程数设置为 6，线程数一定要小于机器核数，线程数并不是越大越好。

2.4 Redis 启动后的线程组成

因此， Redis 6.0 版本之后，Redis 在启动的时候，默认情况下会 额外创建 6 个线程 （这里的线程数不包括主线程 ）：

• Redis-server：Redis 的主线程，主要负责执行命令
• bio_close_file、bio_aof_fsync、bio_lazy_free：三个后台线程，分别异步处理关闭文件任务、AOF 刷盘任务、释放内存任务
• io_thd_1、io_thd_2、io_thd_3：三个 I/O 线程，io-threads 默认是 4，所以会启动 3（4-1）个 I/O 多线程，用来分担 Redis 网络 I/O 的压力

三、Redis 为什么这么快

3.1 4 大核心原因

Redis 快的核心原因，可以用一句话概括：它干的活极其简单，而且它把单线程的优势发挥到了极致，同时通过操作系统底层的"高级外挂"解决了高并发的排队问题。

原因 1：绝大多数请求是纯内存操作

这是最根本的基础。Redis 的所有数据都存储在内存中，CPU 读写内存的速度（纳秒级别）比起读写机械硬盘或 SSD（微秒甚至毫秒级别）快了数万倍。

原因 2：避免了多线程的"内耗"

多线程虽然能并发，但也带来了高昂的代价。Redis 采用单线程，反而完美避开了这些性能杀手：

• 没有线程切换的开销：操作系统在切换线程时，需要保存当前线程的上下文并加载新线程的数据。单线程一个人干到底，零切换成本
• 没有锁的竞争：多线程访问共享资源必须加锁，加锁、解锁以及等待锁的操作非常重。Redis 单线程天然保证了所有操作都是原子性的，根本不需要锁

原因 3：I/O 多路复用技术（底层外挂）

“单线程"指的是 Redis 核心的网络事件处理器和键值对读写命令 是由一个线程串行执行的。但面对海量的客户端连接，单线程怎么可能忙得过来？

这就是 I/O 多路复用（I/O Multiplexing） 大显身手的地方。Redis 利用了操作系统底层的非阻塞 I/O 机制（在 Linux 上通常是 epoll）。

epoll 工作原理：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

┌─────────────────────────────────────────┐
│  Redis 主线程                            │
│  ┌──────────────────┐                  │
│  │ epoll_wait()      │ ← 阻塞等事件      │
│  └──────────────────┘                  │
│  ↓ 有事件发生                            │
│  遍历 fd_list，处理每个就绪 fd            │
│  ├─ Client 1: read()                    │
│  ├─ Client 5: read()                    │
│  └─ Client 100: read()                  │
│  ↓ 业务逻辑                              │
│  执行 Redis 命令（单线程原子）              │
│  ↓ 写回响应                              │
│  write() → 多线程异步                     │
└─────────────────────────────────────────┘

epoll 优势：

• select：O(n) 遍历所有 fd
• poll：O(n) 遍历所有 fd
• epoll：O(1) 事件通知（内核维护就绪链表）

原因 4：精心优化的数据结构

四、内存淘汰策略

4.1 8 大策略

4.2 选型建议

• 缓存场景（容忍丢失）：allkeys-lru / allkeys-lfu
• 数据不能丢：noeviction + 监控告警
• 混合场景：volatile-lru（仅淘汰过期 key）

五、持久化机制

5.1 三大方式

5.2 RDB 触发

1
2
3
4
5
6
7
8

# 自动触发（save 命令）
save 900 1        # 900 秒内至少 1 个 key 变更
save 300 10       # 300 秒内至少 10 个 key 变更
save 60 10000     # 60 秒内至少 10000 个 key 变更

# 手动触发
bgsave  # 后台异步保存
save    # 同步保存（阻塞主线程）

5.3 AOF 三种策略

1
2
3
4

# appendfsync 策略
appendfsync always    # 每次写入同步刷盘（最安全，最慢）
appendfsync everysec  # 每秒刷盘（默认，推荐）
appendfsync no        # 操作系统决定（最快，最不安全）

六、Redis 集群方案

七、Redis 经典问题

7.1 缓存雪崩

现象：大量 key 同时过期，请求打到数据库。

解决方案：

• 过期时间加随机值：expire = base + random(0, 300)
• 熔断降级：数据库压力过大时直接拒绝部分请求
• 缓存预热：系统启动时把热点数据加载到缓存

7.2 缓存穿透

现象：查询不存在的 key，每次都打到数据库。

解决方案：

• 空值缓存：key -> null（短 TTL）
• 布隆过滤器：先过布隆过滤器
• 接口校验：参数合法性检查

7.3 缓存击穿

现象：热点 key 突然过期，瞬间大量请求打到数据库。

解决方案：

• 分布式锁：第一个请求查 DB，后续请求等
• 永不过期：逻辑过期（不设 TTL，值带过期时间字段）
• 熔断降级：直接返回旧值

7.4 数据不一致

现象：数据库和缓存数据不一致。

解决方案：

• 先更新 DB，再删除缓存（Cache-Aside Pattern）
• 延迟双删：更新 DB → 删除缓存 → 异步延迟再删
• binlog 订阅：监听 binlog 异步更新缓存
• 设置较短 TTL：最终一致性兜底

八、写在最后

Redis 面试要点：

1. 基础：8 大数据类型 + 选型
2. 线程模型：单线程 vs 多线程 I/O、I/O 多路复用
3. 快的原因：内存操作 + 无锁 + epoll + 优化数据结构
4. 持久化：RDB / AOF / 混合
5. 集群：主从 / Sentinel / Cluster
6. 经典问题：雪崩 / 穿透 / 击穿 / 一致性

参考资料

• Redis 官方文档
• Redis 设计与实现
• Redis 源码
• Redis 6.0 多线程 I/O 解析