Redis数据恢复利器，磁盘读入那些事儿你得知道

（引用来源：知乎专栏《Redis数据恢复利器，磁盘读入那些事儿你得知道》）

今天咱们来聊聊Redis数据恢复的那些事儿，特别是那个听起来有点神秘的“磁盘读入”过程，你可能知道Redis很快，因为它把数据都放在内存里，但万一服务器断电或者重启了，内存里的数据不就全没了吗？别担心，Redis早就想到了这一点，它提供了两种主要的持久化方式，就像是给内存中的数据拍了两种不同风格的照片，方便出事以后恢复,这两种方式就是RDB和AOF。

先说说RDB，你可以把它理解成一张“全景快照”，Redis会在特定的时间点，比如每隔5分钟如果有100个键发生变化，或者每隔15分钟如果有10个键发生变化，就把当前内存里所有的数据生成一个压缩过的二进制文件，存到磁盘上，这个文件就叫RDB文件，这个过程就像是给整个数据库拍了一张大合照，它的优点是恢复起来特别快，因为直接把整个文件读进内存就行了，文件本身也比较紧凑，节省磁盘空间，但缺点也很明显，你可能会丢数据，比如你设置的是5分钟拍一次快照，要是在拍完快照后第4分59秒服务器宕机了，那这将近5分钟之内更新的数据就全丢了，RDB适合那些对数据完整性要求不是那么极致,但追求快速恢复的场景。

再来看看AOF，它更像是一个“流水账本”或者“操作日志”，Redis会把每一个会修改数据的写命令（比如SET、LPUSH、DEL）都记录到一个文件里，这个文件就是AOF文件，当Redis重启的时候，它不会直接去读数据，而是会把这个日志文件里的命令从头到尾重新执行一遍，这样就能重建出整个数据集，这种方式的好处是数据安全性高很多，你可以配置成每秒钟同步一次日志到磁盘，这样最多也就丢一秒钟的数据，甚至有种最保险的模式，让每个写命令都立刻同步到磁盘，但这样会严重影响性能，AOF的缺点是日志文件通常会比RDB文件大得多，而且恢复数据的时候，重放所有日志命令可能会很慢，特别是当数据库很大、运行了很久之后,那个日志文件可能非常庞大。

Redis重启的时候，到底是怎么恢复数据的呢？这就是“磁盘读入”的关键环节了，其实规则很简单，但又很重要：如果AOF持久化功能是开启的，Redis在启动时会优先使用AOF文件来恢复数据，只有当AOF功能关闭时，它才会去找RDB文件来恢复。

（引用来源：知乎专栏《Redis数据恢复利器，磁盘读入那些事儿你得知道》）

为什么要这么设计呢？因为通常来说，AOF文件能保证更少的数据丢失，它的数据“新鲜度”更高，想象一下，你昨天下午3点拍了一张RDB快照（全景合照），然后从3点到现在所有的操作都记在了AOF日志（流水账）里，现在服务器重启，你肯定希望先根据昨天的合照把基础还原，然后再把今天的流水账一笔一笔加上去，这样才能得到最完整、最新的状态，Redis就是这么做的,它认为AOF文件是更完整的数据来源。

当你启动一个配置了持久化的Redis服务器时，你会看到类似这样的日志信息： “DB loaded from disk: 0.000 seconds” （如果是从RDB恢复） 或者 “DB loaded from append only file: 0.500 seconds” （如果是从AOF恢复）

这个时间长短就能很直观地反映出恢复过程的差异，从RDB恢复通常就是一瞬间的事，而从AOF恢复，如果日志文件很大,可能需要几秒甚至更长时间。

了解了这个机制，你就能更好地规划你的数据安全策略了，如果你一点数据都不能丢，那就应该开启AOF，并设置为每秒同步或者每个命令同步，如果你能接受几分钟的数据丢失，但希望服务器重启像闪电一样快，那么只用RDB可能更合适，很多生产环境为了保险起见，会选择两者同时开启，这样，RDB可以作为AOF的一个紧凑备份，而AOF则确保了数据的实时性，在恢复时，依然是以AOF为主，享受它数据全的好处,同时RDB也能在AOF文件出问题时作为一个备选的恢复手段。

最后提一个有趣的点，因为AOF文件是纯文本格式（实际上是Redis协议的格式），记录的是一个个命令，所以理论上你甚至可以用文本编辑器打开它（如果文件不大的话）看看里面到底记了些什么，这在排查问题的时候有时候能帮上大忙，RDB文件是二进制的,就没法直接看了。

Redis的磁盘读入机制核心就是“AOF优先”，理解了RDB和AOF这两种“照片”的不同特性和恢复时的优先级，你就能更好地驾驭Redis的持久化，确保你的数据安全无忧，下次再看到Redis启动时的那行日志，你就能会心一笑,知道背后发生了什么故事了。

（引用来源：知乎专栏《Redis数据恢复利器，磁盘读入那些事儿你得知道》）