来自官网[https://redis.io/topics/persistence]摘要
Redis provides a different range of persistence options:
The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
The AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log on background when it gets too big.
If you wish, you can disable persistence at all, if you want your data to just exist as long as the server is running.
It is possible to combine both AOF and RDB in the same instance. Notice that, in this case, when Redis restarts the AOF file will be used to reconstruct the original dataset since it is guaranteed to be the most complete.
一、RDB( Redis DataBase )
-
RDB持久化概述
(1)在指定时间间隔内，将内存中的数据集快照写入磁盘。
(2)将快照文件直接从磁盘读到内存以恢复数据集。Redis会单独fork一个子进程来进行持久化，会将数据写入至一个临时临时文件dump.rdb。待持久化过程结束，使用这个新的dump.rdb临时文件替换上一次持久化生成的dump.rdb文件。 持久化的整个过程中，主进程不再进行任何IO操作，这就确保了极高的性能。 如果需要进行大规模数据恢复，且对于数据恢复的完整性要求不是非常敏感，那RDB方式比AOF方式更加高效。 RDB最大缺点是最后一次持久化的数据可能丢失。 -
RDB保存的持久化文件是.rdb,默认为dump.rdb。
注：在哪个路径下启动，过程产生的文件如dump.rdb就会保存至该路径*在哪个路径下启动，过程产生的文件如dump.rdb就会保存至该路径 [配置项dir默认为./ ] * -
RDB相关配置位置：参见上一节配置文件"SNAPSHOTTING-快照"部分
-
当发出FLUSHALL命令时，Redis会快速生成当前状态的持久化文件dump.rdb进行替换(类似COMMIT)。因此，FLUSHALL后重启，Redis数据库为空，不是没有读取dump.rdb，而是当前dump.rdb为空
-
如何触发快照持久化
(1)按配置文件中设置自动触发
(2)执行save命令或bgsave命令，即刻持久化生成.rdb文件save与bgsave的区别：
save：只负责保存，其余全部阻塞
bgsave：快照操作在后台异步进行，操作的同时还可以响应客户端请求。通过lastsave命令获取最后一次成功执行快照的时间(3)执行FLUSHALL，但生成的dump.rdb文件为空，没有实际意义
-
如何恢复
将持久化文件dump.rdb移动至Redis启动目录(CONFIG GET dir)并启动服务即可
一定要给dump.rdb做备份以恢复 -
如何修复“损坏”的dump.rdb?
使用Redis工具自动修复：redis-check-rdb --fix dump.rdb -
优势
适合大规模的数据恢复，且对数据完整性和一致性要求不高扫描二维码关注公众号，回复： 4092660 查看本文章
-
劣势
(1) 在一定时间间隔做一次备份，若在两次间隔之间Redis下线，将会丢失最后一次快照后的所有修改。
(2) 调用fork时，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
二、AOF( Apped Only File )
-
RDB已经能够满足大部分应用场景，AOF改进之处在于：将可能丢失的修改的间隔降至一秒
-
AOF持久化概述
(1) 以日志的形式记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不予记录），只许追加文件但不可以改写文件。
(2)类似.sql脚本一样，Redis启动时会读取该文件重构数据集，即Redis重启就根据日志文件的内容将写指令从前到后地执行一次以完成数据的恢复工作。 -
AOF保存的持久化文件是.aof文件，默认是appendonly.aof
-
AOF相关配置位置：参见上一节配置文件"APPEND ONLY MODE-追加模型"部分
-
FLUSHALL属于写命令，也会被加入appendonly.aof。因此与RDB不同，FLUSHALL后重启，Redis数据库为空，不是因为appendonly.aof为空，而是顺序执行appendonly.aof，先SET后被FLUSHALL完成整个恢复过程
-
AOF与RDB可以共存，同时存在时，先加载appendonly.aof。但若appedonly.aof由于某些原因（如网络中断，丢包等）损坏，Redis根本无法启动
-
如何恢复
将持久化文件appendonly.aof移动至Redis启动目录并启动服务即可 -
如何修复“损坏“的appendonly.aof
使用Redis工具自动修复：redis-check-aof --fix appendonly.aof -
重写—Rewrite
(1) appendonly.aof 精简优化机制由于.aof文件不断追加会越来越大，为避免出现这种情况，新增了重写机制。当.aof文件的大小超过所制定阈值时，Redis就会压缩其内容，只保留可恢复数据的最小指令集。使用命令bgrewriteaof即刻重写
(2) 重写原理
当AOF文件持续增长而过大时，Redis会fork出一个新进程来将文件重写。重写appendonly.aof文件的操作，并没有读取之前已存在的aof文件，而是将当前整个内存中的数据内容用命令的方式重写为一个新的appendonly.aof文件后改名(3) 自动触发条件
Redis会记录上次重写的.aof文件大小，默认配置是当前.aof文件是上次重写后大小的一倍(100%)且文件大于64M -
优势
(1)每次修改追加、每秒追加(可能丢失的数据量减少)、不追加
(2) 易读的appendonly.aof -
劣势
(1) 对于相同数据集，appendonly.aof文件远大于dump.rdb，恢复速度慢于dump.rdb
(2) aof运行效率要慢于rdb，每秒同步策略效率比较高，不同步策略效率和rdb相同
三、总结
-
一句话总结
(1)RDB持久化方式：在指定的时间间隔内对当前数据集进行快照存储
(2)AOF持久化方式：记录每次对Redis服务器的“写操作”，以Redis协议追加至文件末尾，当服务器重启时会重新执行这些命令来恢复原始数据。Redis还能对appendonly.aof文件进行后台重写，以放置appendonly.aof文件体积过大 -
若只希望数据在服务器运行时存在（即不需要持久化为磁盘文件,Cache-Only）:
可以关闭所有持久化配置可以关闭所有持久化配置 -
同时开启两种持久化方式 :
这种情况下，由于appendonly.aof文件保存的数据集要比dump.rdb文件保存的数据集更完整，当Redis重启时，会优先载入AOF文件来恢复原始数据 -
是否只使用AOF进行持久化?
Redis作者建议不要，因为RDB更适合用于备份数据（AOF不断变化不利于备份）与快速重启，保留作为“保底”手段。 -
性能建议【转载】
因为RDB文件只用作后备用途，建议只在Slave上进行RDB持久化，且快照间隔设为15分钟即可（只保留save 900 这一条规则）。
若使用AOF:
(1) 好处是在最恶劣的情况下只会丢失不超过2s的数据，启动脚本较简单，只需要load自己的appendonly.aof文件。
(2)代价之一是持续的IO，代价之二是AOF重写时将重写过程中产生的新数据写入新文件造成的组合几乎时不可能避免的。只要硬盘许可，应该尽量减少AOF的重写的频率。(重写AOF的基础大小默认值64M过小，3-5G起步比较合适)
若不适用AOF：仅靠主从复制Master-Slave Replication完全可以实现高可用性。
(1)好处是节省很大程度的IO，并且减少了重写时系统波动。
(2)代价是如果Master/Slave同时下线，将丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件时间戳，载入较新的dump.rdb恢复。