【2023】Redis数据持久化-Toy模板网

这篇具有很好参考价值的文章主要介绍了【2023】Redis数据持久化。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1.为什么需要Redis持久化

Redis是基于内存的NoSQL数据库，读写速度很快，但是存储在内存中的Redis数据会在服务器重启后丢失。
然而在一些场景中，需要长久的保存数据，所以需要把内存中的数据持久化的保存在硬盘中。

Redis持久化提供两种方式：

1️⃣：AOF（Append Only File）只追加文件
2️⃣：RDB（Redis DataBase）基于Redis数据库

2.Redis持久化机制概述

2.1.基于AOF的持久化机制

Redis的AOF持久化是指将数据存储到二进制日志文件中，以便在重启或出现故障时可以恢复数据。

AOF持久化会周期性地将数据写入到日志文件中，因此可以实现更高的数据备份频率。

在使用基于AOF的持久化方式时，需要注意以下几点：

写入日志文件的数据会占用一定的存储空间，因此需要考虑磁盘空间的问题。
基于AOF的持久化方式需要消耗一定的系统资源，包括写入日志文件的时间和空间、维护AOF文件的开销等。因此在高并发场景下，需要根据实际情况进行调整。
基于AOF的持久化方式可以通过配置日志文件的大小和频率来调整备份数据的频率和大小，以满足不同场景的需求。
在使用基于AOF的持久化方式时，需要注意防止系统故障或重启导致数据丢失，可以通过定期备份或使用其他持久化方式（如RDB持久化）来增强数据保护能力。

2.2.基于RDB的持久化机制

基于RDB的持久化方式会把当前内存中所有Redis键值对数据以快照（snapshot）的方式写入硬盘文件中，如果需要恢复数据，就把快照文件读到内存中。

RDB持久化的主要优点是数据可以快速恢复，而且不需要消耗太多的系统资源。

但是，RDB持久化也有一些缺点，如数据在内存中的写入和查询效率可能会受到一定的影响，并且RDB持久化方式不支持快速的数据备份和恢复。

因此，在实际应用中，需要根据具体场景选择适合的持久化方式。

3.AOF持久化机制实战

3.1.AOF方式持久化机制实战

可以通过设置配置文件里的参数来启动或停止AOF持久化机制，由于基于AOF的持久化方式具有实时存储的特性，因此可以在读写关键数据时开启，以防因Redis重启或故障而导致的风险。

AOF配置文件参数说明：通过redis.conf来配置AOF

开启AOF持久化，关闭注视掉即可

appendonly yes

设置持久化策略（always、everysec、no）

appendfsync everysec

1️⃣：always：每次触发写操作都会触发持久化操作，可能会影响redis自身及redis服务器性能
2️⃣：everysec：会以1秒频率触发持久化动作，这种方式能很好平衡持久化需求和性能间关系
3️⃣：no：由操作系统决定持久化频率，这种方式对其他另外两种而言性能最好，但可能每次持久化操作间的间隔有些长，这样当故障发生时可能会丢失较多的数据。

持久化文件所在路径和文件名

dir ./
appendfilename "appendonly.aof"

平衡性能与安全性：取值为yes，那么在重写AOF文件时能提升性能，但可能在重写AOF文件时丢失数据；如果取值为no，则不会丢失数据，但较取值为yes的性能可能会降低。

no-appendfsync-on-rewrite no

指定重写条件：如果当前的AOF文件比上次执行重写时的文件大100%时会再次触发重写操作。如果该参数取值为0，则不会触发重写操作。

auto-aof-rewrite-percentage 100

指定触发重写时AOF文件大小

auto-aof-rewrite-min-size 64mb

注意：，由auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个参数指定的重写条件是“And”的关系，即只有当同时满足这两个条件时才会触发重写操作，比如当前AOF文件的大小小于auto-aof-rewrite-min-size参数指定的值，哪怕文件增幅达到no-appendfsync-on- rewrite参数指定的范围，也不会触发重写操作。

实践：

配置reids AOF持久化配置文件：redis.conf，配置后重启redis

dir /data
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

注意：启动redis时指定配置文件

redis-server /path/to/redis.conf

连接redis服务器，创建一些数据

[root@localhost ~]# redis-cli 
127.0.0.1:6379> get name001
(nil)
127.0.0.1:6379> set name001 'xiaoming'
OK
127.0.0.1:6379> set age001 30
OK

如果配置成功，当前是开启AOF持久化的，应该会有数据

[root@localhost redis-6.2.12]# cd /data/
[root@localhost data]# ls
appendonly.aof
[root@localhost data]# cat appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$7
name001
$8
xiaoming
*3
$3
set
$6
age001
$2
30

以上数据即为持久化文件的内容：
选择0号数据库，插入两条键值对

3.2.重写AOF文件的效果

向数据库插入一个列表

[root@localhost ~]# redis-cli
127.0.0.1:6379> lpush namelist "yy1"
(integer) 1
127.0.0.1:6379> lpush namelist "yy2"
(integer) 2
127.0.0.1:6379> lpush namelist "yy3"
(integer) 3
127.0.0.1:6379> lpush namelist "yy4"
(integer) 4

查看持久化文件内容

*3
$5
lpush
$8
namelist
$3
yy1
*3
$5
lpush
$8
namelist
$3
yy2
*3
$5
lpush
$8
namelist
$3
yy3
*3
$5
lpush
$8
namelist
$3
yy4

