一文了解:Redis的AOF持久化

每当Redis-Server接收到写数据时,就把命令以文本形式追加到AOF文件里,当重启Redis服务时,AOF文件里的命令会被从新执行一次,从新恢复数据。当AOF过大时将重写AOF文件。redis

工做原理

> lpush list 1 2 3 4
(integer) 4
127.0.0.1:6379> lrange list 0 -1
1) "4"
2) "3"
3) "2"
4) "1"
127.0.0.1:6379> lpop list
"4"
127.0.0.1:6379> lrange list 0 -1
1) "3"
2) "2"
3) "1"
复制代码

appendonly.aof文件中数据库

*2
$6
SELECT
$1
0
*6
$5
lpush
$4
list
$1
1
$1
2
$1
3
$1
4
*2
$4
lpop
$4
list
复制代码

能够看到上面的示例中写操做有lpush和lpop命令,在AOF文件中存在lpush和lpop。SELECT命令为AOF程序自动加上的选择数据库。安全

AOF命令写入的内容为文本协议格式,如:命令lpush list 1 2 3 4 的文本形式为"*6\r\n$5\r\nlpushr\n$4r\nlist\r\n$1\r\n1$1\r\n2$1\r\n3$1\r\n4\r\n"。将文本内容追加到aof_buf(缓冲区)中,AOF缓冲区根据相应的策略同步写入AOF文件中,当AOF文件愈来愈大时,将AOF文件重写。bash

AOF原理

启动AOF持久化

在redis.conf文件中网络

appendonly no  #写成yes,打开AOF持久化
复制代码

AOF写入频率

# appendfsync always 
appendfsync everysec   # 默认
# appendfsync no
复制代码
  1. alaws:老是同步到AOF文件,每个命令都写入,安全,速度慢
  2. everysec:每秒写入一次,安全性好,最多丢失1秒钟的数据
  3. no:写入AOF文件工做交给操做系统,由操做系统写入AOF文件,安全性通常

文件

aof文件目录经过RDB文件目录,他们共享同一个目录app

dir ./

appendfilename "appendonly.aof"
复制代码

经过config set dir {newDir} 动态修改dir配置ui

经过config set dbfilename {appendfilename} 动态修改AOF文件名称spa

重写

AOF文件过大时,Redis将fork()一个子进程对内存数据进行比那里逆化成Redis命令,序列化文本格式后写入到新的AOF文件中。而后将重写时发生的增量AOF文件追加到新的AOF文件中,最后替换旧的AOF文件。操作系统

自动重写

auto-aof-rewrite-percentage 100  # 比上次重写时文件增大了100%就重写AOF文件
auto-aof-rewrite-min-size 64mb   # AOF文件至少超过为64M时重写AOF文件
复制代码

自动重写必须知足:当前AOF文件大小 > auto-aof-rewrite-min-size &&(当前文件AOF文件大小减去上次重写时AOF文件大小)除以 上次重写时AOF文件大小 = auto-aof-rewrite-percentagecode

手动重写

> bgrewriteaof
Background append only file rewriting started
复制代码

优缺点

优势

  1. 比RDB文件可靠,everysec模式下只丢1秒数据。
  2. AOF文件为纯文本文件。文件协议格式容易恢复成Redis命令。
  3. AOF文件太大会进行自动重写。

缺点

  1. 同等数据下,比RDB文件大。
  2. 同步过程当中Redis主进程会被阻塞,everysec是个折中方案。

数据恢复

Redis读取AOF文件数据还原过程

  1. 建立一个不带网络的客户端
  2. 读取AOF文件内容,还原成命令
  3. 将命令在1中的客户端执行
  4. 重复2,3的过程

结语

本人深知水平有限,欢迎指正本文错误之处。


logo