一文读懂Redis持久化机制

徐俊生

已于 2022-07-05 16:57:29 修改

阅读量1.5k

点赞数

分类专栏： Redis 文章标签： redis redis持久化 rdb aof

于 2021-11-16 00:18:31 首次发布

本文链接：https://blog.csdn.net/D812359/article/details/121194922

版权

Redis 专栏收录该内容

12 篇文章 3 订阅

订阅专栏

一文读懂Redis持久化机制

AOF日志
RDB
两种持久化方式对比
混合持久化

我们日常开发中，使用Redis的普遍场景就是用作缓存。也就是把后端数据库的数据存储在内存中，然后从内存读取数据，响应速度会非常的快。并且使用缓存还会降低数据库的访问压力。但是这里也有一个绝对不能忽视的问题：一旦服务器宕机，内存中的数据就会全部丢失。

为了保证数据的持久性，Redis提供了两种持久化方案：AOF日志和RDB快照。我们可以根据实际情况，在项目中灵活配置。

下面我们首先来看看AOF日志。

AOF日志

AOF（Append Only File），它记录了Redis收到的每一条命令，并以文本形式保存。

AOF相关配置

Redis默认不开启AOF持久化方式，我们可以修改redis.conf文件配置开启：

# 开启aof机制
appendonly yes

# aof文件名
appendfilename "appendonly.aof"

# 写入策略 默认 everysec
# appendfsync always
appendfsync everysec
# appendfsync no

# 自动重写配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 保存目录
dir ./

AOF是写后日志。跟MySQL的写前日志（WAL）相反。写前日志指的是，在实际写数据前，先把修改的数据记录到日志文件，以便故障时进行恢复。写后的意思是，Redis先执行命令，把数据写入内存，然后再记录日志到磁盘。

看到这里，我们就要想了，为什么AOF要先执行命令，再记日志呢？

Redis为了避免额外的性能开销，再向AOF里面记日志的时候，并不会先去检查命令的语法正确性，而是先让系统执行命令，只有执行成功之后，这条才会被记录下来，否则，系统就会报错。所以写后日志好处之一就是，防止出现错误命令的问题。

此外，另一个好处就是，因为是在命令执行之后，才去记录日志，所以不会阻塞当前的写操作。

当然了写后日志也会带来一定风险。

首先第一个：数据丢失。如果执行完一个命令，还没来得及写日志系统就发生宕机了，此时就会发生数据丢失的风险。

其次，AOF日志是在主线程中执行的，如果在日志写入磁盘的时候，磁盘写压力大，就会导致写盘很慢。我们都知道，redis是单线程的，如果主线程发生阻塞，就导致后续的操作都无法进行。

那么如何解决这两个风险呢？

聪明的你应该发现了，这两个风险都跟AOF写回磁盘的时机相关。如果我们能找到一种合适的时机，这两个风险是不是就能避免呢？我们继续看。

AOF的持久化实现

AOF的持久化实现分为三个步骤：

命令追加：当 AOF 持久化功能被打开时，服务器执行完一个写命令之后，会议协议格式将被执行的命令追加到 aof_buf 缓冲区的末尾；
文件写入：将 aof_buf 缓冲区的内容写入和保存到 AOF 文件，具体的写回策略由 appendfsync 选项的值来确定；
文件同步

AOF三种写回策略

在Redis的配置文件中，有这样几个配置：

# appendfsync always
appendfsync everysec
# appendfsync no

always：同步写回，每个写命令执行完，立马同步地将日志写回磁盘；
everysec：每秒写回，redis默认写回策略，即每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
no：由操作系统控制的写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

我们来总结一下这三种策略：

always：这种策略很安全，它能基本做到不丢失数据，但是每个写命令之后都有一个落盘的操作，所以它对系统的影响也是最大的；
no：这种策略最不安全，因为落盘的时机不在redis手中，一旦发生宕机对应的数据就会丢失；
everysec：避免了always策略的性能开销，也降低了no策略的丢失风险，最多可能会丢失1s的数据，它算是在二者之间取了个折中。

三种我们策略应该如何选择呢？

如果想要系统的高性能选 no策略；
如果想要高可靠性就选择 always策略；
如果二者兼容的话只有 everysec策略啦。

注意，到这里没有结束哦。我们虽然按照系统的需求选择了写回策略，但是AOF是以文件的形式记录接收到的命令的，这时候随着写入命令的不断增加，AOF文件的体积会变得越来越大。

如果AOF太大，再往里面追加命令的时候，效率就会降低。而一旦发生宕机，用AOF恢复的速度也会非常慢。

为了避免这种问题，接下来继续AOF的重写机制。

AOF重写机制

简单点说就是根据原有的AOF文件，重新创建一个新的AOF文件，只不过这个新的AOF文件比原来的更小。

那么Redis是怎么把文件变小的呢？

原来，Redis的重写机制具有多变一的功能，也就是检查数据库的键值对，记录下键值对的最终状态，从而实现对某个键值对多次操作产生的多条命令压缩为一条的效果。

我们知道，AOF文件是以追加的方式，记录接收到的命令。当对一个键值对反复修改时，就会记录多条命令。然而在重写的时候只是记录下了当前的最新状态，这样就实现了多变一。

看到这，大家可能会问了，既然redis是单线程的，它既要执行写入命令，同时又要同步日志到磁盘，这里又冒出来一个重写机制，但是它响应的速度依然很快，这到底是咋回事呢？

Redis为了避免阻塞主线程，导致数据库性能下降。就会创建一个子线程—bgrewriteaof，由子线程完成重写过程。

重写过程：

首先，主线程fork出bgrewriteaof子线程；同时也会把主线程的内存拷贝一份给bgrewriteaof子线程，这里的拷贝指的是子进程复制了父进程页表，此时子线程可以共享访问父进程的内存数据了；
然后，子线程就可以将新的内容记入重写日志了；注意，是重写日志！！！
对于新的操作命令，继续父线程处理，redis会把这个操作记录到正在使用的AOF日志的缓冲区，这样一来就不用担心宕机问题。同样，也会在重写日志的缓冲区也记录一份；
当子线程完成重写工作之后，缓冲区里的这些新的操作也会记录到新的AOF文件。此时，我们就可以用新的AOF文件替代旧文件了。

重写触发的时机：

手动触发：手动发送bgrewriteaof指令
自动触发：涉及到两个配置参数，只有AOF文件大小同时超出下面这两个配置项时，会触发AOF重写：
- auto-aof-rewrite-min-size：AOF重写时文件的最小大小，默认为64MB；
- auto-aof-rewrite-percentage：重写百分比，当前AOF文件比上一次重写后AOF文件的增量大小，和上一次重写后AOF文件大小的比值。

到这里AOF日志基本就介绍完了，接下来我们继续看看另一种持久化方法：内存快照。

RDB

RDB（Redis DataBase）内存快照，是redis默认的持久化方式。具体就是将某一时刻的内存数据以文件的形式保存到磁盘上。

请注意，这里是保存的是数据！！！ 不是操作。所以，在数据恢复的时候，我们就可以直接把RDB文件读入内存，快速完成恢复。

RDB相关配置

# 备份的频率：900秒内至少一个键被更改则进行快照
save 900 1
save 300 10
save 60 10000

# 快照创建出错后，是否继续执行写命令
stop-writes-on-bgsave-error yes

# 是否对快照文件进行压缩
rdbcompression yes

# 文件名称
dbfilename dump.rdb

# 文件保存位置
dir ./