运行bgrewriteaof命令手动触发AOF文件的重写动作，然后打开文件查看

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

REDIS0009ú      redis-ver^F6.2.12ú
redis-bitsÀ@ú^EctimeÂ^<8b><91>dú^Hused-memÂHW^M^@ú^Laof-preambleÀ^Aþ^@û^C^@^@^Fage001À^^^@^Gname001^Hxiaoming^N^Hnamelist^A^_^_^@^@^@^Y^@^@^@^D^@^@^Cyy4^E^Cyy3^E^Cyy2^E^Cyy1ÿÿ^?d^_5µ<82>{^?

3.3.模拟数据恢复

停止该redis服务器并重新启动一个新的服务器

[root@localhost data]# ps -ef | grep 6379
root       1943      1  0 19:03 ?        00:00:03 redis-server 127.0.0.1:6379
root       1993   1314  0 19:24 pts/0    00:00:00 grep --color=auto 6379
[root@localhost data]# kill -9 1943

redis-server /root/redis-6.2.12/redis.conf

连接服务器查看数据、创建数据、清空内存数据

127.0.0.1:6379> get name001
"xiaoming"
127.0.0.1:6379> get age001
"30"
127.0.0.1:6379> set name002 xiaoli
OK
127.0.0.1:6379> set age002 21
OK
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> get name002
(nil)
127.0.0.1:6379> get age002
(nil)

查看持久化文件，包含刚才执行的数据

*3
$3
set
$7
name002
$6
xiaoli
*3
$3
set
$6
age002
$2
21
*1
$8
FLUSHALL

退出客户端，停止运行redis服务器，删除持久化文件中的FLUSHALL，不然执行后还会清空
重启启动redis服务器，查看数据

[root@localhost ~]# redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get name002
"xiaoli"
127.0.0.1:6379> get age002
"21"

看到此内容证明恢复成功

3.4.修复AOF文件

报错：

"Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>"

代表AOF文件格式不正确

解决：

redis-check-aof --fix /data/appendonly.aof

后面加你自己的aof文件路径，即可修复成功。

文件损坏也会导致redis启动失败。

4.RDB持久化机制实践

在基于RDB的持久化机制里会定时把Redis内存数据以快照的方式保存到硬盘上，而在必要的时候可以通过快照文件来恢复数据。

4.1.修改基于RDB的配置文件

为了方便区分，先把基于AOF的配置关闭，只配置RDB相关配置

appendonly no

save 600 1
save 300 100
save 60 1000

1️⃣：第1行代码表示当在600秒内有1个或1个以上的键被修改时就会生成快照
2️⃣：第2行代码表示在300秒内有大于或等于100个键被修改时就会生成快照
3️⃣：第3行表示在60秒内有大于或等于1000个键被修改时会生成快照。
注意：三者是或的关系，满足一条即可触发

设置文件名及路径

dbfilename dump.rdb
dir /data

4.2.创建Redis服务器进行测试

启动redis服务器

[root@localhost redis-6.2.12]# redis-server redis.conf

连接服务器创建一条数据

[root@localhost ~]# redis-cli
127.0.0.1:6379> set id001 001
OK
127.0.0.1:6379> set id002 002
OK

此时已经有rdb文件

[root@localhost redis-6.2.12]# cd /data/
[root@localhost data]# ls
appendonly.aof  dump.rdb
[root@localhost data]# cat dump.rdb 
REDIS0009	redis-ver6.2.12
redis-bits󿿀򳨭eÊused-mem@V
aof-preamble@r¶ [root@localhost data]# Xshell

恢复数据与AOF类似，停止服务器重启创建即可自动恢复数据。

5.如何选用持久化方式

在Redis里，基于AOF和RDB的两种持久化方式有各自的优缺点，所以它们有各自的应用场合。

5.1.对比两种持久化方式

Redis有两种持久化方式，分别是RDB（Redis DataBase）和AOF（Append-Only File）。

RDB的优点：

RDB使用一种紧凑的二进制格式来存储数据，因此它的速度非常快。在恢复大量数据时，它通常比AOF快得多。
RDB对于在磁盘上的数据备份和恢复非常有用，用于灾难恢复和数据迁移。

RDB的缺点：

RDB快照是定期执行的，而不是实时执行，所以如果Redis在快照之间崩溃，您将丢失最新的数据。
RDB无法保证数据的实时性，因为您需要配置多久进行一次快照，并在磁盘之间传输大量的数据。

AOF的优点：

AOF以追加方式记录每个写操作，因此能够实时记录每个数据更改，更加可靠。
AOF提供了更好的数据安全保障，因为它通过记录每个写操作来避免数据的丢失。

AOF的缺点：

AOF记录每个写操作，因此它的速度比RDB慢，尤其在写操作比较频繁时更加明显。
AOF生成的日志文件可能比较大，因此需要定期进行压缩和清理。

综上所述，RDB在执行速度和备份恢复上优于AOF，但无法保证数据的实时性；而AOF在数据安全方面更有保障，但会对性能产生影响。因此，选择哪种持久化方式应该根据具体业务需求和应用场景来确定。Redis有两种持久化方式，分别是RDB（Redis DataBase）和AOF（Append-Only File）。