Redis之——持久化机制

Redis提供了两种持久化机制：RDB和AOF

 

一、RDB

RDB的持久化策略：按照规则定时将内存中的数据同步到磁盘中，生成文件名为dump.rdb

 

redis触发快照的4种方式：

1、自己配置的快照规则（默认）

save <seconds> <changes>

save 900  1           在900秒内被更改的key大于1次就会执行快照

save 300  10

save 60  10000

2、save或者bgsave

save：执行save，将数据同步到磁盘中，这个操作会阻塞客户端的请求

bgsave：执行bgsave，在后台异步执行快照操作，这个操作不会阻塞客户端的请求

3、执行flushall的时候

清除内存中的所有数据，只要快照的规则不为空，那么redis就会执行快照

4、执行复制的时候

 

快照实现的原理

1、redis使用fork函数复制一份当前进程的子进程。

2、父进程可以继续接收命令，子进程开始将内存中的数据写入到硬盘中的临时文件。

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

注意：redis在进行快照的过程中不会去修改RDB文件，只有在快照结束时，才会用新的RDB文件去替换旧的RDB文件，所以在任何时候RDB文件都是完整的，所以我们可以通过定时备份RDB文件来实现对Redis数据的备份。

 

RDB的优缺点：

优点：RDB可以最大化Redis的性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后子进程就会处理接下来的所有保存工作，而父进程无需执行任何磁盘的I/O操作。

缺点：使用RDB实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。

 

二、AOF

AOF的持久化策略：修改redis.conf中的appendonly  yes，重启后执行对数据的变更命令，会在bin目录下生成对应的appendonly.aof文件，aof文件中会记录所有的操作命令。

 

AOF重写的原理

redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写，重写后的新AOF文件只包含恢复当前数据集所需的最小命令集合，也就是将一个已经被覆盖或者删除的数据命令去掉。整个重写操作是绝对安全的，因为redis在创建新AOF文件的过程中，会继续将命令追加到现有的的AOF文件里，即使重写过程中发生停机，现有的AOF文件也不会丢失。而一旦新AOF文件创建完毕，redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。

 

AOF文件损坏后的修复

1、先备份现有的AOF文件。

2、使用Redis附带的redis-check-aof 程序，对原来的 AOF 文件进行修复。执行命令redis-check-aof  –fix，重启 Redis 服务器，等待数据恢复。

 

RDB和AOF如何选择

一般来说，如果对数据安全性要求非常高的话，应该同时使用两种持久化功能。如果可以承受数分钟以内的数据丢失，那么可以只使用RDB持久化。

两种持久化策略可以同时使用，也可以只使用其中一种。如果同时使用的话，那么Redis重启时，会优先使用AOF文件来还原数据。