Redis 核心知识精讲：从基础到实战要点

在分布式系统和高并发场景中，Redis 凭借高性能、丰富功能成为必备中间件。本文整理 Redis 核心知识点，涵盖数据结构、持久化、高可用、缓存策略等关键内容，帮你快速掌握 Redis 核心能力。

一、Redis 核心特性：为何成为主流？

Redis（Remote Dictionary Server）是开源的内存数据库，核心特性决定其优势：

1. 高性能：基于内存操作，单节点读 QPS 可达 10 万 +，写 QPS 约 5 万 +，远超传统数据库；
2. 多数据结构：支持 String、Hash、List、Set、Sorted Set 等，满足复杂业务场景；
3. 持久化：通过 RDB 和 AOF 机制，避免内存数据丢失；
4. 单线程：通过单线程进行命令的操作，避免了多线程之间的竞争锁、切换等操作影响性能。

二、必掌握的 5 种核心数据结构及应用场景

Redis 数据结构是其核心竞争力，不同结构对应不同业务场景，需牢记 “结构特性 + 典型用法”：

五种类型数据内部实现方式：

Redis 五种核心类型（String、List、Hash、Set、Sorted Set）的高效性，源于底层根据数据规模和操作场景动态选择的优化结构，以下是每种类型的核心实现逻辑：

1. String（字符串）

• 核心结构：简单动态字符串（SDS，Simple Dynamic String），替代 C 语言原生字符串；

• 结构选择：无场景区分，所有 String 类型均基于 SDS 实现；

• 关键特点：SDS 记录字符串长度（避免 O (n) 计算长度）、预分配空间（减少扩容开销）、二进制安全（支持存储图片 / 视频等二进制数据），例如存储 "user:100:name" 的值时，直接用 SDS 存储字符串内容。

2. List（列表）

• 核心结构：双向链表（LinkedList）+ 压缩列表（ZipList）；

• 结构选择：

• • 当列表元素数量≤512 且每个元素长度≤64 字节时，用压缩列表（节省内存，连续内存存储，减少指针开销）；

• • 超过上述阈值时，自动转为双向链表（支持高效插入 / 删除，时间复杂度 O (1)，适合大量数据场景）；

• 典型场景：用双向链表实现消息队列（LPUSH/RPOP），用压缩列表存储少量短消息。

3. Hash（哈希）

• 核心结构：压缩列表（ZipList）+ 哈希表（HashTable）；

• 结构选择：

• • 当哈希表元素数量≤512 且每个键值对长度≤64 字节时，用压缩列表（键值对连续存储，内存紧凑）；

• • 超过上述阈值时，转为哈希表（数组 + 链表解决哈希冲突，支持 O (1) 查找，适合大量键值对场景）；

• 典型场景：存储用户信息（user:100 → {name: "张三", age: 20}），少量字段用压缩列表，大量字段用哈希表。

4. Set（集合）

• 核心结构：整数集合（IntSet）+ 哈希表（HashTable）；

• 结构选择：

• • 当集合中所有元素都是整数且数量≤512 时，用整数集合（连续内存存储整数，比哈希表更节省空间）；

• • 不满足上述条件（如包含字符串元素或数量超阈值）时，用哈希表（键存元素值，值存 NULL，利用哈希表唯一性特性，支持 O (1) 判断元素是否存在）；

• 典型场景：存储用户标签（tags:100 → {篮球，音乐}），全整数标签用整数集合，含字符串标签用哈希表。

5. Sorted Set（有序集合）

• 核心结构：压缩列表（ZipList）+ 跳跃表（SkipList）+ 哈希表（HashTable）；

• 结构选择：

• • 当元素数量≤128 且每个元素长度≤64 字节时，用压缩列表（按分数排序存储键值对，节省内存）；

• • 超过上述阈值时，用跳跃表 + 哈希表（跳跃表按分数排序，支持 O (logn) 增删查和范围查询；哈希表存 "元素→分数" 映射，支持 O (1) 获取分数）；

• 典型场景：排行榜（score:article → {1001: 1000 阅读量，1002: 800 阅读量}），少量数据用压缩列表，大量数据用跳跃表 + 哈希表。

三、持久化机制：避免内存数据丢失

Redis 是内存数据库，断电或重启会丢失数据，持久化是保障数据安全的关键，核心有两种方案：

1. RDB（Redis Database）：快照持久化

