目录
前言
我们都知道Redis 是基于内存的数据库，一旦服务器的进程退出，数据库数据就会随之丢失，这不是我们想看到的，为了避免这个问题，Redis 为我们提供了俩种持久化方案，将数据保存到磁盘上去，避免数据的丢失。
数据的持久化存储是 Redis 的重要特性之一，它能够将内存中的数据保存到本地磁盘中，实现对数据的持久存储。这样即使在服务器发生故障之后，也能通过本地磁盘对数据进行恢复。
RDB
RDB 即快照模式，它是 Redis 默认的数据持久化方式，它会将数据库的快照保存在 dump.rdb 这个二进制文件中。
RDB持久化产生的RDB文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态。
RDB 持久化提供了两种触发策略：一种是手动触发，另一种是自动触发。
手动触发是通过SAVAE命令或者BGSAVE命令将内存数据保存到磁盘文件中。
SAVE：阻塞redis的服务器进程 ，直到RDB文件被创建完毕。BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号 给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。
自动触发策略，是指 Redis 在指定的时间内，数据发生了多少次变化时，会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中：
# 以下配置表示的条件：
# 服务器在900秒之内被修改了1次
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000- save 900 1 表示在 900 秒内，至少更新了 1 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
- save 300 10 表示在 300 秒内，至少更新了 10 条数据，Redis 自动触 BGSAVE 命令，将数据保存到硬盘。
- save 60 10000 表示 60 秒内，至少更新了 10000 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
优点
1.RDB是二进制压缩文件，占用空间小，便于传输（传给slaver）；
2.主进程fork子进程，可以最大化Redis性能；
3.使用RDB文件来恢复数据较快。
缺点
1、不保证数据完整性，会丢失最后一次快照以后更改的所有数据；
2、父进程在fork子进程的时候如果主进程比较大会阻塞；
AOF
AOF 被称为追加模式，或日志模式，是 Redis 提供的另一种持久化策略，它能够存储 Redis 服务器已经执行过的的命令，并且只记录对内存有过修改的命令，这种数据记录方法，被叫做"增量复制"，其默认存储文件为appendonly.aof。
具体配置可以在配置文件中进行配置：
#AOF 和 RDB 持久化方式可以同时启动并且无冲突。
#如果AOF开启，启动redis时会加载aof文件，这些文件能够提供更好的保证。
appendonly yes
# 只增文件的文件名称。（默认是appendonly.aof）
# appendfilename appendonly.aof
#redis支持三种不同的写入方式：
#
# no:不调用，之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。
# always: 每次更新数据都写入仅增日志文件。慢，但是最安全。
# everysec: 每秒调用一次。折中。
appendfsync everysec
# 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no
# 自动重写只增文件。
# redis可以自动盲从的调用'BGREWRITEAOF'来重写日志文件，如果日志文件增长了指定的百分比。
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb服务器配置中有一项appendfsync，这个配置会影响服务器多久完成一次命令的记录：
always：将缓存区的内容总是即时写到AOF文件中。everysec：将缓存区的内容每隔一秒写入AOF文件中。no：写入AOF文件中的操作由操作系统决定，一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。
redis默认实用的是everysec。
在RDB和AOF备份文件都有的情况下，redis会优先载入
AOF备份文件
Redis 在长期运行的过程中，aof 文件会越变越长。如果机器宕机重启，"重演"整个 aof 文件会非常耗时，导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下"瘦身"运动。Redis 提供了 AOF 重写机制，手动执行BGREWRITEAOF命令，开始重写 aof 文件
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started- 新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致；
- 新的 aof 文件会使用尽可能少的命令来记录数据库数据，因此新的 aof 文件的体积会小很多；
- AOF 重写期间，服务器不会被阻塞，它可以正常处理客户端发送的命令
优点
- 更好的保护数据不丢失，性能高，可做紧恢复
缺点
- 等量级的命令，AOF持久化文件要大于RDB持久化文件
- 恢复速度慢于RDB
总结
| RDB持久化 | AOF持久化 |
|---|---|
| 全量备份，一次保存整个数据库。 | 增量备份，一次只保存一个修改数据库的命令。 |
| 每次执行持久化操作的间隔时间较长。 | 保存的间隔默认为一秒钟（Everysec） |
| 数据保存为二进制格式，其还原速度快。 | 使用文本格式还原数据，所以数据还原速度一般。 |
| 执行 SAVE 命令时会阻塞服务器，但手动或者自动触发的 BGSAVE 不会阻塞服务器 | AOF持久化无论何时都不会阻塞服务器。 |
如果进行数据恢复时，既有 dump.rdb文件，又有 appendonly.aof 文件，您应该先通过 appendonly.aof 恢复数据，这能最大程度地保证数据的安全性。