Redis持久化

2.rdb性能高，aof性能低

1Redis默认情况下不开启AOF2Redis 将所有对数据库进行过写入的命令（及其参数）（RESP）记录到 AOF 文件， 以此达到记录数据库状态的目的3当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了。4AOF会记录过程，RDB只管结果

AOF基本说明

5.aof写入文件时过期的key会生成一条del语句，当触发重写时会忽略过期的key和del命令

AOF_FSYNC_ALWAYS ：每执行一个命令保存一次

参数配置

RDB执行流程(原理)

子进程

1 save \"\"  #不使用RDB存储，  不能进行主从复制2 save 900 1 #表示15分钟 内至少1个键更改则进行快照3 save 300 10 #表示5分钟 内至少10个键更改则进行快照4 60 10000 #表示1分钟内  至少10000个键更改则进行快照

RDB

Redis持久化

由于aof文件会越写越大，所以需要有重写机制触发，重新定义文件，缩小文件大小

（4）

在这种模式下， 每隔一秒钟，就会执行一次save操作，因为此操作是fork子进程，所以不会引起主进程阻塞（推荐使用）（最多丢失1-2秒钟数据）

保存aof文件/落磁盘

文件写入wirte

always配置

有其他子进程正在执行，直接返回

生成临时aof文件

(1)

RDB基本说明

完成后替代现有的aof文件

3执行flushall命令

1. Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof（aof文件重写命令）的子进程，如果在执行则bgsave命令直接返回。2. 父进程执行fork（调用OS函数复制主进程）操作创建子进程，这个复制过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令。3. 父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令。4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换。RDB始终完整）5. 子进程发送信号给父进程表示完成，父进程更新统计信息。6. 父进程fork子进程后，继续工作。

优点

生成RDB文件

AOF

不保证数据完整性，会丢失最后一次快照以后更改的所有数据

对比

fork

Fork

4 执行主从复制操作 (第一次)

2执行save或者bgsave命令

everySecend配置

redis服务器

重写说明

aof重新缓冲区

4.rdb在主从模式时，主服务器上不会保存过期的key-value，从服务器时会保存过去的key-value，当主从服务器同步后，在删除过期的key

（2）

或者no的配置

父进程

AOF持久化配置

AOF重写机制

触发快照的方式

重写流程

（3）

信号通知父进程

（5）

AOF_FSYNC_EVERYSEC ：每一秒钟保存一次

save

如果配置是 everySecond的话，需要fork子进程进行保存配置

RDB和AOF对比

1RDB是二进制压缩文件，占用空间小，便于传输（传给slaver）2主进程fork子进程，可以最大化Redis性能，主进程不能太大，Redis的数据量不能太大，复制过程中主进程阻塞

aof缓冲区

内存

将重写时产生的数据写入到重写缓冲区

命令传播

相应其他命令

RDB是redis默认的存储方式，RDB是通过快照 (snapshotting)实现的

在这种模式下， 每次调用 flushAppendOnlyFile 函数， WRITE 都会被执行， 但 SAVE 会被略过。只有在 redis被关闭，aof被关闭，系统的写缓存被刷新。这几种情况下加save操作会阻塞主进程

在这种模式下， 每执行一次命令，wirte和saev都会触发，因为此时save是由主进程执行的，所主进程会阻塞，不会接收其他命令请求（最多丢失一条命令）

bgsave

客户端

缺点

AOF的保存模式配置

# 可以通过修改redis.conf配置文件中的appendonly参数开启 appendonly yes# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。dir */# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改appendfilename appendonly.aof

1符合自定义配置的快照规则

RDB的优缺点

AOF_FSYNC_NO：不保存