• 原理：在指定时间间隔内，将内存中 “全量数据” 快照写入磁盘（生成.rdb 文件），恢复时直接加载该文件到内存。

• 触发方式：

• • 配置触发：save 900 1（900 秒内 1 次修改）、save 300 10（300 秒内 10 次修改）；

• • 手动触发：执行SAVE（阻塞 Redis，不推荐）或BGSAVE（fork 子进程执行，主进程不阻塞）。

• 优缺点：

• • 优点：文件小、恢复速度快，适合备份（如每天凌晨备份）；

• • 缺点：可能丢失 “最后一次快照到故障” 期间的数据（如配置save 300 10，若 300 秒内修改 10 次后，10 秒后故障，这 10 秒数据丢失）。

2. AOF（Append Only File）：日志持久化

• 原理：记录每一条 “写操作命令”（如 SET、HSET）到.aof 文件，恢复时重新执行文件中的命令，重建数据。

• 刷盘策略（配置appendfsync）：

• • always：每执行 1 条命令刷盘，数据零丢失，但性能差；

• • everysec：每秒刷盘 1 次，最多丢失 1 秒数据，性能与安全平衡（推荐）；

• • no：由操作系统决定刷盘时机，性能好但数据丢失风险高。

• 优缺点：

• • 优点：数据丢失少（最多 1 秒），日志文件易读懂；

• • 缺点：文件体积大（如频繁 SET 同一 key，日志会存大量重复命令），恢复速度慢（需重新执行所有命令）。

2.1 AOF重写

它通过压缩冗余命令、合并重复操作，生成一个更精简的 AOF 文件，同时保持数据最终状态一致。

自动触发

通过配置文件 redis.conf 中的参数自动触发# 当 AOF 文件体积比上次重写后的体积增长了指定百分比时触发

auto-aof-rewrite-percentage 100 # 增长100%（即翻倍）时触发

# 当 AOF 文件体积达到指定大小时才可能触发（避免小文件频繁重写）

auto-aof-rewrite-min-size 64mb # 最小64MB才可能触发

手动触发

通过 BGREWRITEAOF 命令异步执行重写127.0.0.1:6379> BGREWRITEAOF

Background append only file rewriting started bgrewriteaof

执行后，Redis 会 fork 一个子进程负责重写，主进程继续处理客户端命令（保证服务不中断）。

主进程会将重写期间收到的新命令同时写入原 AOF 文件和重写缓冲区，确保数据不丢失。

子进程完成重写后，主进程会将缓冲区中的命令追加到新 AOF 文件，然后原子性地替换原 AOF 文件，完成重写。

原理

AOF 重写不是对原有 AOF 文件进行修改，而是直接读取当前内存中的数据状态，生成一系列创建该状态的最小命令集，写入一个新的 AOF 文件。

3. 实际选择：RDB+AOF 混合持久化

Redis 4.0 + 支持混合模式，AOF 文件头部存储 RDB 快照，尾部存储 AOF 日志：

• 恢复时：先加载 RDB 快照（快速），再执行 AOF 尾部命令（补全快照后的增量数据）；

• 优势：兼顾 RDB 的 “恢复快” 和 AOF 的 “数据安全”，是生产环境首选。

四、实战避坑：这些问题要注意

1.缓存穿透：

• 问题：查询 “不存在的数据”（如用户 id=-1），缓存和数据库都不命中，请求全打数据库，导致数据库压力过大；
• 解决：不存在的 key 也缓存（如缓存-1:null，设置短期过期时间）、使用布隆过滤器（提前过滤不存在的 key）。

2.缓存击穿：

• 问题：热点 key（如热门商品 id=100）过期瞬间，大量请求同时打数据库；
• 解决：热点 key 设置 “永不过期”、加互斥锁（如 Redis 的 SET NX，只有 1 个请求能查数据库并更新缓存）。

3.缓存雪崩：

• 问题：大量缓存 key 同时过期，或 Redis 集群故障，请求全打数据库，导致数据库崩溃；
• 解决：key 过期时间加随机值（避免同时过期）、部署 Redis Cluster（避免集群故障）、服务降级（故障时返回默认数据）。

六、总结

Redis 的核心价值在于 “高性能 + 多功能”，掌握以下要点即可应对大部分场景：

1. 数据结构：根据业务场景选对类型（如排行榜用 Sorted Set）；
2. 持久化：生产环境用 RDB+AOF 混合模式，平衡安全与性能；
3. 避坑：提前预防缓存穿透、击穿、雪崩问题。