RDB和AOF持久化
?RDB持久化
RDB是什么？
原理是redis会单独创建（fork） 一个与当前进程一模一 样的子进程来进行持久化，这个子进程的所有数据（变量。环境变量，程序程序计数器等）都和原进程一模一 样，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何的io操作，这就确保了极高的性能
1.这个持久化文件在哪里
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
2. 触发机制
既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制，是实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。我们分别来看一下
save：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止
bgsave：该命令是非阻塞，后台持久化数据，Redis会在后台异步进行快照操作，不影响写操作。
自动化：
在redis.conf配置文件中，里面有如下配置，我们可以去设置：
默认如下配置：
#表示900秒内如果至少有1个key的值变化，则保存save9001#表示300秒内如果至少有10个key的值变化，则保存save30010#表示60秒内如果至少有10000个key的值变化，则保存save6010000
不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。
RDB 的优势和劣势：
- 容易丢失数据，最高可能丢失59秒数据，当save6010000命令：突然断电，可能会丢失前59s持久化的临时数据文件
- RDB文件紧凑，全量备份，占用空间少。
AOF原理：
全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
1.触发机制（根据配置文件配置项）
appendfsync no：表示等操作系统进行数据缓存同步到磁盘（快， 持久化没保证）
appendfsync always：同步持久化，每次发生数据变更时，立即记录到磁盘（慢， 安全）
appendfsync everysec：表示每秒同步一次（默认值，很快， 但可能会丢失一秒以内的数据）
2.aof重写机制
其实就是瘦身，清除没用的日志记录
AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
什么时候会启动重写机制：
#当AOF文件增长到一定大小的时候Redis能够调用BGREWRITEAOF 对日志文件进行重写。当AOF文件大小的增长率大于该配置项时自动开启重写。
auto一aof一rewrite一percentage 80
#当AOF文件增长到一定大小的时候Redis能够调用BGREWRITEAOF 对日志文件进行重写。当AOF文件大小大于该配置项时自动开启重写
auto一aof一rewrite一min一size 64M（一般的公司最低5G）
3. 优缺点
(1)对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
(2)AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
(3)以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。
RDB和AOF最大区别
rdb:会frok子进程
aof:不会frok子进程，重写机制会frok子进程
原文地址：https://www.cnblogs.com/rqy0526/p/12346623.html