Redis持久化
因为AOF文件的更新频率通常比RDB文件的更新频率高，所以如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态。只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。
redis持久化：
两种方式：rdb（redis database）和aof（append of file）
RDB：
在指定时间间隔内，将内存中的数据作为一个快照文件（snapshot）写入到磁盘，读取的时候也是直接读取snapshot文件到内存中
①持久化过程：redis单独创建（fork）一个进程来持久化，会先将数据写入临时文件中，待上次持久化结束后，会将该临时文件替换上次持久化文件，比aof高效，但是最后一次数据可能会丢失
②Fork：在linux中，fork（）会产生一个跟主进程一样的子进程，出于效率考虑，主进程和子进程会公用一段物理内存，当发生改变的时候，才会把主进程“”写时复制”一份给子进程
③Redis备份的文件：在redis.conf中设置，dbfilename默认为：dump.rdb
Redis提供了save和bgsave两个命令来生成RDB文件（即将内存数据写入RDB文件中），执行成功后我们在磁盘中找到该RDB文件（dump.rdb）
有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE。
两者区别：
SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求；
BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求；
创建RDB文件的实际工作由rdb.c/rdbSave函数完成，SAVE命令和BGSAVE命令会以不同的方式调用这个函数
手动快照：
如果没有触发自动快照，可以对redis进行手动快照操作，SAVE和BGSAVE都可以执行手动快照，两个命令的区别是前者是由主进程进行快照操作，会阻塞其他请求；而后者是通过fork子进程进行快照操作。
注意：
由于redis使用fork来复制一份当前进程，那么子进程就会占有和主进程一样的内存资源，比如说主进程8G内存，那么在备份的时候必须保证有16G内存，要不然会启用虚拟内存，性能非常差。
RDB文件中存放的是二进制数据
④ Rdb保存策略：
900s 1 file change
300s 10file change
60s 10000file change
⑤Rdb的备份：
config get dir 得到备份的文件夹
复制备份文件
⑥Rdb恢复：
关闭redis
将备份文件复制到工作目录下
启动redis，自动加载
AOF :
以日志形式记录每个写操作，启动时通过日志恢复操作
开启AOF：默认不开启，进入redis.conf找到appendonly yes打开
修复AOF：redis-check-aof –fix appendonly.aof
同步频率：每秒记录一次，如果宕机该秒记可能失效
Rewrite：bgrewrite aof 因为日志是追加方式，文件会越来越大，当超过了设置的阈值时，日志文件会压缩，保留仅可以恢复的日志
AOF重写
重写是为了解决AOF文件越来越大的问题，所以需要将他的体积缩小。
AOF文件重写的实现
首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是AOF重写功能的实现原理。
如：
redis> SADD animals "Cat"
// {"Cat"}
(integer) 1
redis> SADD animals "Dog" "Panda" "Tiger" // {"Cat", "Dog", "Panda", "Tiger"}
(integer) 3
redis> SREM animals "Cat" // {"Dog", "Panda", "Tiger"}
(integer) 1
redis> SADD animals "Lion" "Cat" // {"Dog", "Panda", "Tiger",
(integer) 2 "Lion", "Cat"}
可以用：
SADD animals"Dog""Panda""Tiger""Lion""Cat" 命令代替。
aof的重写是也是放在子程序中进行。不过，使用子进程也有一个问题需要解决，因为子进程在进行AOF重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的AOF文件所保存的数据库状态不一致。
为了解决这种数据不一致问题，Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区，如图所示：
这也就是说，在子进程执行AOF重写期间，服务器进程需要执行以下三个工作：
1）执行客户端发来的命令；
2）将执行后的写命令追加到AOF缓冲区；
3）将执行后的写命令追加到AOF重写缓冲区。
这样一来可以保证：
a、AOF缓冲区的内容会定期被写入和同步到AOF文件，对现有AOF文件的处理工作会如常进行。
b、从创建子进程开始，服务器执行的所有写命令都会被记录到AOF重写缓冲区里面。
当子进程完成AOF重写工作之后，它会向父进程发送一个信号，父进程在接到该信号之后，会调用一个信号处理函数，并执行以下工作：
1）将AOF重写缓冲区中的所有内容写入到新AOF文件中，这时新AOF文件所保存的数据库状态将和服务器当前的数据库状态一致。
2）对新的AOF文件进行改名，原子地（atomic）覆盖现有的AOF文件，完成新旧两个AOF文件的替换。
这个信号处理函数执行完毕之后，父进程就可以继续像往常一样接受命令请求了。
注意：
在整个AOF后台重写过程中，只有信号处理函数执行时会对服务器进程（父进程）造成阻塞，在其他时候，AOF后台重写都不会阻塞父进程，这将AOF重写对服务器性能造成的影响降到了最低。
=================================================================
RDB优点：
节省磁盘空间
恢复速度快
缺点：
数据太大时，比较消耗性能
一段时间保存一次快照，宕机时最后一次可能没有保存
AOF优点：
备份机制更加稳健
可读的日志文件，通过aof恢复更加稳健，可以处理失误
缺点：
比RDB更占磁盘
备份速度较慢
每次都同步日志，有性能压力
RDB和AOF哪个好
官方推荐都启用
对数据不敏感，单独用RDB
不建议单独使用AOF
若作为纯缓存使用，可以都不开启