共计 4046 个字符，预计需要花费 11 分钟才能阅读完成。
大家好，我是小菜。
一个心愿可能成为 吹着牛 X 谈架构 的男人！如果你也想成为我想成为的人，不然点个关注做个伴，让小菜不再孤独！
本文次要介绍
Redis 的长久化如有须要，能够参考
如有帮忙，不忘 点赞 ❥
微信公众号已开启，小菜良记，没关注的同学们记得关注哦！
最近在面试的路上愈走愈远了，Redis必定是一个热门面试方向。像有几种数据结构？如何实现提早队列？淘汰机制是怎么样的？都快问到麻痹，这些问题还常绕脑梁。那咱们这篇就举一个比拟常见且难度适中的面试题来聊聊。Redis 的长久化策略是怎么样的？
开局问个问题，置信被问到 Redis 长久化 的同学必定不在少数，答对的同学必定也不在少数，有些小伙伴说到 Redis 长久化 必定张口就来，毕竟也就 AOF 和 RDB 两个概念，只有你筹备了面试，就不会被问的太惨。然而你是真的懂还是只是为了应酬面试而去应酬记忆？你晓得 AOF 和 RDB 两个词是什么单词的缩写吗？你落地施行过吗？你真认为面试官听不出来你是背题还是实操吗？如果 4 个问题你中了一半，那无妨往下看看，兴许会有些播种，起码答面试题的时候心中有小菜~！
Redis 长久化
什么是 Redis 长久化？
咱们先别记得往解决方向前行，先明确这道题的意思。
长久化 就是要让数据永恒的保留上来。那什么是 Redis 长久化？那就是把 Redis 保留在内存的数据写到磁盘中，避免服务宕机了内存数据失落问题。那有些小伙伴就说了，那磁盘损坏了，数据怎么长久化？就算多点备份能解决磁盘损坏问题，那如果来个多点失落怎么整？停住停住，咱们这篇讲的是 Redis 内存数据 -> 磁盘的长久化问题，可别指望靠这个问题跟面试官扯半个小时~！
咱们这篇从几个点来阐明 Redis 长久化 问题。
也就三点大的方向，三步走策略解决你的长久化问题。
一、RDB
先来解决开局的问题之一，RDB 是什么单词的全称。RDB（Redis Database Backup file）— Redis 数据备份文件，也称为 Redis 数据快照。
这个玩意就是用来将内存中的所有数据都记录到磁盘中，当 Redis 实例故障重启后，从磁盘读取快照文件，从而复原数据。心田狂喜，看来学的第一个概念就能够解决 Redis 长久化问题~
在学 RDB 之前，咱们先明确两个外围概念 fork 和 cow，上面咱们会解释，这里先卖个关子。
RDB 是 Redis 中默认的长久化机制，依照肯定的工夫将内存中的数据以快照的形式保留到磁盘中，它会产生一个非凡类型的文件 .rdb 数据文件，同时能够通过配置文件中的 save 参数来定义快照的周期.
咱们从配置文件中的两个配置参数动手，首先是 save 配置。
这个指令是由 Redis 主过程来执行 RDB，会阻塞所有命令
咱们在配置文件中找到有对于 sava 的配置
1、
dbfilename dump.rdb该配置项的作用便是用来定义 rdb 文件名（须要留神该名称不能定义为门路，只能定义为文件名称）
当咱们执行完 save 命令后，便可在 redis 文件夹中看到一个 dump.rdb 文件
2、
save <seconds> <changes>该配置项的作用是用来定义多长时间内产生多少次变动便会执行 bgsave，如果是 save "" 则示意禁用 RDB。
咱们接下来关上 save 配置 进行测试
dbfilename dump-test.rdb # 文件名为 dump-test.rdb
save 3600 1 # 在 3600 秒内产生一次更改，便会执行 bgsave咱们通过 redis-cli 进入操作
而后咱们退出后便可在当前目录下看到刚刚生成的 dump-test.rdb 文件
阐明咱们配置是失效的，接着咱们间接重启 Redis，看是否还存在咱们刚刚保留的数据
看到咱们的数据，就阐明 redis 长久化胜利了。而后咱们把刚刚生成的 dump-test.rdb 文件删除后重启 redis
这能够阐明Redis 启动时是靠 .rdb 来复原文件数据的。那咱们下面始终说到的 bgsave，那 bgsave 又是如何执行的呢？
咱们在后面有说过两个概念 fork 和 cow，不晓得是否还有印象，这两个概念便是要害~！
bgsave 开始的时候会 fork 主过程失去一个新的子过程，而 子过程 是 共享 主过程的内存数据的。子过程会将数据写到磁盘上的一个长期的 .rdb 文件中，当子过程写完临时文件后，会将原来的 .rdb 文件替换掉。这个就是 fork 的外围，那什么是 cow 呢？cow 全称 copy-on-write 技术，当主过程执行读操作的时候是拜访共享内存的，而主过程执行写操作的时候，则会拷贝一份数据，执行写操作。
具体流程如下：
这种长久化形式有什么长处呢？
- 不便长久化，只有一个
dump.rdb文件 - 容灾性好，能够将文件保留到平安的磁盘中
- 性能最大化，fork 子过程来实现写操作，让主过程持续解决命令，将 IO 最大化，保障 Redis 的高性能
毛病也是有的：
- 数据安全性低，RDB 是距离一段时间来长久化（save <seconds> <change>），如果长久化期间 Redis 产生故障，那么就会造成数据失落，所以这种形式实用于数据要求不是很谨严的状况下应用
- 保留工夫长，如果数据量很大，保留快照的工夫就会很长，会占用磁盘空间
优劣均沾，斟酌应用
二、AOF
AOF 全称 Append Only File (追加文件)。作用便是 Redis 解决的每一个写命令都会记录在 AOF 文件中，能够看做是命令日志文件。
该性能默认是敞开的，咱们能够在 redis.conf 文件中查看有对于 AOF 相干的配置项
1、
appendonly yes # 开启 AOF 日志记录性能，默认是敞开的2、
appendfilename "appendonly.aof" # AOF 文件的名称以上两个配置项便是用来开启 AOF 日志记录，那么还有个额定的配置项也须要理解
3、
appendfsync everysec # AOF 命令记录的频率该配置项有三个可选值
| 配置项 | 刷盘机会 | 长处 | 毛病 |
|---|---|---|---|
| Always | 同步刷盘 | 可靠性高，简直不会失落数据 | 性能影响较大 |
| everysec | 每秒刷盘 | 性能适中 | 最多失落 1 秒的数据 |
| no | 操作系统管制 | 性能最好 | 可靠性较差，可能失落大量的数据 |
有理解 Mysql 中 relay log 日志的同学，就不会对这种模型很生疏。
原理：它是将写命令追加到 AOF 文件的开端，应用 AOF 长久化须要设置同步选项，从而确保写命令同步到磁盘文件上的机会，这是因为对文件进行写入并不会马上将内存同步到磁盘上，而是先存储到缓存区中，而后由操作系统决定什么时候同步到磁盘。
咱们开启 AOF 记录性能查看下：
能够看出咱们的每一个操作都曾经记录到 AOF 文件中，咱们这边通过重启 Redis 也一样能获取到刚刚存储的数据，阐明长久化是有失效的~
咱们看到下面的 AOF 记录文件是不是感觉很规整？然而在线上环境中越规整反而不好，因为这文件次要是给机器看的，而不是跟咱们看的，因而咱们最好可能进行压缩。
为了解决 AOF 文件体积一直增大的问题，用户能够向 Redis 发送 bgrewriteaof命令，这个命令会通过 通过移除 AOF 文件中的冗余命令 来重写（rewrite）AOF 文件，使 AOF 文件的体积变得尽可能地小。bgrewriteaof的工作原理和 bgsave 创立快照的工作原理十分类似：Redis会创立一个子过程，而后由子过程负责对 AOF 文件进行重写。因为 AOF 文件重写也须要用到子过程，所以快照长久化因为创立子过程而导致的 性能问题和内存占用问题，在 AOF 长久化中也同样存在。
既然存在手动触发压缩，那也存在主动触发压缩，这就得说到配置文件中的两个配置项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb该配置项的意思为当 AOF 文件的体积大于 64MB，并且 AOF 文件的体积比上一次重写之后的体积大了至多一倍（100%）的时候，Redis 将执行 bgrewriteaof 命令。
总结下，它的长处如下：
- 数据安全。AOF 长久化能够配置 appendfsync 属性中的
always，每进行一次写命令操作就会记录到 AOF 文件中一次 - 一致性。通过 append 模型写文件，即便中途服务器宕机，也能够通过
redis-check-aof工具来解决数据一致性问题
毛病如下：
- AOF 文件比 RDB 文件大，而且复原速度慢
- 数据集大的时候比 RDB 文件启动效率低
同样是优劣均沾，斟酌应用
三、两者区别
别离介绍了两者，咱们回顾一下两者有什么区别？
| 方面 | RDB | AOF |
|---|---|---|
| 长久化形式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
| 数据完整性 | 不残缺，两次备份之间会失落 | 绝对残缺。取决于刷盘策略 |
| 文件大小 | 会有压缩，文件体积小 | 记录命令，文件体积很大 |
| 宕机复原速度 | 很快 | 慢 |
| 数据恢复优先级 | 低，因为数据完整性不如 AOF | 高，因为数据完整性更高 |
| 系统资源占用 | 高，大量 CPU 和内存耗费 | 低，次要是磁盘 IO 资源。且 AOF 重写时会占用大量 CPU 和内存资源 |
| 应用场景 | 能够容忍数分钟的数据失落，谋求更快的启动速度 | 对数据安全性要求较高 |
看完下面后，想必对两种长久化机制都有肯定的理解了。两者都有优劣势，那咱们该如何抉择？这里给出几点意见~
- 如果能够忍耐一小段时间内的数据失落，能够应用 RDB 机制，定时生成 RDB 快照，并且 RDB 复原数据集的速度也要比 AOF 复原的速度要快
- 然而如果单单应用 RDB 机制，可能导致失落很多数据，因而咱们须要综合应用 AOF 和 RDB 两种长久化机制，用 AOF 来保证数据不失落，作为数据恢复的第一抉择；用 RDB 来做不同水平的冷备份，在 AOF 文件都失落或损坏不可用的状况下，能够应用 RDB 来进行疾速的数据恢复
- 咱们能够利用 RDB 来疾速复原数据，并用 AOF 来补全数据
咱们到这里就讲述了 Redis 长久化机制的配置，通过这篇文章的学习，我置信到时候面试的时候遇到这个问题也不至于那么不知所措~！
不要空谈，不要贪懒，和小菜一起做个 吹着牛 X 做架构 的程序猿吧~ 点个关注做个伴，让小菜不再孤独。咱们下文见！
明天的你多致力一点，今天的你就能少说一句求人的话！
我是小菜，一个和你一起变强的男人。💋
微信公众号已开启，小菜良记，没关注的同学们记得关注哦！
