接下来两篇将记录Redis持久化存储两大技术：AOF日志、RDB快照
本篇重点
“AOF日志实现”
“AOF日志三种写回策略”
“AOF重写——避免日志过大的解决方案”
前言
Redis持久化存储两大技术：AOF日志、RDB快照
AOF: Append Only File
RDB: Redis DB
背景
Redis运行中，若突然宕机，存储在内存中的数据都会丢失。此时如果从后端数据库恢复数据，虽然可行，但也会导致效率问题：
- 频繁访问数据库增加数据库压力
- 慢速数据库读取导致Redis性能下降
因此，Redis实现数据持久化的方式，要避免从后端数据库中恢复数据，采用的方式就是AOF日志和RDB快照，本篇文章主要讨论AOF日志。
1. AOF日志实现
- 写后日志：先执行命令，数据写入内存；再记录日志
- 日志记录内容：Redis收到的每一条命令，记录格式如下：
-
"*+number"——当前命令有number个字段，后面内容是对应字段描述
-
"$+number"——表示当前字段占用的字节数，后面跟具体字段名称
-
例子：命令：
set testkey testvalue，写入AOF日志后的格式是*3 // 当前命令3个字段（分别是set testkey testvalue） $3 // 第一个字段占3B set // 第一个字段名：set $7 testkey $9 testvalue
-
- “写后日志”的原因
- Redis记录AOF日志时不会对命令进行语法检查（节省检查开销）
- 基于第一点，采用“写后日志”防止记录错误命令
- AOF日志在主线程中执行
- AOF不会阻塞当前写操作（先执行命令，后记录日志）
- AOF潜在风险：
- AOF存在阻塞下一个操作的风险（下个操作执行之前主线程写上一个操作的日志）
- 若Redis直接用作数据库，命令执行后系统宕机——AOF日志没记录导致数据丢失
以上的AOF潜在风险都与AOF日志写盘时间相关，解决方案——AOF三种写回策略
2. AOF日志三种写回策略——appendfsync参数的三个可选项
Always——同步写回：每个写命令执行后，同步写磁盘
Everysec——每秒写回：日志暂时写到AOF日志cache，每隔1s写盘
No——操作系统控制的写回：日志暂时写到AOF日志cache，由OS决定何时写盘
| 配置项 | 写回时机 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| Always | 同步写回 | 可靠性高 数据基本不丢失 |
每个写操作都伴随写盘，性能影响较大 | 高可靠性 |
| Everysec | 每秒写回 | 性能适中 | 宕机时丢失1s内数据 | 允许少量数据丢失，同时性能影响较小 |
| No | OS控制写回 | 性能好 | 宕机时丢失数据较多 | 高性能 |
QA
Q: AOF文件过大带来的一系列性能问题？如何控制AOF文件过大？
A: 性能问题
- 文件系统本身文件大小的限制
- 文件太大时，追加命令记录效率变低
- 宕机后，AOF文件中的命令挨个重新执行的导致的故障恢复过程缓慢
解决方案：AOF重写机制
3. AOF重写——避免AOF日志过大
- AOF重写：Redis根据数据库现状，创建一个新的AOF文件
- 操作：将当前Redis每个KV都用一条set命令写入AOF重写日志
- 原理：“多变一”——某个KV被多条命令反复修改
- AOF重写是否会阻塞主线程？AOF重写机制。
- AOF日志由主线程写盘
- AOF重写日志由后台子进程bgrewriteaof执行
- 重写过程——“一个拷贝，两处日志”
- “一个拷贝”：主线程fork bgrewriteaof子进程，通过拷贝页表（OS的“写时复制”原则）访问主线程的内存数据
- “两处日志”：写操作发生时，AOF日志与AOF重写均先将操作记录到各自日志cache中，随后fork bgrewriteaof子进程进程重写日志操作
- AOF非阻塞的重写过程
结尾
AOF故障恢复需要运行所有操作记录，即“重放”过程很慢，既能避免数据丢失，又能更快恢复数据的方法——“RDB快照”
图片来源于极客时间专栏《Redis核心技术与实战》