接下来两篇将记录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文件
- 原理:“多变一”——某个KV被多条命令反复修改
- AOF重写是否会阻塞主线程?AOF重写机制。
- AOF日志由主线程写盘
- AOF重写日志由后台子进程bgrewriteaof执行
- 重写过程——“一个拷贝,两处日志”
- “一个拷贝”:主线程fork bgrewriteaof子进程,通过拷贝页表(OS的“写时复制”原则)访问主线程的内存数据
- “两处日志”:写操作发生时,AOF日志与AOF重写均先将操作记录到各自日志cache中,随后fork bgrewriteaof子进程进程重写日志操作
- AOF非阻塞的重写过程
结尾
AOF故障恢复需要运行所有操作记录,即“重放”过程很慢,既能避免数据丢失,又能更快恢复数据的方法——“RDB快照”
图片来源于极客时间专栏《Redis核心技术与实战》