Redis持久化方式笔记

RDB快照

RDB属于全量备份，RDB备份又分为两种BGSave与Save实现方式。

原理：主进程fork子进程，子进程将数据集写入到一个临时RDB 文件中。当子进程完成对新 RDB 文件的写入时，用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

优点：
非常适合保存某个时间点的数据集，比如每小时每天，可以根据需求恢复到不同版本的数据集。
RDB相对于AOF在恢复大数据集的时候回更快。  

缺点：
RDB持久化数据属于重量级操作，不适合频繁执行，所以redis意外停机后持久化数据完整性没有AOF好。
经常fork子进程保存数据，当数据集比较大的时候计较耗时会影响客户端请求。

AOF追加

AOF文件会记录所有写入操作，以此来记录所有数据发生的变化，可以使用命令BgRewriteAOF发出重写AOF文件操作，Redis2.4以后版本中AOF会由redis自行触发。

原理：主进程fork子进程，对于写命令主进程会将他们写入缓存中并且写入现有的AOF文件末尾，待子进程重写完毕会发送给主进程信号，主进程会把缓存中数据追加到新AOF文件中，然后会使用新文件替换旧文件。

优点：

    使用AOF策略，主线程依然可以处理客户端请求，如果出现故障最多丢失1秒数据。

    AOF文件有序对数据库执行的写入操作，而且文件内容人类可读，即便不小心执行了错误的命令，在AOF文件未被重写情况下只要停止redis服务器就可以编辑AOF文件对命令进行重写或者删除命令。

缺点：

    AOF文件体积通常要要大于RDB文件。
    AOP启用fsync 策略后性能可能不如RDB高。

恢复数据

如果开启了两种持久化方式，redis启动后优先从AOF文件中恢复数据，因为AOF文件中数据通常相对于RDB要完整。

AOF文件损坏

当redis正在进行AOF备份是停机，如果停机造成AOF文件出错那么redis为了保证数据的一致性不被破坏，会拒接加载这个AOF文件。
1为AOF文件创建备份；
2使用redis-check-aof程序对AOF文件进行修复；
3重启redis服务器等待载入修复后的AOF文件。

持久化过程差异

RDB经测试
删除dump.rdb文件，执行bgsave会新生成一个dump.rdb文件。所以rdb将内存中数据写入到临时的RDB文件中，然后替换新的RDB文件并删除旧RDB。

AOF经测试
测试1：aof持久化策略为每次写入都持久化，然后写入set 新字符串，查看appendonly.aof文件修改时间已经改变为写入字符串的时间。

测试2：同样策略删除appendonly.aof，新写入set 新字符串，appendonly.aof文件没有重新生成，总结AOF是copy旧文件，主进程缓存新写入数据并追加现有AOF文件，待子进程发送信号，主进程将内存缓存数据追加至新appendonlt.aof文件中，然后替换新文件