redis虽然是一个内存级别的缓存程序，但是它可以将内存的数据按照一定的策略保存到硬盘中，从而实现数据的持久化保持。目前，redis支持两种不同方式的数据持久化保存机制，分别是RDB和AOF，这两种模式分别类似于MySQL备份中dump和二进制日志方式。
- RDB模式
1.1 RDB模式工作原理
RDB（Redis DataBase，redis数据库）：基于时间的快照，默认只保留当前最新的一次快照，优点是执行速度比较快，缺点是可能会丢失上一次快照到当前快照时间点之间的数据。其工作原理如下图所示，首先redis将内存中的数据备份到二进制RDB文件中，之后如果redis处于关闭状态，则内存中的数据将不复存在，但是redis重启后，会自动加载之前备份的RDB文件，重新读取数据。
要想将redis内存中的数据备份到RDB文件中，我们可以使用到save指令（同步，会阻赛其它命令，不推荐使用）、bgsave指令（异步后台执行，不影响其它命令的执行）或者自动（制定规则，自动执行）的方式。例如RDB bgsave的方式，其实现快照的具体过程如下图所示：
RDB bgsave实现快照时，redis会从master主进程先fork一个子进程，使用写时复制机制，子进程将内存中的数据保存为一个临时RDB文件，当所有数据保存完毕之后再将上一次的RDB文件替换掉，然后关闭子进程，从而保证每一次做RDB快照所保存的数据都是完整的。
1.2 RDB模式的优缺点
1.2.1 RDB模式优点
RDB模式的优点主要表现为以下几点：
①RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave(非阻塞，后台执行)或者save(会阻塞写操作，不推荐)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本，很适合备份，并且此文件格式也支持有不少第三方工具可以进行后续的数据分析。
②RDB可以最大化Redis的性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O操作。
③RDB在大量数据,比如几个G的数据，恢复的速度比AOF的快。
1.2.2 RDB模式缺点
RDB模式的缺点表现在两方面：
①不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据。如果需要尽量避免在服务器故障时丢失数据，那么RDB并不适合。虽然Redis允许设置不同的保存点（save point）来控制保存RDB文件的频率，但RDB文件需要保存整个数据集的状态，所以它并不是一个轻松快速的操作，因此一般会超过5分钟以上才保存一次RDB文件，在这种情况下，一旦发生故障停机就可能会丢失好几分钟的数据。
②当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或者秒，取决于磁盘IO性能。在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端，如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失。
- AOF模式
2.1 AOF模式工作原理
AOF（Append Only File）：按照操作顺序依次将操作追加到指定的日志文件末尾。AOF模式和RDB模式一样使用了写时复制机制，AOF默认为每秒钟fsync一次，即将执行的命令保存到AOF文件当中，这样即使redis服务器发生故障最多只丢失1秒钟之内的数据，也可以设置不同的fsync策略always，即设置每次执行命令的时候执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的I/O影响。同时启用RDB和AOF进行恢复时，默认AOF文件优先级高于RDB文件，即会使用AOF文件进行恢复。
注意：AOF模式默认是关闭并且没有数据文件存在的，第一次开启AOF并重启服务生效后，会因为AOF的优先级高于RDB而导致所有数据丢失。
2.2 AOF模式的优缺点
2.2.1 AOF模式优点
AOF模式的优点表现为：
①数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存储设备)，默认是appendfsync everysec，即每秒执行一次fsync，在这种配置下，redis仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求)。
②由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek，即使出现宕机现象也不会破坏日志文件中已经存在的内容。如果本次操作只是写入了一半数据就出现了系统崩溃问题，在redis下次启动之前，可以通过redis-check-aof工具来解决数据一致性的问题。
③redis可以在AOF文件体积变得过大时自动地在后台对AOF进行重写，重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为redis在创建新AOF文件的过程中，append模式不断的将修改数据追加到现有的AOF文件里面，即使重写过程中发生停机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。
④AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作，事实上也可以通过该文件完成数据的重建。AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。
2.2.2 AOF模式缺点
AOF模式的缺点表现为：
①即使有些操作是重复的也会全部记录，因此AOF的文件大小要大于RDB格式的文件。
②AOF在恢复大数据集时的速度比RDB的恢复速度要慢。
③根据fsync策略不同，AOF速度可能会慢于RDB。
④在AOF模式中，bug出现的可能性会更多。
- RDB和AOF的选择
选择何种模式要依据实际情况来定：
①如果主要充当缓存功能，或者可以承受数分钟数据的丢失，通常生产环境中只开启RDB即可，这也是默认设置。
②如果数据需要持久保存，一点都不能丢失，可以同时开启RDB和AOF。
③一般不建议只开启AOF。
