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文件
  • 原理:“多变一”——某个KV被多条命令反复修改
  • AOF重写是否会阻塞主线程?AOF重写机制。
    • AOF日志由主线程写盘
    • AOF重写日志由后台子进程bgrewriteaof执行
  • 重写过程——“一个拷贝,两处日志”
    • “一个拷贝”:主线程fork bgrewriteaof子进程,通过拷贝页表(OS的“写时复制”原则)访问主线程的内存数据
    • “两处日志”:写操作发生时,AOF日志与AOF重写均先将操作记录到各自日志cache中,随后fork bgrewriteaof子进程进程重写日志操作
  • AOF非阻塞的重写过程

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

结尾

AOF故障恢复需要运行所有操作记录,即“重放”过程很慢,既能避免数据丢失,又能更快恢复数据的方法——“RDB快照”

图片来源于极客时间专栏《Redis核心技术与实战》

上一篇:实操:httprunner中用validate断言


下一篇:Redis数据库(九)——Redis持久化AOF