redis学习——RDB和AOF持久化

定义

rdb持久化：

        把当前数据生成快照保存在硬盘上

aof持久化：

        记录每次对数据的操作到硬盘上

RDB特点

        操作rdb持久化可以手动也可以自动，手动需要进行save和bgsave两种操作，而自动需要修改配置文件。

save操作：

        当执行save操作时，redis服务就会进入阻塞状态，直到rdb持久化完成。此操作在处理大量数据持久化时会造成长时间阻塞。

bgsave操作：

        当执行bgsave操作时，redis会调用fork创建一个子进程，此时bgsave操作就执行完了，持久化rdb的任务就会由子进程完成，如果阻塞也只会阻塞子进程，redis服务不会受到影响。

过程：

        首先执行bgsave命令，Redis进程先判断当前是否存在正在执行的RDB或AOF子线程，如果存在就是直接结束。当redis进程执行fork操作创建子线程，在执行fork操作的时候中Redis进程会被阻塞。当redis进程fork完成后，bgsave命令就结束了，自此Redis进程不会被阻塞，可以响应其他命令。子进程根据Redis进程的内存生成快照文件，并替换原有的RDB文件。子进程通过信号量通知Redis进程已完成。

自动rdb持久化：

        图中的意思就是每300秒内如果修改10个值那么就执行一次bgsave操作，下面的一行是在面对高并发的情况下，当60秒内有10000个数据被修改，那么就会执行一次bgsave操作。

        优点：rdb是一个紧凑的二进制压缩文件，是redis在某个时间点的全部数据快照，使用rdb恢复数据的速度远远快于aof，非常适合备份，全量复制，灾难恢复等场景。

        缺点：每次执行bgsave都要使用fork创建子进程，消耗大。

AOF特点

        相比于rdb的定期定次持久化，aof持久化是实时的，他会把每次写的命令都追加写入日志中，当需要恢复数据的时候重新执行aof文件里面的命令即可，就像写脚本一样，aof文件人也能看得懂，类似于有个助手当你敲代码的时候他就跟着敲一遍。aof解决了数据持久化的实时性，也是目前主流的redis持久化方式。

过程：

        当我们写完操作后，所有的命令操作都会被追加到aof的缓存区保存，保存到缓存区后会根据不同的策略将aof缓存区同步到aof文件中。但是aof毕竟不像rdb那样的二进制文件，所以需要定期的对aof文件进行重写，（比如连续给一个键赋值，那么重写后的文件就只保留最后赋值的命令），重写后的文件执行的结果会和原本的操作一样，不同的是执行过程中的冗余代码会被检测剔除。当需要重新加载回复数据的时候，redis会重新执行aof文件中的命令。

自动执行aof持久化

appendonly改为yes，开启AOF：

        appendonly yes

指定AOF文件的名字：

    appendfilename "appendonly.aof"

AOF文件的写入方式：
        everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式，此外还有no，和always，always表示每次写入一次命令，就会进行一次aof持久化，将aof缓存中的内容写入文件。而no是将aof持久化操作交给操作系统，自己永不执行（性能最高）。而everysec设置为每一秒就执行一次，关照了实时性又兼顾了效率

        appendfsync everysec

运行AOF重写时AOF文件大小的增长率的最小值

        auto-aof-rewrite-percentage 100

运行AOF重写时文件大小的最小值，64mb过小，一般可以设置的更大

        auto-aof-rewrite-min-size 64mb