Redis怎么从持久化文件里把数据给读出来，恢复那些存着的东西

Redis有两种主要的持久化方式，分别是RDB和AOF，它们生成的文件不同，所以数据恢复的过程和逻辑也不太一样，Redis在启动的时候，会自己去检查这些文件，然后根据一定的规则把数据重新加载到内存里，这样服务启动后,之前保存的数据就又回来了。

我们看RDB方式的恢复过程。

RDB就像是给内存中的数据拍一张快照，然后把这张快照保存到一个叫dump.rdb的文件里（文件名可以在配置文件里改），这个文件里的数据是经过压缩的二进制格式,不是直接能看懂的文本。

当Redis服务器启动时，它会自动去寻找这个dump.rdb文件，它找的路径是由配置文件里的dir参数和dbfilename参数共同决定的，如果dir是/var/lib/redis，dbfilename是dump.rdb，那么Redis就会去/var/lib/redis/dump.rdb这个位置找文件。

找到文件之后，Redis就开始恢复工作了，这个过程大致是这样的：Redis会把这个RDB文件读进内存，然后按照文件里记录的数据结构，一个一个地重新创建出来，因为RDB文件保存的是某个时间点的完整数据副本，所以恢复起来很直接，就是直接把整个数据集加载到内存里，这个过程中，Redis会处于阻塞状态，也就是说，在数据没有完全加载完毕之前，它是不会处理任何来自客户端的命令请求的，如果RDB文件很大，比如有几个GB，那么这次启动过程就会显得比较慢，需要耐心等待它加载完，一旦加载成功，Redis就会开始正常提供服务,此时内存中的数据就和上次拍快照的时候一模一样了。

我们再看AOF方式的恢复过程。

AOF方式和RDB完全不同，它不拍快照，而是像一个日记本，把所有会修改数据的写命令（比如SET, LPUSH, SADD等）一条一条地记录下来，保存到一个叫appendonly.aof的文件里（同样，文件名可配置），这个文件是文本文件，你如果用文本编辑器打开看,基本上能看到一行一行的Redis命令。

Redis启动时，如果开启了AOF功能（默认是关闭的），它会优先使用AOF文件来恢复数据，因为AOF文件通常比RDB文件能保存更完整的数据（可以配置为每秒同步一次或者每次命令都同步），所以Redis认为AOF文件的数据更新、更可靠。

恢复的过程就像是在“重放”或者“复盘”历史操作，Redis会创建一个伪客户端（因为没有真实的网络连接），然后从头到尾地读取AOF文件中的每一条命令，并让这个伪客户端执行一遍，执行这些命令的效果，就是一步步地重建了整个数据库的状态，这就好比你在玩游戏时存了个录像，下次打开录像,游戏角色就会按照你之前的操作重新玩一遍。

由于AOF文件记录的是操作命令，随着服务器运行时间变长，这个文件会变得非常大，而且里面可能有很多重复或无效的操作，比如你先SET了一个key，后来又把它DEL掉了，那么之前的那条SET命令在恢复时就是不必要的，所以Redis提供了AOF重写机制，会生成一个新的AOF文件，这个新文件包含了重建当前数据集所需的最少命令集合，文件会小很多，在恢复时，如果存在重写后的AOF文件，Redis就是读取这个瘦身过的文件来进行恢复,速度会快很多。

说一下当两种文件同时存在时，Redis会怎么选择。

这是一个很关键的点，当Redis启动时，如果发现同时存在RDB文件和AOF文件（即AOF功能是开启的），它会优先使用AOF文件来进行数据恢复，原因刚才提到了，因为AOF文件通常能保证数据的完整性更高，只有在AOF功能被关闭的情况下，Redis才会退而求其次,使用RDB文件来恢复。

Redis从持久化文件恢复数据是一个自动的过程，对于RDB，是直接加载数据快照；对于AOF，是重新执行一遍写命令，你可以通过配置文件来决定使用哪种方式，或者两种都用，服务器启动时会自动处理这一切，目标就是把磁盘上保存的数据尽可能地还原到内存中,让你的服务能够无缝衔接地继续运行。

根据Redis官方文档（来源：Redis Persistence）中的描述，这些恢复流程是Redis内核设计的一部分,确保了在重启后数据的可恢复性。