RDB缺点
如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB ⽂件的频率， 但是， 因为RDB ⽂件需要保存整个数据集的状态， 所以它并不是⼀个轻松的操作。 因此你可能会⾄少 5 分钟才保存⼀次 RDB ⽂件。 在这种情况下， ⼀旦发⽣故障停机， 你就可能会丢失好⼏分钟的数据。每次保存 RDB 的时候，Redis 都要 fork() 出⼀个⼦进程，并由⼦进程来进⾏实际的持久化⼯作。 在数据集⽐较庞⼤时， fork() 可能会⾮常耗时，造成服务器在某某毫秒内停⽌处理客户端； 如果数据集⾮常巨⼤，并且 CPU 时间⾮常紧张的话，那么这种停⽌时间甚⾄可能会长达整整⼀秒。 虽然 AOF 重写也需要进⾏ fork() ，但⽆论 AOF 重写的执⾏间隔有多长，数据的耐久性都不会有任何损失。
AOF优点
使⽤ AOF 持久化会让 Redis 变得⾮常耐久（much more durable）：你可以设置不同的 fsync 策略，⽐如⽆ fsync ，每秒钟⼀次 fsync ，或者每次执⾏写⼊命令时 fsync 。AOF 的默认策略为每秒钟 fsync ⼀次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发⽣故障停机，也最多只会丢失⼀秒钟的数据（ fsync 会在后台线程执⾏，所以主线程可以继续努⼒地处理命令请求）。AOF ⽂件是⼀个只进⾏追加操作的⽇志⽂件（append only log）， 因此对 AOF ⽂件的写⼊不需要进⾏ seek ， 即
使⽇志因为某些原因⽽包含了未写⼊完整的命令（⽐如写⼊时磁盘已满，写⼊中途停机，等等）， redis-check-aof ⼯具也可以轻易地修复这种问题。
Redis 可以在 AOF ⽂件体积变得过⼤时，⾃动地在后台对 AOF 进⾏重写： 重写后的新 AOF ⽂件包含了恢复当前数据集所需的最⼩命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF ⽂件的过程中，会继续将命令追加到现有的 AOF ⽂件⾥⾯，即使重写过程中发⽣停机，现有的 AOF ⽂件也不会丢失。 ⽽⼀旦新 AOF ⽂件创建完毕，Redis 就会从旧 AOF ⽂件切换到新 AOF ⽂件，并开始对新 AOF ⽂件进⾏追加操作。AOF ⽂件有序地保存了对数据库执⾏的所有写⼊操作， 这些写⼊操作以 Redis 协议的格式保存， 因此 AOF ⽂件的内容⾮常容易被⼈读懂， 对⽂件进⾏分析（parse）也很轻松。 导出（export） AOF ⽂件也⾮常简单： 举个例⼦， 如果你不⼩⼼执⾏了 FLUSHALL 命令，但只要 AOF ⽂件未被重写， 那么只要停⽌服务器， 移除 AOF ⽂件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到FLUSHALL 执⾏之前的状态。
AOF缺点
对于相同的数据集来说，AOF ⽂件的体积通常要⼤于 RDB ⽂件的体积。根据所使⽤的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在⼀般情况下， 每秒 fsync 的性能依然⾮常⾼， ⽽关闭 fsync 可以让 AOF 的速度和 RDB ⼀样快， 即使在⾼负荷之下也是如此。 不过在处理巨⼤的写⼊载⼊时，RDB 可
redis支持的五种数据类型以提供更有保证的最⼤延迟时间（latency）。AOF 在过去曾经发⽣过这样的 bug ： 因为个别命令的原因，导致 AOF ⽂件在重新载⼊时，⽆法将数据集恢复成保存时的原样。 （举个例⼦，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件⾥为这种情况添加了测试： 它们会⾃动⽣成随机的、复杂的数据集， 并通过重新载⼊这些数据来确保⼀切正常。 虽然这种 bug 在 AOF ⽂件中并不常见， 但是对⽐来说， RDB ⼏乎是不可能出现这种 bug 的。
如何选择
⼀般来说，如果想达到⾜以媲美 PostgreSQL 的数据安全性， 你应该同时使⽤两种持久化功能。如果你⾮常关⼼你的数据，但仍然可以承受数分钟以内的数据丢失， 那么你可以只使⽤ RDB 持久化。有很多⽤户都只使⽤ AOF 持久化， 但我们并不推荐这种⽅式： 因为定时⽣成 RDB 快照（snapshot）⾮常便于进⾏数据库备份， 并且 RDB 恢复数据集的速度也要⽐ AOF 恢复的速度要快， 除此之外， 使⽤ RDB 还可以避免之前提到的 AOF 程序的 bug 。因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是⼀个长期计划。）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。