Redis学习笔记（四）持久化

Redis的持久化分为两种：RDB(Redis DataBase)和AOF（Append Only File）

一.RDB

1.是什么？

在指定的时间间隔内将内存中的数据集快照写入磁盘，
也就是行话讲的Snapshot快照，它恢复时将快照直接读到内存内。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写到一个临时文件中，主进程不进行任何的IO操作的，这就确保了极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2.Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等）都和原进程一致，但是是一个全新的进程，作为主进程的子进程。

3.配置文件中的RDB

可以从解释中看出默认配置三种情况来存储RDB文件
第一种：900秒内，有1次的key改变
第二种：300秒内，有10次的key改变
第三种：60秒内，有10000次的key改变
并且如果我们想直接将值写进RDB，我们可以直接输入命令save，就可以不受上面条件的限制了。

一般生成的RDB文件默认名字为dump.rdb

如果在备份的时候，数据出错，将停止备份。

在备份的过程中将会压缩，但是会浪费一些系统资源。

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

4.注意事项：

命令SAVE只管保存，其他不管，全部阻塞。
命令BGSAVE，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间。
执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

5.如何恢复？

将备份文件（dump.rdb）移动到redis安装目录并启动服务即可，CONFIG GET dir 获取目录。

6.优势

适合大规模的数据恢复，但对数据完整性和一致性要求不高，比如出现网络问题，最后一次备份的数据可能丢失。

7.劣势

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
Fork的时候，内存中的数据被克隆了一次，大致两倍的膨胀性需要考虑

二.AOF

1.是什么？

以日志的形式来记录每个写动作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构造数据，换言之，redis重启的话就根据日志文件的内容将指令此前到后执行一次以完成数据的恢复工作。

2.配置文件

可以看出，默认情况下aof是关闭着的，并且生成的文件是appendonly

3.AOF和RDB在恢复的时候谁的优先度更高？

我们可以写个简单的测试
往redis写数据，触发rdb和aof文件，然后shutdown
这个时候往aof写一堆乱码，然后重启redis，发现重启不起来
这个时候我们就可以得出结论：redis在恢复的过程中先找aof来恢复
这种出现乱码的情况很常见，比如说突然断电,丢包，病毒等等
这个时候如何恢复呢？

redis-check-aof --fix appendonly.aof

4.rewrite

是什么：
AOF采用文件追加方式，文件会越来越大为避免出现这种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF的内容压缩，只保留可以恢复数据的最小指令，可以使用命令bgrewriteaof 。
重写原理：
aof文件持续增长过大时，会fork出一条新进程来将文件重写（也就是先写临时文件然后再rename）。遍历新进程的内存中数据，每条记录有一条set语句。重写aof文件操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写一个新的aof文件，这点和快照有点类似。
触发机制:
redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64M时触发。