Redis进阶 | 05.持久化-RDB和AOF

参考文章

Redis的两种持久化RDB和AOF（超详细）

1.RDB - folk进程写入快照

在达成一定条件时，就触发bgsave指令，folk子进程来异步地将某一时刻的数据快照（dump.rdb）写入磁盘中。

默认配置及其释义

若 m 秒之后有 n 个key发生变化，就触发BGSAVE创建快照。

save 900 1 					# 900秒（15分钟）之后若有1个key发生变化，就触发BGSAVE指令创建快照
save 300 10 				# 300秒（5分钟）之后有10个key发生变化，就触发BGSAVE指令创建快照
save 60 10000 				# 60秒（1分钟）之后有10000个key发生变化，就触发BGSAVE指令创建快照

rdb文件生成方式 - 写时复制机制

在将数据写入到文件时，创建与主进程一模一样的子进程，通过子进程异步地将数据写入到文件当中。

• Redis通过folk( )创建一个数据完全一致的子进程；
• 子进程将数据写入到临时文件中；
• 使用临时文件替换dump.rdb。

问：为什么不直接在主进程将数据写入到dump.rdb

答：若写入时主进程崩溃，dump.rdb便会损坏，所有数据将会丢失。

RDB持久化的优缺点

• 优点：数据量较大时，RDB的恢复速度更快；

• 缺点：主要有以下两点

  – RDB无法做到秒级持久化，且每次bgsave都要folk( )子进程来执行，非常笨重；

  – RDB的持久化策略是一定时间后有一定数量的key发生变化才会持久化，因此如果挂掉，若数据尚未被持久化，就会丢失。

2.AOF - 追加指令到xxx.aof文件中

在缓冲区记录每一条对key修改的指令，并在一定的规则下（如：经过1s以后），将缓冲区命令追加到xxx.aof文件中。

配置及其释义

通常开启everysec，每秒一次将缓冲区中的指令追加到xxx.aof文件中

appendfsync always				# 每当数据修改，都执行AOF，严重降低Redis速度
appendfsync everysec			# 每秒执行一次AOF
appendfsync no				    # 让操作系统手动AOF

AOF重写 - 写时复制机制

重写的时机通常有以下两个：

• 高可用：从库加载完主库的RDB文件后（前提是AOF被启动）
• AOF体积过大。

而AOF的重写，也用到了写时复制技术（folk( )子进程来写入数据），具体如下：

1. 主进程触发folk( )生成一个子进程；
2. 子进程将数据写入到新的aof文件中，期间新的指令将暂存在缓冲区中；
3. 待子进程数据写入完毕，缓冲区数据追加到新的aof文件末尾。