小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
废话不多说，直接来总结！
AOF和RDB之间的相互作用
在版本号大于等于 2.4 的 Redis 中，BGSAVE 执行的过程中，不可以执行 BGREWRITEAOF 。反过来说，在 BGREWRITEAOF 执行的过程中，也不可以执行 BGSAVE。这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。
如果 BGSAVE 正在执行，并且用户显示地调用 BGREWRITEAOF 命令，那么服务器将向用户回复一个 OK 状态， 并告知用户BGREWRITEAOF 已经被预定执行：一旦 BGSAVE 执行完毕，BGREWRITEAOF 就会正式开始。
当 Redis 启动时，如果 RDB持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集，因为 AOF 文件所保存的数据通常是最完整的。
备份redis数据
- 创建一个定期任务（
cron job），每小时将一个RDB文件备份到一个文件夹，并且每天将一个RDB文件备份到另一个文件夹； - 确保快照的备份都带有相应的日期和时间信息，每次执行定期任务脚本时，使用
find命令来删除过期的快照； - 至少每天一次，将
RDB备份到你的数据中心之外，或者至少是备份到你运行Redis服务器的物理机器之外。
性能建议
在实际应用时，因为RDB文件只用作后备用途，建议只在slave上持久化RDB文件，而且只需要15分钟备份一次就够了，只保留save 900 1这条规则。
如果开启AOF，好处是在最恶劣情况下也只会丢失不超过2秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite 的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设置到5G以上。默认超过原大小的100%时重写可以改到适当的数值。
如果不开启AOF，仅靠Master-Slave Replication实现高可用性也可以。能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。
以上就是 Redis 持久化的的全部内容了，如果你有不同的意见或者更好的idea，欢迎联系阿Q，添加阿Q可以加入技术交流群参与讨论呦！
