关于redis:教你如何让Redis更持久

大家好，我是小菜。
一个心愿可能成为 吹着牛 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 命令记录的频率

该配置项有三个可选值

有理解 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 文件启动效率低

同样是优劣均沾，斟酌应用

三、两者区别

别离介绍了两者，咱们回顾一下两者有什么区别？

看完下面后，想必对两种长久化机制都有肯定的理解了。两者都有优劣势，那咱们该如何抉择？这里给出几点意见~

1. 如果能够忍耐一小段时间内的数据失落，能够应用 RDB 机制，定时生成 RDB 快照，并且 RDB 复原数据集的速度也要比 AOF 复原的速度要快
2. 然而如果单单应用 RDB 机制，可能导致失落很多数据，因而咱们须要综合应用 AOF 和 RDB 两种长久化机制，用 AOF 来保证数据不失落，作为数据恢复的第一抉择；用 RDB 来做不同水平的冷备份，在 AOF 文件都失落或损坏不可用的状况下，能够应用 RDB 来进行疾速的数据恢复
3. 咱们能够利用 RDB 来疾速复原数据，并用 AOF 来补全数据

咱们到这里就讲述了 Redis 长久化机制的配置，通过这篇文章的学习，我置信到时候面试的时候遇到这个问题也不至于那么不知所措~！

不要空谈，不要贪懒，和小菜一起做个 吹着牛 X 做架构 的程序猿吧~ 点个关注做个伴，让小菜不再孤独。咱们下文见！

明天的你多致力一点，今天的你就能少说一句求人的话！
我是小菜，一个和你一起变强的男人。 💋
微信公众号已开启，小菜良记，没关注的同学们记得关注哦！