【大厂秘籍】 - Redis持久化篇

创作不易，你的关注分享就是博主更新的最大动力， 每周持续更新

微信搜索【 企鹅君】关注还能领取学习资料喔，第一时间阅读(比博客早两到三篇)

求关注?? 求点赞?? 求分享?? 对博主真的非常重要

企鹅君原创｜GitHub开源项目github.com/JavaDance 欢迎Star和完善

面试开始

激动的心，颤抖的手, 你打开了面试官发过来的远程面试链接

对面是一位身穿格子衬衫的有点中年发福的男子，

看着屏幕上面试官反光的头顶，一寸亮，一寸强！啧啧，你瞬间就感受面试官的实力恐怖如斯~~

但是你也不慌，因为你早已看了多遍《大厂秘籍》，再见面试官都是小场面

面试官从你的项目聊到了Java知识、数据库， 然后就到了面试基本必问的Redis

你心想这不踢到钢板了吗， 公司同事都尊称你是「Redis小王子」

但你还是忍住了心中的沸腾，面色平静、假装着小白等着面试官提问

面试官: 小伙汁， Redis有几种持久化选项，你知道吗

Redis 是一种内存数据库，读写效率快。但是一旦进程退出，Redis 内存数据就会丢失。为了解决这个问题
Redis 提供了4种持久化选项，将数据写入保存到本地磁盘

1. RDB （Redis DataBase, Redis 数据库）默认的持久化方式

2. AOF（Append Only File, 仅追加文件）

3. RDB + AOF（混合持久化）

4. No persistence（无持久化), 一些简单的业务场景也可以选择关闭持久化RDB

那你讲讲RDB和AOF

RDB

RDB是Redis默认的持久化方式（Redis DataBase, Redis 数据库）。（Redis DataBase, Redis 数据库）按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。
RDB 触发机制分为使用指令手动触发和配置自动触发。
手动触发方式:
● save 命令 ，该指令会阻塞当前 Redis 服务器，执行 save 指令期间，Redis 不能处理其他命令，直到 RDB 过程完成为止。
● bgsave 命令，执行该命令时，Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。，此时 Redis 仍然可以相应客户端请求。
配置自动触发方式 ：
redis.conf 默认配置

save 900 1 # 表示900 秒内如果至少有 1 个 key 的值变化，则触发RDB
save 300 10 # 表示300 秒内如果至少有 10 个 key 的值变化，则触发RDB
save 60 10000 # 表示60 秒内如果至少有 10000 个 key 的值变化，则触发RDB

AOF

AOF持久化（Append Only File, 仅追加文件），是将Redis执行的每次写命令记录到单独的日志文件中，然后可以在服务器重启时重新执行这些操作，从而恢复数据。

AOF 持久化功能的实现可以分为5步:

1. 命令追加（append）：所有的写命令会追加到 AOF 缓冲中。
2. 文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数（系统调用）, 此时并没有同步到磁盘。
3. 文件同步（fsync）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
4. 文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
5. 重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。
   AOF写入内容
   当 AOF 持久化功能处于打开状态时，Redis 在执行完一个写命令之后，被执行的写命令追加到 Redis 服务端维护的 AOF 缓冲区末尾。
   比如说 SET mykey myvalue 这条命令就以如下格式记录到 AOF 缓冲中。

"*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n"

AOF之所以直接采用文本协议格式，是因为所有写入命令都要进行追加操作，直接采用协议格式，避免了二次处理开销。

小伙汁不错嘛，答得这么流畅，看来是没少看《大厂秘籍》，接着就问到:AOF 持久化方式有哪些？

AOF持久化方式有三种，可以在Redis配置文件中设置 appendfsync 选项的值。

1. append fsync always: Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件，并且同步 AOF 文件，所以 always 的效率是 appendfsync 选项三个值当中最差的一个，但从安全性来说，也是最安全的。当发生故障停机时，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。
2. appendfsync everysec:Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件中，并且每隔一秒就要在子线程中对 AOF 文件进行一次同步。从效率上看，该模式足够快。当发生故障停机时，只会丢失一秒钟的命令数据。
3. appendfsync no：永远不会fsync，只需将您的数据交给操作系统即可。更快但安全性较低的方法。通常 Linux 会使用此配置每 30 秒刷新一次数据

appendfsync的三个值代表着三种不同的调用 fsync的策略。
建议（和默认）的策略是``appendfsync everysec。它既快速又相对安全。always`策略在实践中非常慢。
AOF 重写

AOF重写有了解过吗

1. 因为 AOF 持久化是通过保存被执行的写命令来记录 Redis 状态的，所以随着 Redis 长时间运行，AOF 文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的 AOF 文件很可能对 Redis 甚至宿主计算机造成影响。
   为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 文件重写( rewrite) 功能。通过该功能，Redis 可以创建一个新的 AOF 文件来替代现有的 AOF 文件。新旧两个 AOF 文件所保存的 Redis 状态相同，但是新的 AOF 文件不会包含任何浪费空间的荣誉命令，所以新 AOF 文件的体积通常比旧 AOF 文件的体积要小得很多。

如上图所示，重写前要记录名为list的键的状态，AOF 文件要保存五条命令，而重写后，则只需要保存一条命令。

那到底应该怎么选择Redis持久化呢

● 如果可以忍受灾难发生时几分钟的数据丢失，建议单独使用 RDB。
● 不建议单独使用 AOF，因为时不时地创建一个 RDB 快照可以进行数据库备份、可以更快的重启恢复数据
● 如果对数据要求安全性比较高的话（不能丢失），建议使用 RDB 和 AOF 混合持久化。

（答得这么好，都有点佩服自己了， 读者朋友们到这赶紧点点赞）

面试结束

小伙汁你针不戳，给你发Offer了，能不能早点来公司上班呀

你心想自己手里还有几个其他大厂的Offer呢，还得问下网友考虑选哪个好呢

你当然没把心里话说出来，假装镇定回复合适的话，争取早点来公司。

好的。面试官 心想这小伙汁有点东西，必须把他招进公司，赶紧联系hr给他工资加满。

你感叹《大厂秘籍》果然有用，再也不用担心没有Offer了

赶紧让你的小伙伴也分享点赞收藏！！！

总结

**技术面试其实并不难，但是也没有什么捷径，（当然博主希望《大厂秘籍》可以帮助读者少走弯路）平时多看多总结。在面试的时候，可以试着通过自己的项目引导面试官向你熟悉的领域提问，比如你的简历项目里写到了使用Redis解决了XX问题，这时候面试官基本都会问你更细节的东西，这样在你提前准备下逻辑清晰, 有理有据的讲出如何解决问题会在面试官心里加不少分, 那一个个Offer还不到手就来!_! **

参考

● Redis persistence - Redis 官方文档：https://redis.io/docs/management/persistence/
● Redis AOF 持久化详解 - 程序员历小冰：http://remcarpediem.net/article/376c55d8/

创作不易，你的关注分享就是博主更新的最大动力， 每周持续更新

微信搜索【 企鹅君 】第一时间阅读(比博客早一到两篇), 关注还能领取资料

求关注?? 求点赞?? 求分享?? 对博主真的非常重要

企鹅君原创｜GitHub开源项目github.com/JavaDance 欢迎Star和完善

本文由mdnice多平台发布