本篇文章是对之前文章的一些总结
【大厂面试】面试官都爱问的 Redis 持久化 (RDB)
【大厂面试】面试官都爱问的 Redis 持久化 (AOF)
RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以 redis 协议追加保存每次写的操作到文件末尾，redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式
同时开启两种持久化方式
- 在这种情况下，
当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。 - RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件，
那要不要只使用 AOF 呢？作者建议不要，因为 RDB 更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
性能建议
- 因为 RDB 文件只能做后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1 这条规则。
- 如果开启 AOF，好处是在最恶劣的情况下也只会丢失不超过两秒的数据，启动脚本简单只加载自己的 AOF 文件就可以了，代价一是带来了持续的IO，二是 AOF 重写的最后将重写过程中产生的新数据写到新文件造成的堵塞几乎是不可避免的，只要硬盘许可，应该尽量减少 AOF 重写的频率，AOF 重写的基础大小默认值 64M 太小了，可以设置到5GB以上，默认超过原大小 100% 大小时重写可以改到适当的数值。
- 如果不开启AOF，仅靠 Master-Slave Replication 实现高可用性也可以，能省掉一大笔IO也减少了重写时带来的系统波动，代价是如果 Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB 文件，载入较新的那个，新浪微博就选用了这种架构。
