AOF会记录每个Redis命令到AOF文件，随着时间越来越长，AOF文件会变得越来越大。如果不加以控制，会对Redis服务器，甚至对操作系统造成影响，而且AOF文件越大，数据恢复也越慢。
为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写功能来对AOF文件进行“瘦身”。Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令。
RDB和AOF对比关于RDB和AOF的优缺点，官网上面也给了比较详细的说明redis.io/topics/pers…
RDB优点：
RDB快照是一个压缩过的非常紧凑的文件，保存着某个时间点的数据集，适合做数据的备份，灾难恢复；
可以最大化Redis的的性能，在保存RDb文件，服务器进程只需要fork一个子进程来完成RDB文件的创建，父进程不需要做IO操作；
与AOF相比，恢复大数据集的时候会更快；
缺点：
RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，根据配置可能要几分钟才快照一次，如果服务器宕机，那么就可能丢失几分钟的数据；
Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时；
AOF优点：
数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）；
AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复；
缺点：
对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢；
根据所使用的fsync策略，AOF的速度可能会慢于RDB。 不过在一般情况下，每秒fsync的性能依然非常高；
RDB和AOF如何选择通常来说，应该同时使用两种持久化方案，以保证数据安全。
如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化。
如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可。
如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启。
当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整。
参考资料Redis设计与实现
10分钟彻底理解Redis的持久化机制：RDB和AOF
Redis两种持久化机制RDB和AOF详解（面试常问，工作常用）