04 AOF日志：宕机了，Redis如何避免数据丢失

接下来两篇将记录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核心技术与实战》