redis（三）RDB持久化和AOF持久化

RDB

save和bgsave

save

save会对进程进行阻塞，直到RDB文件创建完毕。阻塞后redis不会接受任何请求。

bgsave

和save不同的是，bgsave是进程会fork一个子进程，这样主进程不会被阻塞，可以正常的服务。但是bgsave的期间，服务器会拒绝client端发来的save请求，如果是bgrewriteaof请求，则会等bgsave结束才会执行bgRewriteAOF。如果bgRewriteAOF在执行，则会拒绝bgsave。

自动间隔保存

save 900 1
save 300 10
save 60 10000

意思就是：
900秒内，对数据库至少进行了1次修改。
300秒内，对数据库至少进行了10次修改。
60秒内，对数据库至少进行了10000次修改。

同时服务器会使用两个字段进行保存修改数，和上一次执行保存的时间。
redis服务器会周期性调用一个函数（serverCorn），对是否需要进行持久化进行判断。

AOF

AOF（Append only file），意思就是会将命令直接append 进aof文件。

AOF写入与同步

aof执行请求的时候，会将请求内容先缓存进aof_buf里面，需要进行同了后，就会追加到文件里面去。
aof有3种同步的策略：

1. always 就是每次操作都会同步到文件里面去
2. everysec 同步时间相隔1秒，每秒对aof_buf中的数据append到 aof文件中
3. no 这个根据操作系统内部来进行。

这里有个权衡，就是是选用那种策略。

• 如果是always的话，那会对redis服务器对效率进行很严重的影响，但是数据的完整性，最多是相隔一次命令。
• 如果是everysec，效率会快上很多，而且就算机器宕机，丢失的也只有1秒的数据。
• no的话，可以根据操作系统的判断，按对服务的影响的话，no是基本不会影响服务，但是如果宕机，那么丢失的数据将是直到上一次no执行为止的数据。

AOF文件的载入与数据还原

AOF的重写与实现

如果是按照每条set语句来的话，那么对同一个key进行了多次set，如果aof载入的时候，进行重放操作，那么对载入的时间可能会有很大的影响，所以需要对aof文件进行重写。
重写文件的话，会对旧的aof文件，进行读取，并且对key值进行判断，最后生成对重写文件则会是，所有对key值只会写入一遍。过滤掉过期数据。
命令的话：bgRewriteAOF。同样是fork一个子进程来进行操作。但是可能会出现一种情况，就是：在后台进行重写的时候，客户端再次请求操作。

这里就添加了aof重写缓冲区，当重写aof文件进程结束的时候，会将aof重写缓冲区里面的命令再写到新的aof文件中，然后使用原子性的方式来覆盖旧的aof文件。