【怒怼大厂面试官】你说精通Redis？来讲讲Redis持久化

面试官：听说你精通Redis，那我就考考你吧

面试官：不用慌尽管说，错了也没关系😊。。。

面试官：知道Redis持久化吗

嗯嗯知道的，Redis提供了RDB持久化、AOF持久化。

前者是保存了整个Redis数据库状态、而后者是保存了从Redis启动后所有执行的命令。

面试官思考中...

面试官：那你说一说Redis生成RDB文件的命令是什么

好的，有两个，一个是SAVE命令，一个是BGSAVE命令。

面试官思考中...

面试官：是你的话，你会在什么场景使用什么命令

是这样的，SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。

而BGSAVE命令则不进行阻塞，它会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程继续处理命令请求。

如果是在业务高峰期的话要使用RDB的保存命令，建议是使用后者，可以防止某些请求丢失了。

面试官停顿了一会......，大概在思考怎么为难你，激发你的潜力！！！

面试官：知道AOF文件重写吗

嗯嗯知道的。AOF文件重写主要是为了解决AOF文件体积膨胀的问题。

对于一个键值对，AOF旧的文件会保存数十条对该键值对的修改命令，这样浪费了大量内存空间。

而AOF文件重写主要是可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令。

简单来说，就是新的AOF文件只会保存键值对的最终状态的创建命令。

面试官心想：得抓个机会好好怼你

面试官：那照你这么说，只会保存创建命令，那每个键的创建只有一条命令对吧

噢噢不是的。这样的话在执行命令时可能会造成客户端输入缓冲区溢出。

所以Redis重写程序在处理列表、哈希表、集合、有序集合这四种可能会带有多个元素的键时，如果元素的数量超过了redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值，那么重写程序将使用多条命令来记录键的值。

而不是一定就使用一条命令。

面试官心想：还不错，继续问

面试官：那你说说AOF重写过程中，有新的创建请求进来怎么办

可以把这些新的创建请求写入到一个缓冲区里。

是这样，Redis服务器会维护一个AOF重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。

等新的AOF文件创建完成，Redis服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，来保证两个新旧AOF文件状态一致。

面试官抓抓脑袋，继续看你的简历......

未完待续。。。。。。

创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️