Redis 持久化 问题
前言
相关系列
- 《Redis & 目录》（持续更新）
- 《Redis & 持久化 & 源码》（学习过程/多有漏误/仅作参考/不再更新）
- 《Redis & 持久化 & 总结》（学习总结/最新最准/持续更新）
- 《Redis & 持久化 & 问题》（学习解答/持续更新）
参考文献
- 《Redis的持久化详解》
Redis有哪些持久化机制？各自的优缺点是什么？
RDB @ Redis DataBase @ Redis数据库
RDB机制的本质是将Redis某时刻的数据保存为快照文件，从而得以在Redis重启时将数据恢复至快照文件所记录的时刻…该机制的优/缺点具体如下：
- 文件体量小：RDB快照文件体量相对较小，对磁盘的占用率不高；
- 数据恢复快：RDB快照文件以二进制格式保存数据，因此其数据恢复速度很快；
- 性能影响小：RDB快照文件由子进程异步生成，因此不会阻塞主进程的内存读/写。
- 数据完整性低：RDB快照文件无法记录生成期间并发产生的数据变动，因此宕机时该部分数据的会丢失；
- 文件可读性差：RDB快照文件以二进制格式保存数据，因此难以手动地去修改/修复数据。
AOF @ Append Only File @ 只追加文件
AOF机制的本质是在日志文件中记录Redis执行的每条写指令，从而得以在Redis重启时通过重演指令以实现数据恢复…该机制的优/缺点具体如下：
- 数据完整性高：AOF日志文件会实时记录Redis执行每条写指令，因此其数据完整性是接近完全的。而如果再将写回机制设置为always，那么“理论上”其甚至可以不丢失数据；
- 文件可读性高：AOF日志文件的会明文直接保存指令，因此可以对修复/修改的手动行为支持度很高；
- 性能影响小：指令由操作系统异步写入AOF日志文件，因此不会阻塞主进程的内存读/写。但重写时会短暂阻塞，这是因为主进程会负责新/旧AOF日志文件的替换来保证安全。
- 文件体量大：AOF日志文件的体量会持续正大，对磁盘的占用率较高；
- 数据恢复慢：庞大的AOF日志文件代表着同样庞大的指令数量，因此重演这些指令需要耗费相当长的时间；
- 文件易损坏：AOF日志文件会持续写入，因此其遭遇磁盘损坏/系统宕机等原因而同步损坏的概率也较高，故而AOF机制往往要搭配RDB机制一同使用。
在RDB/AOF都开启的情况下Redis会如何恢复数据？
在RDB/AOF都开启的情况下，Redis启动时会优先使用AOF日志文件恢复数据，因为其数据完整性理论上会高于RDB快照文件。
如何为Redis选择最合适的持久化机制？
对于单纯将Redis作为缓存使用的程序而言通常不需要开启持久化机制；而对于数据完整性要求不高，即可以接受分钟级别数据丢失的程序而言一般只需开启RDB机制即可；而对于数据完整性较高的程序而言通常会同时开启RDB&AOF机制，这其中RDB机制是作为AOF机制失效是的备用手段存在的，因为AOF日志文件在持续写入的过程中有较大的概率出现损坏。此外如果对数据完整性的要求极高，那么还推荐将AOF机制的写回机制设置为always，这样Redis在宕机时丢失的数据可以达到最少，甚至有较大概率不丢失数据。