redis 通过aof日志恢复_Redis进阶教程-aof(append only file)日志文件

今天看了

何为AOF?

在Redis配置文件中有一个叫

扩展知识:

Redis有三种类型的落地文件:

数据文件-在配置中可设置其位置及文件名,默认文件名dump.rdb

日志文件-在配置中也可以配置.当然,在你是以daemon方式运行的时候,这个值就不要设置为stdout了,这么设置会自动被换成/dev/null

AOF文件-也就是我们这篇文章的主角,他的作用是用于数据恢复.他除了设置是否开启外,还可以设置开启后以何种方式写日志.这个何种一共是三

种,1是每次写操作都保证将fsync()来完成的,2是每秒调用一次fsync(),3是从不调用,让操作系统自己来同步.当然,设置为不同,效率会不

同,你的数据损失风险也不同.

运行流程

既然是log文件,而且是要用于恢复的,那么我们动动脚趾都能想到,这玩意肯定会越来越大,不管你的应用是大是小,如果AOF文件只增不减的话,那

文件将会无限长大,这个问题是所有binlog都会遇到的.而通常遇到这种问题都会有一个rotate方案.就是当日志达到一定大小或者每隔一段时间将日

志写到新的一个文件中,旧日志文件可以用来备份或其它.

而Redis的AOF还和rotate略有不同,他用了一种比较简单的方法,就是先给当前的所有数据做一个快照.然后再在这个快照的基础上写接下来的日志.

照快照的好处是,你之前可能用了10w次操作共改变了100条数据(比如在一条数据上进行了多次操作).那这时你AOF中的10w条写操作记录就变成了100条记录.相当于将前面的执行全部合并了.原本很大AOF变小了.

执行这个操作的命令是:

这个快照长什么样呢?基本和一般的写日志没什么两样,也是一条一条的写记录..比如现在Redis中总共存了3条string类型的数据a=&

gt;1,b=>2,c=>3.那这个快照的基本内容就是写入a=>1,写入b=>2,写入c=>3.

这时候要用AOF进行恢复的时候,只要先执行了前面几条,就能够恢复当前状态,然后再执行之后来的写操作,就能完全重现数据了.

内部实现

我们大概知道了执行BGREWRITEAOF时都发生了什么,下面来说一下Redis是如何实现的.分下面几步:

fork! Redis通过fork产生子进程.

子进程对当前数据执行遍历操作,将当前所有数据都生成一条写入日志,将这些日志写入一个临时文件.(其实是子进程写了一个临时文件,又再rename成了另一个临时文件)

父子进程是并行执行的,在子进程遍历并写临时文件的时候,父进程在照常接收请求,处理请求,写AOF,不过这时他是把新来的AOF写在一个缓冲区中.

当子进程完成遍历操作,写完临时文件后,就会退出.这时父进程的wait3函数会接收到子进程退出的消息,他会把自己现在收集在缓冲区中的所有AOF追加在临时文件中.

最后一步,把临时文件rename一下,改名为appendonly.aof,这时原来的aof文件被覆盖.整个过程完成.

如果你的AOF文件稍微大点,你可以在一个终端执行BGREWRITEAOF, 然后立刻ls

连着查看几次redis的data目录,就可以看到,先生成了一个临时文件,临时文件比原来的appendonly.aof小一些,然后临时文件消失,而

原来的appendonly.aof变小了,其实就是临时文件rename成了appendonly.aof..覆盖了原来的大文件.看起来像是临时文件

消失了.

其它

可能你要说,随着数据的增多,aof文件肯定也是越来越大的啊..这个没错,因为当你有10w条记录的时候,你至少要有10w条纯添加日志.然而这时候你的数据文件也应该够大了吧..更何况这日志文件呢.