持久化意义
redis持久化的意义主要在于故障恢复，比如部署了一个redis服务器，作为缓存里面可能有些重要数据，如果没有持久化，redis遇到灾难性故障时就会丢失所有的数据。所以持久化是必不可少的。
RDB和AOF两种持久化机制介绍
RDB持久化机制是对redis中数据进行周期性的持久化。
AOF持久化机制对每条写入命令作为日志，以append-only（追加）模式写入到一个日志文件中，在redis重启的时候，可以通过AOF写入的指令来重新构建整个数据集。
通过RDB和AOF都可以讲redis内存中的数据持久化到硬盘上，然后可以将数据备份到云服务器上。
如果redis挂了可以从云服务器上的备份文件copy到指定位置后重启redis，redis就会自动持久化文件中的数据，去恢复内存中的数据。
如果同时使用RDB和AOF两种持久化机制，那么redis重启的时候，会使用AOF来构建数据，因为AOF数据更加完整。
RDB机制
当满足条件时，redis需要执行RDB的时候服务器会执行以下操作：
1.redis调用系统的fork()函数创建一个子进程
2.子进程将数据集写入一个临时的RDB文件
3.当子进程完成对临时的RDB文件的写入时，redis用新的RDB文件来替换原来旧的RDB文件，并删除旧的RDB文件。
redis在进行快照的过程中不会对RDB文件进行修改，只有快照结束后才会将旧快照替换成新快照，也就是说任何时候RDB文件都是完整的。
RDB优点：
（1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻的数据，这种多个数据文件的方式，非常适合做冷备。
（2）RDB在redis对外提供读写服务的时候，影响非常的小，因为redis主进程只需要fork一个子进程出来，让子进程对磁盘io来进行持久化。
（3）RDB在恢复大数据集的时速度比AOF的恢复速度快。
RDB确定：
（1）如果redis要故障时尽可能的少丢失数据，RDB没有AOF好。例如1:00进行的快照，在1:10又要进行快照的时候宕机了，这个时候就会丢失10分钟的数据。
（2）RDB每次fork出子进程来执行RDB快照生成文件时，如果文件特别大，可能会导致客户端提供服务暂停数毫秒或者几秒。
AOF机制
redis中的数据是有一定数量的，不可能说redis中的数据无限增长，进而导致AOF文件无限增长。内存的大小是一定的，等到了一定大小redis会采用淘汰策略，自动将内存中的数据清除掉。AOF是存放每条写命令的，所以会不断的增大，当大到一定程度时，AOF会做rewrite操作，rewrite操作就是基于当时redis的数据重新构造一个小的AOF文件，然后将大的AOF文件删除。
AOF优点：
（1）AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis挂掉了，最多丢失1秒的数据。
（2）AOF以append-only的模式写入，所以没有任何的磁盘寻址的开销，写入性能非常的高。
（3）AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。
AOF缺点：
（1）对于同一份数据备份文件，AOF比RDB大
（2）AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的。
（3）数据恢复比较慢，不适合做冷备。
AOF和RDB如何选择
（1）不要仅仅使用RDB，会丢失很多数据
（2）不要仅仅使用AOF，因为这一会有两个问题，第一通过AOF做冷备没有RDB做冷备恢复的速度快；第二RDB每次简单粗暴生成数据快照，更加健壮。
（3）综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，可以使用RDB进行快速的数据恢复。