---恢复内容开始---
RDB:在指定的时间间隔对redis中的数据进行快照存储，默认开启
AOF:记录每次操作redis的命令，将命令写入到AOF文件中，当重启redis时会重新执行这些命令来恢复数据，默认关闭。
RDB方式：
Redis会根据redis.conf配置文件定期将数据快照至一个RDB文件中：
save [seconds] [changes]:意为每seconds秒内如果数据有changes次修改，那么就进行一次rdb快照存储。可配置多条save指令，让redis执行多级的快照保存策略。
RDB工作原理：RDB持久化是指在指定的时间间隔内对内存中的数据进行一次快照存储,写入本地磁盘中。实际操作过程是先fork一个子进程，再将数据写入到一个临时文件中，写入成功后，再将之前的文件替换，用二进制压缩存储的。RDB是redis默认的持久化方式，会在对应的目录下产生一个dump.rdb的文件，重启redis会加载这个dump.rdb文件，恢复原始数据。
RDB的触发分为两种：手动触发和自动触发。
手动触发可以是：
save: 该命令会阻塞redis,在sava期间，不能执行其他命令，直到持久化完成。
bgsave:该命令不会阻塞redis，在后台进行的。该触发方式会fork一个子进程，由子进程负责持久化，因此阻塞只会发生在fork子进程的时候。
自动触发：
save m n:根据redis配置文件配置规则自动触发。
从节点全量复制时，主节点发送一个rdb文件给从节点完成复制操作时，主节点会触发bgsave。
执行debug reload时自动触发RDB持久化。
执行shutdown时，若没有开启aof 也会触发RDB持久化。
注意：fork操作会阻塞redis，导致redis读写性能下降，我们可以通过控制单个redis实例的最大内存，来尽可能降低fork时的消耗。也可通过减少自动触发的频率，减少fork次数。
RDB优点：
对性能影响最小：因为它会fork一个子进程来完成持久化操作，几乎不影响redis处理客户端请求的效率。
他可以按照每小时，每分钟，每天来进行快照存储，可以作为一种可靠的灾难恢复手段。
数据恢复比AOF要快很多。
RDB缺点 ：
如果更新数据后，还没来得及持久化，redis就宕机了，那么更新的数据就会丢失。
如果redis中的数据非常多且CPU处理能力不足的情况下，在fork子进程的时候就会消耗更长的时间，这时若对redis进行额外的操作的话，redis处理这个操作的时间就更长。
AOF方式:
- AOF工作原理
采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。
AOF的整个流程大体分为两步，一步是命令的实时写入（如果是 appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写（重写是直接把当前内存的数据生成对应命令）。
对于增量追加到文件这一步主要的流程是：命令写入=》追加到aof_buf =》同步到aof磁盘。那么这里为什么要先写入buf在同步到磁盘呢？如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。
aof重写的目的是为了减少aof文件的大小，可以手动或者自动触发。
手动触发： bgrewriteaof，自动触发 就是根据配置规则来触发。
- AOF如何配置：
AOF默认是关闭的，如要开启，进行如下配置：appendonly yes。AOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定：
appendfsync no：不进行fsync，将flush文件的时机交给OS决定，速度最快
appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢
appendfsync everysec：折中的做法，交由后台线程每秒fsync一次
随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大，也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。
AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
上面两行配置的含义是，Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。
AOF的优点：
最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据。
AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。
AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。
AOF的缺点：
AOF文件通常比RDB文件更大
性能消耗比RDB高
数据恢复速度比RDB慢
---恢复内容结束---