Redis为什么要持久化
我们知道，Redis中的数据是缓存在内存中的，而一旦机器宕机，内存里面的数据就会丢失，这对于高度依赖缓存的应用来说，是不可接受的，数据一丢失，重新建立缓存十分的消耗性能，于是就有了Redis的持久化。
RDB（redis database）
顾名思义，Redis数据库，就是把Redis中的数据像数据库一样的进行存储。
RDB是Redis默认的持久化方式，这种方式就是把Redis中的数据以快照的形式全量写入快照文件中，默认的文件名为：dump.rdb。
持久化触发方式
save命令方式触发（同步）
127.0.0.1:6379> save
OK
save命令执行的时候，会造成Redis的阻塞，所有的命令都要等待它执行完成。
文件生成策略：生成一个临时文件，等待save命令完成之后用这个临时文件替换dump.rdb文件
不推荐使用，生产环境不允许Redis阻塞
bgsave命令方式触发（异步）
127.0.0.1:6379> BGSAVE
Background saving started
通过Redis给我们的消息可以看出，bgsave命令是异步的，命令执行过程为系统fork一个子进程，这个子进程用来生成RDB文件 。
文件生成策略：与save命令一致
可以使用
自动触发
我们可以在配置文件中进行配置，让Redis自动的持久化。打开Redis的配置文件：redis.conf，以下就是默认的RDB配置
save 900 1 //900秒内有一个key被修改，则发起快照保存，所谓的修改是指key对应的value有更新，或者insert一个新的key
save 300 10 //300秒内10个key被修改
save 60 10000 //60秒内1w个key被修改dbfilename dump.rdb //默认保存的文件名为：dump.rdb
dir /var/lib/redis //默认的保存位置为/var/lib/redis
stop-writes-on-bgsave-error yes //当bgsave命令发生错误时，停止写入
rdbcompression yes //RDB文件采用压缩格式
rdbchecksum yes //对RDB文件进行校验
我们可以更改配置，自定义自动保存快照规则，文件名和保存位置，自动备份的过程与bgsave一致，都是由Redis fork一个子进程，子进程生成RDB文件。
优势
- 备份方便，可以自定义备份方式，全自动，并且可以很容易的把RDB文件移动到其他机器上
- RDB可以最大化Redis性能，主进程接着干活，备份工作由fork出的子进程完成
- RDB在恢复大量数据的时候速度比AOF快
劣势
- 自动备份过程中如果宕机，会丢失一段时间的记录，如果对数据很敏感，那么是不能接受的
- 由于RDB方式是全量备份，当数据很大的时候，fork子进程来完成备份会消耗较多时间
AOF（append only file）
顾名思义，RDB是全量，AOF则是增量，Redis会将收到的写命令追加到文件中。
当然，在突然宕机的情况下，AOF也是会丢失数据的，但是不会有RDB丢失的那么多。
触发方式
我们来看看AOF备份的方式：
appendonly no //是否开启AOF备份
appendfilename "appendonly.aof" //备份的文件名为：appendonly.aof
// If unsure, use "everysec".
// appendfsync always //每收到一条Redis写命令都追加到文件中
appendfsync everysec //每秒把写命令追加到文件中，默认配置
// appendfsync no //从不持久
no-appendfsync-on-rewrite no //aof重写期间是否同步
AOF方式是追加写，不可避免的文件会越来越大，比如我们调用incr key1命令100次，那么AOF文件中就会有100条incr命令，但其实，我们只需要一条set key1 100命令就行了，所以，AOF配置中有以下的重写配置，重写之后，Redis会自动的把类似上面例子的命令进行优化：
// aof重写策略，当AOF文件大于64mb，并且当前文件大小比上次重写文件大100%时，则把AOF文件重写，可以看看配置文件此处的英文注解，说的很清楚
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
AOF重写具体执行过程
- Redis调用fork，这时有了父进程和子进程
- 子进程根据内存中的数据快照（不读取原来的AOF文件），往临时文件中写入重建数据库状态的命令
- 父进程继续处理client请求，除了把写命令追加到原来的AOF文件中，同时把收到的写命令缓存起来，这样，如果子进程重写失败，也没有什么影响
- 当子进程把快照内容写入临时文件完成之后，子进程通知父进程，然后父进程把缓存的写命令也追加到临时文件中
- 父进程把临时文件替换原来的AOF文件，并重命名，后面收到的命令也开始往新的AOF文件中写入
优势
- 相较于RDB而言，丢失的数据没有那么多，更能确保数据的完整性
- 由于采用的是append方式，因此在写入过程出现宕机的情况，也不会对破坏原来的日志文件，如果写入的命令因为宕机问题，只写入了一半，也不用担心，可以使用redis-check-aof工具来进行文件的修复
- AOF文件的可读性较高，由于是append方式，每条命令都可以轻松的读懂，如果不小心执行了FLUSHALL命令，我们只需要在AOF文件最后把该命令删除，就可以恢复所有的数据
劣势
- 尽管有重写功能，AOF文件往往会大于RDB文件
- 由于是append方式，所以AOF的效率没有RDB高，但是，appendfsync everysec模式下的效率也足够了
which one？
说了这么多，那么到底选择哪一个呢？如果你的系统对于数据的敏感性不是那么的高，允许一段时间的数据丢失，那么RDB是适合的。其他情况的话AOF好一点，但是建议是两个都开启，两个都开启的话数据安全性是最高的。
如何从备份文件中恢复数据？
想要恢复数据，只需要把配备份文件放到对应的文件夹下，然后重启Redis即可，其流程图如下：
启动时首先会检查AOF文件是否存在，如果不存在则尝试加载RDB文件，为什么会优先加载AOF呢？因为AOF文件保存的数据更加完整。如果AOF文件有错误怎么办？那么会抛出Redis启动失败。
