6、Redis从入门到放弃 之 持久化RDB和AOF

Redis强大的功能很大部分是由于他把数据缓存在内存中，为了使Redis在重启的时候，数据不丢失，就需要已某种方式把数据持久化到磁盘中。Redis持久化的方式有俩种，RDB和AOF。

RDB==>Redis DatabaseAOF====>Append Only File

1、RDB

①、RDB是以快照的方式对内存中的数据进行存储。即在 “”制定的时间间隔内“”将内存中的数据快照写入磁盘（即默认的dump.rdb文件）。重启或执行其他恢复命令 时 Redis直接去读取快照文件（dump.rdb）。

 ②、Redis调用fork()函数 单独创建一个子进程进行持久化操作。Redis持久化时会将数据写到一个临时文件中，待持久化过程结束后，再用这个临时文件替换上次持久化好的文件（在这个持久化过程中，主进程是不会进行IO操作的）

【fork（）函数通过系统调用创建一个与原来进程几乎完全相同的进程，也就是两个进程可以做完全相同的事，但如果初始参数或者传入的变量不同，两个进程也可以做不同的事。】

③、与RDB持久化相关的  配置信息（在redis.conf文件中）

Redis通过在redis.conf配置文件中配置 在规定时间内的改动次数 来触发  Redis内存数据持久化的发生：

（格式：save <seconds>  <changes>）

save 900 1 即900秒内至少更改过一个键 就会触发
save 300 10 即300秒内至少更改过10个键 就会触发
save 60 10000 即60秒内至少更改过10000个键 就会触发

此外执行save命令，无需满足 上诉条件 也会迅速生成dump.rdb文件

save "" 表示禁用RDB功能

配置文件中的其他相关 配置：

a、stop-write-on-bgsave-error  yes

yes 表示如果后台保存RDB出错时，就会禁止前台写KEY/VALUE

no 表示 不在乎数据是否满足一致性，可以进行更改和写操作

b、rdbcompress  yes

yes表示对存储到磁盘中的快照(dump.rdb)进行压缩操作  （会有一定的性能消耗）

c、rdbchecksum  yes

yes表示存储快照完成后，让redis进行数据的校验。（会有一定的性能消耗）

d、dbfilename  dump.rdb

是对生成的快照文件的命名  即将持久化后的信息保存在这个dump.rdb文件中

e、dir   ./

表示dump.rdb存储文件的位置

④、rdb快照触发条件：

a、满足redis.conf文件中的save配置条件

b、执行save命令或 bgsave命令

（save时只管持久化，其他不管，全部阻塞；bgsave时后台会异步进行快照持久化操作）

c、执行flushdb或者flushall操作

(flushdb清除当前库中的数据，flushall清除所有库中的数据)

d、重启服务等。

⑤、优缺点

优点：适合大规模的数据恢复，应为不是实时的进行持久化操作，所以性能会比aof要好点

缺点：默认在触发save条件时，也就是会在一定的间隔时间内才做一次数据持久化。所以如果Redis服务器意外宕机，就会丢失最后一次的快照后的所  有修改数据。

  fork()时会开启一个与主进程一模一样的子进程进行持久化操作，也就是说内存中的数据被克隆了一份，这就大致造成了2倍的膨胀性，需要考  虑。

2、AOF

（他的存在时为了避免RDB丢失最后一次数据的问题而诞生的，迷之诱惑）

与RDB记录内存数据到dump.rdb文件中不一样，AOF会将用户操作的"命令" "实时" 记录进appendonly.aof文件中。当然，如果aof文件信息膨胀到一定程度时，Redis会将AOF文件中的用户命令进行 "总结优化"（重新读取内存中的数据，每条数据会以set命令的形式重新写进aof文件中）。

（appendonly.aof是优先于dump.rdb的）

下面进入正题

①、AOF以日志的形式来记录每一次的写操作，将Redis执行过的所有写指令记录下来，秩序追加文件但不可以改写文件，Redis启动之初会读取appendonly.aof文件重新构建数据，换言之，redis重启的话就会根据日志文件的内容将写指令从前到后的执行一次已完成数据的恢复工作。

②、appendonly.aof是优先于dump.rdb的，也就是说当Redis服务启动的时候，如果dump.rdb和appendonly.aof同时存在的话，只要appendonly开启，服务会优先读取appendonly.aof文件的。只有在appendonly.aof文件不存在时，服务才会读取dump.rdb文件进行数据恢复。

③、bgrewriteaof

appendonly.aof肯定会越写越多，所以要精简、要优化、要重写文件。于是bgrewriteaof横空出世。

当appendonly.aof文件持续增长而过大时，服务会fork出一条新的进程来将文件进行重写（同rdb一样也是先写临时文件，然后再替换原来的appendonly.aof）。这条新进程会遍历当前内存中的数据，每条数据都会对应一条set语句写进aof文件。

重写aof的操作，并没有读取就得aof，而是将整内存中的数据库内容用命令的方式重写进一个新的aof文件中，类似快照。

那么重写的触发机制有哪些？：

Redis会记录上一次重写时AOF文件的大小，默认配置是当AOF文件大小是上一次reWrite后大小的一杯，且文件小于64M时触发。

对应的配置文件信息：

a、auto-aof-rewrite-percentage  100auto-aof-rewrite-min-size  64M

是上次文件的一倍，和大于64M时，触发。

④、与AOF持久化相关的配置信息（redis.conf文件中）

a、appendonly  yes

是否开启AOF，默认是NO不开启

b、appendfilename"appendonly.aof"

对持久化文件的命名，即持久化的写命令会追加到appendonly.aof文件中

c、appendfsync  everysec

AOF持久化的触发条件配置，有三个

1>、Always：同步持久化，每次数据变更，命令都会被立刻记录到磁盘文件中，性能较差，但数据的完整性一致性最好

2>、EverySec：这是默认的也是推荐的配置，异步操作，每秒记录并写进磁盘文件，但是如果服务宕机，就会丢失者一秒内的数据。

3>、No

d、no-appendfsync-on-write no

重写是是否可以运用appendfsync（即写数据到持久化文件中）。用默认的No即可，保证数据的安全性。

⑤、优缺点：

优点：默认每秒都会进行同步。数据的完整性和一致性比较高

缺点：应为是记录命令，所以相同数据集的数据而言AOF文件要远大于rdb文件。Redis服务在恢复数据的速度上是要慢于RDB的。

3、总结

①、如果对数据存储文件的大小，速度效率的快慢 要求比较高，但对数据的完整性和一致性要求不高时用RDB（双十一时）

②、对数据的完整性要求比较高时用AOF

③、如果只希望数据在服务器运行的时候存在，可以不用任何持久化方式。

在配置文件里  save "" 可以禁用RDB功能，appendonly no 表示禁用AOF功能

④、同时开启两种持久化方式，在这种情况下，当Redis重启时候优先载入AOF文件来恢复原始数据。

因为在通常的情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只是用AOF呢？建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份，快速重启，而且不会有AOF可能在的bug,留着作为一个万一的手段）

文章引用:https://my.oschina.net/davehe/blog/174662

http://www.redis.cn/topics/persistence.html

http://doc.redisfans.com/topic/persistence.html#append-only-file-aof