登录/注册
Web前端之巅
2185
占位
2
占位
0
浏览量
占位
粉丝
占位
关注
04 AOF日志:宕机了,Redis如何避免数据丢失 -
Web前端之巅
2021-09-21 15:20:50 2021-09-21
77
0

接下来两篇将记录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非阻塞的重写过程

结尾

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

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

原文: https://www.cnblogs.com/GuoYuying/p/15064230.html

暂无评论