Redis两种持久化策略详细介绍
Reids是一个key-value存储系统，为了保证效率，数据缓存在内存中，Redis会周期性的把更新的数据写入磁盘以保证数据的持久化。Redis有两种持久化策略
（1）rdb：直接把内存中的数据保存到一个dump文件中，此文件可以视为快照文件。
（2）aof：把所有对Redis的服务器进行修改的命令都存到一个文件里，犹如备份数据库所生成的数据库脚本。
1、RDB持久化策略介绍
默认情况下，Redis采用rdb的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是dump.rdb。redis.conf配置：
900秒之内，如果超过1个key被修改，则发起快照保存
save 900 1
# 300秒内，如果超过10个key被修改，则发起快照保存
save 300 10
# 1分钟之内，如果1万个key被修改，则发起快照保存
save 60 10000这种方式不能完全保证数据持久化，因为是定时保存，所以当Redis服务器宕机之后，就会丢失一部分数据，而且数据量大，写操作多的情况下，会引起大量的磁盘IO操作，会影响性能。
备注：也可以手工调用命令SAVE或BGSAVE进行数据持久化。Redis SAVE/Bgsave命令用于在后台异步保存当前数据库的数据到磁盘。SAVE/BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。
1.1、RDB的优点
对性能影响最小，因为Redis在保存RDB快照时会fork出子进程进行，几乎不影响Redis处理客户端请求的效率。每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照，作为非常可靠的灾难恢复手段。使用RDB文件进行数据恢复比使用AOF要快很多。
1.2、RDB的缺点
快照是定期生成的，所以在Redis宕机时或多或少会丢失一部分数据。如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力。
2、AOF持久化策略介绍
采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。AOF默认是关闭的，如要开启，进行如下配置：
appendonly yesAOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定。
appendfsync no：不进行fsync，将flush文件的时机交给OS决定，速度最快。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢
appendfsync everysec：折中的做法，交由后台线程每秒fsync一次随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。AOF重写即在AOF文件在一定大小之后，重新将整个内存写到AOF文件当中，以反映最新的状态(相当于bgsave)。这样就避免了，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。
备注：auto-aof-rewrite-min-size表示AOF文件重写最小的文件大小最开始AOF文件必须要达到这个文件时才触发，后面的每次重写就不会根据这个变量了。
2.1、AOF的优点
最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据。AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。
2.1、AOF的缺点
AOF文件通常比RDB文件更大，性能消耗比RDB高，数据恢复速度比RDB慢
3、数据持久化引发的延迟
使用RDB持久化通常会提供比使用AOF更高的性能，但需要注意RDB的策略配置。每一次RDB快照和AOF Rewrite都需要Redis主进程进行fork操作。fork操作本身可能会产生较高的耗时，与CPU和Redis占用的内存大小有关。根据具体的情况合理配置RDB快照和AOF Rewrite时机，避免过于频繁的fork带来的延迟。可以通过INFO命令返回的latest_fork_usec字段查看上一次fork操作的耗时（微秒）。
4、RDB和AOF是冲突还是协作呢？
是协作，不是冲突！当Redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：
如果只配置AOF，重启时加载AOF文件恢复数据；
如果同时配置了RBD和AOF，启动是只加载AOF文件恢复数据；
如果只配置RBD，启动是讲加载dump文件恢复数据；
5、数据持久化建议
大多数应用场景下，建议至少开启RDB方式的数据持久化。另外，Redis对于数据备份是非常友好的，因为你可以在服务器运行的时候对RDB文件进行复制。RDB文件一旦被创建，就不会进行任何修改。当服务器要创建一个新的RDB文件时，它先将文件的内容保存在一个临时文件里面，当临时文件写入完毕时，程序才使用原子性rename系统调用将临时文件替换原来的RDB文件。
总之，Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。在任何时候出现故障，Redis的RDB文件都总是可用的。