redis有两种方式支持持久化，分别是RDB和AOF。
RDB
RDB即redis database，它是redis默认采用支持持久化的方式。RDB通过快照实现持久化的支持，当满足一定条件时，RDB将对内存中的所有数据生成快照，并存放到硬盘中，默认存放在当前执行redis服务的根目录的dump.rdb中。
先演示一下，创建5条K-V数据，会生成快照文件dump.rdb，由于一会儿这个文件会被覆盖，所以我们先复制一份，取名为dump_backup.rdm：
现在先删除当前的dump.rdb文件（没关系，我们已经备份了），再进入redis服务，清除内存中的所有数据，并且关掉redis服务器。退出服务后会发现，当前目录下又生成了新的快照文件dump.rdb，但是由于我们清除了内存中的所有数据，所以这个快照文件中没有存放任何数据，一会儿真正起备份恢复作用的还是dump_backup.rdm文件。
由于redis默认会使用名为dump.rdb的文件进行恢复，所以我们现在先删除dump.rdb，然后将dump_backup.rdb重命名为dump.rdb，并且重启redis服务，进入redis会发现，数据自动恢复了：
RDB相关的配置在redis的配置文件redis.conf中，通常在标识有SNAPSHOTTING注释的模块下，我们可以在该配置文件中设置触发快照生成的情况，例如默认会触发快照生成的情况有，当900秒内有1个key被修改，或者当300秒内有10个key被修改，或者当60秒内有10000个key被修改，会触发快照的生成，如下图所示：
如果不希望将数据同步到快照文件中，可以设置为save “”。此外，当执行save，bgsave，flushall，shutdown命令时，也会生成快照文件dump.rdb。
redis生成快照文件的过程为：
1. redis会fork一个子进程作为主进程的副本；
2. 主进程负责接收并处理客户端请求，子进程负责将内存中的数据写入硬盘中的临时文件；
3. 待持久化过程结束后，会用此临时文件替换旧的dump.rdb，到此，一次快照生成完毕。
不难理解，当还没有达到最后一次持久化结束的时间截点，而此时机器发生故障导致宕机，那么最后一次的数据就会丢失。
此外，在redis.conf文件中，还有如下配置项：
stop-writes-on-bgsave-error yes：当后台最后一次保存出错，停止redis的写操作。
rdbcompression yes：当进行持久化时，是否对数据使用LZF算法进行压缩。
rdbchecksum yes：在存储快照后，是否使用CRC64算法进行数据校验。
dbfilename dump.rdb：指定生成的快照文件名为dump.rdb。
dir ./：存储快照文件的路径，./表示当前路径，可以在进入redis服务后通过config get dir查看。
RDB方式的优缺点如下：
优点：
1. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快；
2. RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
缺点：
1. 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
2. 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
AOF
AOF即append only file，在AOF模式下，redis会将每一个收到的写命令（包括flushall命令）都通过write函数追加到文件appendonly.aof中。
默认情况下redis并没有开启AOF，AOF的配置在redis.conf中注释为APPEND ONLY MODE的模块里，如果要开启AOF，需要将appendonly no改为appendonly yes。
现在演示一下，复制一份redis.conf，重命名为redis_aof.conf，在这个文件中设置appendonly yes，并且指定以这个配置文件启动redis服务。
在redis_aof.conf配置文件中，appendfsync指定了redis进行aof持久化的时机，有如下三种方式：
appendfsync always：每次收到写命令就立即强制写入磁盘，性能最低，但是最能保证数据的完整性，不推荐使用
appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
appendfsync no：从不写入，完全依赖os，性能最好，不能保证数据的完整性 redis默认采用appendfsync everysec，如下图所示：
redis对aof新增了一种重写机制，当aof文件大小超过所设定的阈值时，redis会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof手动重写，redis配置的自动重写触发的情景如下：
以上配置信息说明：redis会记录上一次重写时aof文件的大小，默认配置是当aof文件大小超过上次rewrite后大小的一倍且文件大于64mb时触发。如果启动redis后没有发生过重写，记录aof文件的大小就为启动时加载的aof文件大小。
重写的原理：主进程会fork出一条新的进程对文件重写，遍历内存数据，每条记录有一条set语句。实际上，重写aof文件的操作并没有读取旧的aof文件，它只针对内存中当前存在的键值重写一个新的aof文件。
AOF优缺点如下：
优点：
1. 使用 AOF 持久化会让 Redis 变得非常耐久。你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）；
2. Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作；
3. AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
缺点：
1. 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积；
2. 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB，当关闭 fsync 时，可以让 AOF 的速度和 RDB 一样快 ；
RDB和AOF可以同时开启，当两者同时存在时，会优先加载AOF文件，因为在通常情况下AOF保存的数据要比RDB更加完整。
如果RDB或者AOF文件有误，可以分别通过如下命令修复：
redis-check-rdb--fix dump.rdb
redis-check-aof --fix appendonlly.aof
当没有开启AOF模式时，从RDB切换到AOF的步骤：
1. 执行命令
redis-cli config set appendonly yes2. 编辑redis配置文件，设置为appendonly yes。如下图所示：
