redis 持久化rdb aof 简介

redis 持久化rdb aof 简介

结合了几篇文章总结如下

1. rdb模式介绍【默认】

rdb方式的持久化是通过快照完成的，当符合一定条件时redsi会自动将内存中的所有数据进行快照并存储到硬盘上。

默认存储在redis根目录的dump.rdb文件中。

rdb

是redis默认采用的持久化方式，配置信息在配置文件

redis.conf

中

定期将内存数据生成快照(即某个时间点上数据的备份) 然后存储在硬盘上

快照执行时机：

save 900 1：表示900秒内至少一个键被更改则进行快照。
save 300 10
save 60 10000

1.2. 快照执行机制

也可以手动执行save或者bgsave命令让redis执行快照。

两个命令的区别在于

- 1. save是由主进程进行快照操作，会阻塞其它请求。

2. bgsave会通过fork子进程进行快照操作。

1.3. redis实现快照的过程：

：redis使用fork函数复制一份当前进程的副本(子进程)

：父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件

：当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。

1.4. redis的copy-on-write

redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。

这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份

RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

1.5. rdb的修复

文件修复：redis-check-dump 在启动redis失败时，用于修复dump文件

1.6. rdb的优缺点

优点：由于存储的有数据快照文件，恢复数据很方便。

缺点：会丢失最后一次快照以后更改的所有数据。

2. AOF 模式介绍

1. AOF的解释?

在Redis配置文件中有一个叫appendonly的选项,可以写yes或no.这个选项就是负责是否开启AOF日志的开关.AOF日志,你可以简单理解为MySQL binlog一样的东西,作用就是记录每次的写操作,在遇到断电等问题时可以用它来恢复数据库状态.但是他不是bin的,而是text的.一行一行,写得很规范.如果你是一台redis,那你也能人肉通过它恢复数据.

AOF 保存的数据方案是最完整的，如果同时开启了rdb和aof下，会采用aof方式

aof文件的保存位置和rdb文件的位置相同，都是dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改

appendfilename appendonly.aof

2.1 aof的三种模式【不同的运行时机】

appendfsync always 每次都会执行

appendfsync everysec 默认 每秒执行一次同步操作（推荐）

appendfsync no不主动进行同步，由操作系统来做，30秒一次

2.2 aof日志文件重写

执行这个操作的命令是:

BGREWRITEAOF

(background rewrite append only file)

2.2.1 为什么需要日志重写

既然是log文件,而且是要用于恢复的,那么我们动动脚趾都能想到,这玩意肯定会越来越大,不管你的应用是大是小,如果AOF文件只增不减的话,那文件将会无限长大,这个问题是所有binlog都会遇到的.而通常遇到这种问题都会有一个rotate方案.就是当日志达到一定大小或者每隔一段时间将日志写到新的一个文件中,旧日志文件可以用来备份或其它.

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

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

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

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

2.3 内部实现

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

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

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

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

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

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

如果你的AOF文件稍微大点,你可以在一个终端执行BGREWRITEAOF,然后立刻ls 连着查看几次redis的data目录,就可以看到,先生成了一个临时文件,临时文件比原来的appendonly.aof小一些,然后临时文件消失,而原来的appendonly.aof变小了,其实就是临时文件rename成了appendonly.aof..覆盖了原来的大文件.看起来像是临时文件消失了.

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

auto-aof-rewrite-percentage 100

这个好像是说在redis第一次启动到目前位置aof文件所占用的一个百分比，如果有人确定告诉我啊，谢过

auto-aof-rewrite-min-size 64mb

这个好理解也就是aof文件最小要达到这个数值，因为频发执行bgrewriteaof也是不行的

2.4 aof文件修复命令【暂时没用到】

redis-check-aof

2.5 动态切换redis持久方式，从 RDB 切换到 AOF（支持Redis 2.2及以上）

CONFIG SET appendonly yes

CONFIG SET save ""（可选）

3. 一些文章

http://blog.chinaunix.net/uid-20682890-id-3603246.html

http://blog.chinaunix.net/uid-20682890-id-3603246.html

http://my.oschina.net/u/1377774/blog/325489

http://blog.nosqlfan.com/html/199.html

/article/4044331.html