教你如何让Redis更持久！

大家好，我是小菜。一个希望能够成为 吹着牛X谈架构 的男人!如果你也想成为我想成为的人，不然点个关注做个伴，让小菜不再孤单!

最近在面试的路上愈走愈远了，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. dbfilenamedump.rdb

该配置项的作用便是用来定义 rdb 文件名(需要注意该名称不能定义为路径，只能定义为文件名称)

当我们执行完 save 命令后，便可在 redis 文件夹中看到一个 dump.rdb 文件

1. save

该配置项的作用是用来定义多长时间内发生多少次变化便会执行 bgsave，如果是 save "" 则表示禁用 RDB。

我们接下来打开 save 配置进行测试

1. dbfilenamedump-test.rdb#文件名为dump-test.rdb
2. save36001#在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) ，如果持久化期间 Redis 发生故障，那么就会造成数据丢失，所以这种方式适用于数据要求不是很严谨的情况下使用
• 保存时间长，如果数据量很大，保存快照的时间就会很长，会占用磁盘空间

优劣均沾，斟酌使用

二、AOF

AOF 全称 Append Only File (追加文件)。作用便是 Redis 处理的每一个写命令都会记录在 AOF 文件中，可以看做是命令日志文件。

该功能默认是关闭的，我们可以在 redis.conf 文件中查看有关于 AOF 相关的配置项

1. appendonlyyes#开启AOF日志记录功能，默认是关闭的

1. appendfilename"appendonly.aof"#AOF文件的名称

以上两个配置项便是用来开启 AOF 日志记录，那么还有个额外的配置项也需要了解

1. appendfsynceverysec#AOF命令记录的频率

该配置项有三个可选值

有了解 Mysql 中 relay log 日志的同学，就不会对这种模型很陌生。

原理：它是将写命令追加到 AOF 文件的末尾，使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机，这是因为对文件进行写入并不会马上将内存同步到磁盘上，而是先存储到缓存区中，然后由操作系统决定什么时候同步到磁盘。

我们开启 AOF 记录功能查看下：

可以看出我们的每一个操作都已经记录到 AOF 文件中，我们这边通过重启 Redis 也一样能获取到刚刚存储的数据，说明持久化是有生效的~

我们看到上面的 AOF 记录文件是不是觉得很规整?但是在线上环境中越规整反而不好，因为这文件主要是给机器看的，而不是跟我们看的，因此我们最好能够进行压缩。

为了解决AOF文件体积不断增大的问题，用户可以向Redis发送 bgrewriteaof命令，这个命令会通过 通过移除AOF文件中的冗余命令 来重写(rewrite)AOF文件，使AOF文件的体积变得尽可能地小。bgrewriteaof的工作原理和 bgsave 创建快照的工作原理非常相似：Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF持久化中也同样存在。

既然存在手动触发压缩，那也存在自动触发压缩，这就得说到配置文件中的两个配置项

1. auto-aof-rewrite-percentage100
2. auto-aof-rewrite-min-size64mb

该配置项的意思为当AOF文件的体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍(100%)的时候，Redis将执行bgrewriteaof命令。

总结下，它的优点如下：

• 数据安全。AOF 持久化可以配置 appendfsync 属性中的 always，每进行一次写命令操作就会记录到 AOF 文件中一次
• 一致性。通过 append 模型写文件，即使中途服务器宕机，也可以通过 redis-check-aof 工具来解决数据一致性问题

缺点如下：

• AOF 文件比 RDB 文件大，而且恢复速度慢
• 数据集大的时候比 RDB 文件启动效率低

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

三、两者区别

分别介绍了两者，我们回顾一下两者有什么区别?

看完上面后，想必对两种持久化机制都有一定的了解了。两者都有优劣势，那我们该如何选择?这里给出几点意见~

如果可以忍受一小段时间内的数据丢失，可以使用 RDB 机制，定时生成 RDB 快照， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快

但是如果单单使用 RDB 机制，可能导致丢失很多数据，因此我们需要综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择;用 RDB 来做不同程度的冷备份，在 AOF 文件都丢失或损坏不可用的情况下，可以使用 RDB 来进行快速的数据恢复

我们可以利用 RDB 来快速恢复数据，并用 AOF 来补全数据

我们到这里就讲述了 Redis 持久化机制的配置，通过这篇文章的学习，我相信到时候面试的时候遇到这个问题也不至于那么手足无措~!

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

原文链接：https://mp.weixin.qq.com/s/Xcw_xLodEiS7K8VFVS3u-w