RDB
可以指定时间间隔生成数据集的备份文件/可以指定不同的时间间隔
优点
<span style="font-size: 12px;">· rdb数据结构紧凑，可以指定多时间点进行数据备份/在恢复时有多版本</span><br><span style="font-size: inherit;">· rbd是一份内容紧凑的</span>数据<span style="font-size: inherit;">，方便数据加密传输备份<br></span>· rdb数据备份性能更好，fork出来一个子线程来备份，不影响主线程工作<br><span style="font-size: inherit;">· rdb的数据恢复速度比较快；当数据修改较多时尤为显著</span>
缺点
rdb不能尽量保证数据的完整性：容易丢失时间间隔内的数据
每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 <br>在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；<br> 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。<br> 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失
fork失败案例<br>redis存储类14G数据，内存只有16G
<b><font color="#c41230">fork</font></b>
fork()系统调用是Unix下以自身进程创建子进程的系统调用，一次调用，两次返回，如果返回是0，则是子进程，<br> 如果返回值>0，则是父进程（返回值是子进程的pid），这是众为周知的。 <br>还有一个很重要的东西是，在fork()的调用处，整个父进程空间会原模原样地复制到子进程中，<br> 包括指令，变量值，程序调用栈，环境变量，缓冲区，等等。
AOF
记录所有写操作到log文件，以追加的形式写入，恢复时可以执行log中的数据集<br>可以rewrite.来调整log文件大小
优点
1.fsync策略可以设置每次写入/每秒执行，最小损失数据同步<br>2. redis-check-aof 可以对写入有问题的命令进行修复<br>3.aof文件过大时，redis会对文件重写，以最小命令集来压缩文件大小，<br> 并且会在重写后替换现有的aof文件,不用担心期间异常导致的数丢失<br>4.aof文件即便再flushall后仍可恢复/修改aof,删掉最后的命令
缺点
1.相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积<br>2.使用的fsync aof速度慢于rdb
<font color="#c41230">事件</font>
AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。<br> （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） <br>测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 <br>虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。
