RDB:
在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里.rdb 保存的是dump.rdb文件
RDB工作原理：
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
，式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
fork :fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）
数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
redis.conf配置位置:
################################ SNAPSHOTTING ################################ //快照
#
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred. # # In the example below the behaviour will be to save: # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed # save <seconds> <changes>
# save 900 1
# save 60 10000
# 分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
......................
命令save或 bgsave
save：save时只管保存，其它不管，全部阻塞
bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
停止rdb: 命令 ：redis-cli config set save ""
AOF:
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作.Aof保存的是appendonly.aof文件
redis.conf配置位置:
############################## APPEND ONLY MODE ############################### 追加 AOF# By default Redis asynchronously dumps the dataset on disk. This mode is # good enough in many applications, but an issue with the Redis process or # a power outage may result into a few minutes of writes lost (depending on # the configured save points). # # The Append Only File is an alternative persistence mode that provides # much better durability. For instance using the default data fsync policy # (see later in the config file) Redis can lose just one second of writes in a # dramatic event like a server power outage, or a single write if something # wrong with the Redis process itself happens, but the operating system is # still running correctly. # # AOF and RDB persistence can be enabled at the same time without problems. # If the AOF is enabled on startup Redis will load the AOF, that is the file # with the better durability guarantees. # # Please check http://redis.io/topics/persistence for more information. appendonly no 默认Aof备份策略关闭 # The name of the append only file (default: "appendonly.aof") appendfilename "appendonly.aof" 默认备份文件名default: "appendonly.aof"
.
.
.
.
工作原理
AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制:
- Redis 执行 fork() ，现在同时拥有父进程和子进程。
- 子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
- 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
- 现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
AOF有备份策略?
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三种方式：
- appendfsync always:每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全
- appendfsync everysec:每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
- appendfsync no: 从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。
- 推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
RDB 与 AOF文件修复
$ redis-check-dump –fix <filename> //dump.rdb文件修复 $ redis-check-aof –fix <filename> //appendonly.aof文件修复
RDB切换为 AOF方式
执行以下两条命令: redis-cli config set appendonly yes redis-cli config set save “”
AOF和RDB之间的相互作用
当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。
RDB 与 AOF的优缺点（区别）
rdb优点:
1)RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份。
2)RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心, 在不考虑数据完整性，一致性的情况下，适合大批量数据的恢复，效率高
3)RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作.
rdb缺点:
1）Redis意外宕机,你可能会丢失几分钟的数据，就会丢失最后一次快照后的所有修改。
2）fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
AOF优点：
1）AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好，一旦出现故障，
你最多丢失1秒的数据.
AOF缺点：
1）对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
2）aof运行效率要慢于rdb,每秒同步策略（appendfsync everysec）效率较好，不同步效率和rdb相同。