Redis学习—持久化机制

本篇介绍一下Redis的持久化机制

Redis是一种内存数据库，将自己的数据库状态（非空数据库以及它们的键值对）存储在内存中，为了防止丢失状态，Redis提供了持久化机制，将数据库状态保存到磁盘中，保存为dump.rdb文件。之后根据这个压缩的二进制文件，还能还原数据库状态。

RDB（Redis DataBase）

我们安装完redis后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化配置

持久化有三种触发方式：SAVE命令、BGSAVE命令、自动化

• SAVE：可以生成RDB文件，但是同时会阻塞Redis服务器进行，使服务器不能处理任何命令
• BGSAVE:会派生出一个子进程进行创建RDB文件的任务，服务器进程（父进程）继续处理命令。
• 自动化：允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。

打开redis.conf文件可以看到save选项配置：

Redis服务器周期性操作函数serverCron默认每隔100毫秒就会执行一次，主要是对运行的服务器进行维护，其中一项工作就是检查save选项所配置的条件是否已经满足。

{% note info %}

Redis数据库启动时检测到RDB文件存在后，会自动加载RDB文件

{% endnote %}

SAVE与BGSAVE命令的区别

RDB 文件结构

• REDIS:常量，表示是否是RDB文件
• db_version：字符串，记录的是RDB版本号
• databases: 包含零个或多个数据库
• EOF：表示RDB文件正文已经结束
• check_sum：表示一个校验和，检查载入文件时是否出错

RDB的优势和劣势

优势：

1. RDB文件紧凑，保存Redis服务器所有数据库中的数据，适用于备份和灾难恢复
2. 生成RDB文件时，会生成一个子进程处理这个任务，不需要进行任何IO磁盘操作
3. RDB在恢复时比AOF恢复速度快

劣势：

当子进程进行RDB文件持久化时，父进程也在处理Redis命令，而这些修改，子进程不会反映出来，可能丢失数据。

AOF（Append Only File）

如果说RDB是通过保存数据库中的键值对来记录数据库状态的不同，那么AOF持久化是通过保存Redis服务器执行的写命令来记录数据库状态的。

修改配置文件打开AOF功能：

appendonly yes

由于AOF文件的更新频率通常比RDB更新频率高，所以程序会优先使用AOF，只有在AOF关闭时，才会用RDB

AOF持久化实现

AOF持久化功能实现分三个步骤：命令追加、文件写入、文件同步

1. 命令追加

当AOF持久化打开时，服务器执行完一个写命令之后，会将被执行的写命令追加到服务器状态的aof_buf缓冲区末尾

2. 文件写入

Redis服务器进程是这样子：本身是一个事件循环（loop），循环中的文件时间负责接收客户端的命令请求，以及向客户端发送命令回复，而时间时间则负责执行类似serverCron函数（检查服务器运行状态）这类函数

def evenLoop():
	while True:
	
	# 处理文件事件，接收命令请求以及发送命令回复
	# 处理命令请求时可能会有新的内容被追加到aof_buf缓冲区内
	processFileEvents()
	
	# 处理时间事件
	processTimeEvents()
	
	# 考虑是否将aof_buf内容写入AOF文件
	flushAppendOnlyFile()

3. 文件同步

flushAppendOnlyFile()函数通过配置appendfsync选项来决定，有三种类型：

• always: 将aof_buf缓冲区所有内容写入并同步到AOF（文件完整性更好）
• everysec: 将aof_buf缓冲区所有内存写入AOF，时隔1秒进行同步（每秒同步一次，可能会丢失一秒数据）
• no: 将aof_buf缓冲区所有内存写入AOF，不进行同步，何时同步由操作系统定（不同步，效率高）

RDB与AOF区别

AOF文件要大于RDB，相对的恢复速度就慢，而数据的安全性也相对较高。Redis默认使用RDB，我们要看情况选择合适的持久化方式

【最后欢迎大家来我的博客skiron.xyz来玩，一起学习进步！！！】