rdb和aof的优缺点
5583
rdb的优点：1、体积更小；2、恢复更快；3、性能更高。rdb的缺点：1、故障丢失；2、耐久性差。aof的优点：1、数据保证；2、自动缩小。aof的缺点：1、性能相对较差；2、体积相对更大；3、恢复速度更慢。其中，rdb体积更小是指相同的数据量rdb数据比aof的小，因为rdb是紧凑型文件。
一、rdb的优点
- 体积更小：相同的数据量rdb数据比aof的小，因为rdb是紧凑型文件。
- 恢复更快：因为rdb是数据的快照，基本上就是数据的复制，不用重新读取再写入内存。
- 性能更高：父进程在保存rdb时候只需要fork一个子进程，无需父进程的进行其他io操作，也保证了服务器的性能。
二、rdb的缺点
- 故障丢失：因为rdb是全量的，我们一般是使用shell脚本实现30分钟或者1小时或者每天对redis进行rdb备份，（注，也可以是用自带的策略），但是最少也要5分钟进行一次的备份，所以当服务死掉后，最少也要丢失5分钟的数据。
- 耐久性差：相对aof的异步策略来说，因为rdb的复制是全量的，即使是fork的子进程来进行备份，当数据量很大的时候对磁盘的消耗也是不可忽视的，尤其在访问量很高的时候，fork的时间也会延长，导致cpu吃紧，耐久性相对较差。
三、aof的优点
- 数据保证：我们可以设置fsync策略，一般默认是everysec，也可以设置每次写入追加，所以即使服务死掉了，也最多丢失一秒数据
- 自动缩小：当aof文件大小到达一定程度的时候，后台会自动的去执行aof重写，此过程不会影响主进程，重写完成后，新的写入将会写到新的aof中，旧的就会被删除掉。但是此条如果拿出来对比rdb的话还是没有必要算成优点，只是官网显示成优点而已。
四、aof的缺点
- 性能相对较差：它的操作模式决定了它会对redis的性能有所损耗。
- 体积相对更大：尽管是将aof文件重写了，但是毕竟是操作过程和操作结果仍然有很大的差别，体积也毋庸置疑的更大。
- 恢复速度更慢：AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。
拓展阅读
RDB和AOF
RDB是将支持当前数据的快照存成一个数据文件的持久化机制。
- 在生成快照时，将当前进程fork出一个子进程.
- 然后再子进程中循环所有的数据，将数据写入到二进制文件中。
- 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
AOF：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。AOF的工作原理就是是将写操作追加到文件中，文件的冗余内容会越来越多。所以Redis 新增了重写机制。当AOF文件的大小超过所设定的最大值时，Redis就会对AOF文件的内容压缩。
