https://zq99299.github.io/note-book/cache-pdp/redis/010.html#rdb-持久化机制的优点

RDB 缺点 1.故障时，丢的数据多

AOF 1.日志文件大 2.数据恢复较慢

RDB 持久化机制的缺点

1. 在故障时，数据丢得多

   一般来说，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据（因为在内存中还未来得及导出到磁盘）

   这个问题也是 rdb 最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖 RDB 做第一优先恢复方案，会导致数据丢失的比较多

2. 性能影响？

   什么鬼？上面说优点的时候说是性能影响小，这里缺点又提到了？

   以下一段话根本理解不了，

   RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。一般不要让 RDB 的间隔太长，否则每次生成的 RDB 文件太大了，对 redis 本身的性能可能会有影响的

AOF 持久化机制的缺点

1. 日志文件稍大

   对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大

2. 性能稍低

   AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync 一次日志文件，当然，每秒一次 fsync，性能也还是很高的

3. 发生过 BUG

   以前 AOF 发生过 bug，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似 AOF 这种较为复杂的基于命令日志 /merge/ 回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

   说 rewrite 非常复杂，因为是基于当时内存中已有数据进行构建指令达到压缩日志文件的目的，反正我是想不出来怎么实现的

4. 数据恢复较慢

   前面都说了，不适合做冷备，数据恢复基于指令稍慢