Redis持久化实战

AOF持久化

修改配置文件

首先我们知道，AOF的持久化是在配置文件中设置的
所以要找到Redis的文件夹，进入文件夹之后找到配置文件
注意，配置完毕之后要重启Redis才会生效
修改redis.conf文件，在其中编写如下配置信息

appendonly yes  #启动AOF持久化机制 
appendfsync everysec #设置了持久化的策略，即持久化的频率是“每秒
dir ./ #设置了持久化文件的保存路径

这里没有通过appendfilename参数设置持久化文件的名字，所以会选用默认的appendonly.aof文件名，当然也可以自行更改，改成自己想要的也就可以了

重启服务

检查redis是否是启动中

ps -ef|grep redis

关闭redis

redis-cli -a 用户密码 shutdown

重新启动redis，一定要以配置文件启动，否则不生效

# 切换到redeis.config所在目录
/opt/server/redis-6.2.7
# 加载配置文件启动
redis-server redis.conf

操作redis

因为设置的是每秒都触发一次，所以aof文件很快就上来了，这里以windows为例，aof文件已经上来了

此时AOF持久化机制已经生效，每秒会同步持久化文件，而且之前也运行了若干写命令，所以可以观察AOF持久化文件里的内容。

查看当前目录下(运行redis-server所在目录)appendonly.aof文件中的内容

第一条命令是select 0，表示开启0号数据库，能看到第二条和第三条set命令，get name命令是读命令，所以不会写入持久化文件

模拟数据恢复

flushall命令能清空Redis的所有内存数据
这个操作也是写入操作，也会被AOF记录下来

flushall

注意flushall命令也会记录到aof文件中，打开AOF文件，删除最后一行的flushall命令，如果不删除，在进行数据恢复时还会运行这条命令，从而把数据清空。

关闭redis服务，并重新启动

redis-cli -a 123456 shutdown
redis-server redis.conf

观察数据是否被还原

RDB

基于RDB的持久化方式会把当前内存中所有Redis键值对数据以快照的方式写入硬盘文件中，如果需要恢复数据，就直接把快照文件读到内存中，因此这种方式恢复速度很快。

RDB快照文件是经压缩的二进制格式的文件，因此，我们无法像AOF一样查看RDB快照，它的存储路径不仅可以在Redis服务器启动前通过配置参数来设置，还可以在Redis运行时通过命令来设置。
有两种方式可以触发RDB持久化机制：

• 第一种是通过save和bgsave等命令手动触发；
• 第二种是Redis服务器会根据redis.conf配置文件里设置的方式定期把内存数据写入快照。

基于RDB的持久化方式比较适合数据备份和灾备场景，但RDB无法实现即时备份，即上次生成快照后的修改会丢失。

手动触发RDB持久化

save命令（慎用）

Redis客户端运行save命令后，Redis服务器会把当前内存里的数据写入快照文件，在写入的过程中会暂停执行其他命令，直到写完快照文件。
如果当前Redis内存数据很多，那么一旦执行save命令，服务器就会长时间暂停执行命令，造成大量连接阻塞，从而导致线上问题，所以一般在执行save命令时需要非常谨慎。
也就是说，在使用save命令的时候，就相当于Redis暂停使用了

bgsave命令

和save命令对应的是bgsave命令（background save），这里bg的含义是background，即后台运行。当用户输入bgsave命令后，Redis服务器会创建一个新的进程，在该进程里把内存数据写入快照文件里，在写的过程中Redis服务器能继续执行其他来自客户端的命令。

那么既然是在后台运行的，如何确认是否成功了呢?

如果要查看bgsave命令的结果，可以继续执行lastsave命令，该命令返回的是一个时间戳，表示最近一次把内存数据存入快照文件的时间，如果该时间和bgsave命令的运行时间能对应上，则能说明bgsave命令成功执行。

下面是具体实操

修改配置文件

在Redis的redis.conf配置文件里，可以通过save参数配置生成RDB快照的条件，具体代码如下：

这里的save是参数，并且也是在配置文件里的，并非命令。

第1行代码表示当在600秒内有1个或1个以上的键被修改时就会生成快照
第2行代码表示在300秒内有大于或等于100个键被修改时就会生成快照
第3行表示在60秒内有大于或等于1000个键被修改时会生成快照。

save 600 1
save 300 100
save 60 1000

注意，这三个条件是“或”的关系，即只要有一个条件被满足，就会生成快照。从中能看出，RDB持久化文件只是当条件满足后生成快照，所以无法即时保存当前状态的内存数据。也就是说，通过RDB恢复数据时，会丢失上次生成快照后更新的数据。

因为RDB是Redis的默认持久化方式嘛，所以在配置文件中也可以找到他的持久化策略

=========================================================

同时，在redis.conf里加上如下两条描述快照文件文件名的配置
实际上因为默认持久化方式是RDB，所以配置文件中就已经有了这行信息

dbfilename redis.rdb

重启服务

检查redis是否是启动中，再次重启

ps -ef|grep redis

关闭redis

redis-cli -a 用户密码 shutdown

重新启动redis，一定要以配置文件启动，否则不生效

# 切换到redeis.config所在目录
/opt/server/redis-6.2.7
# 加载配置文件启动
redis-server redis.conf

操作Redis

set name lisi

此时满足“600秒里有一个或一个以上键被修改”这个条件，所以能看到RDB持久化文件redis.rdb，不过RDB持久化文件是二进制格式，所以用记事本打开后看到的是乱码。

用快照文件恢复数据

和AOF持久化方式一样，通过RDB的快照文件也可以恢复数据，如果redis数据出现了丢失，在启动时会根据快照文件向该Redis服务器里恢复数据。

AOF和RDB对比

AOF可以设置一秒写一次持久化文件，所以相对RDB而言，这种方式能更好地记录内存数据，从而能更好地达到持久化的效果，而且AOF是以“在文件末尾追加”的方式写入数据，所以AOF性能较好。

AOF持久化的文件一般会大于RDB快照，所以用AOF恢复数据时速度会比RDB要慢。

RDB的快照是二进制文件，所以一般比AOF要小，所以在恢复数据时占优势，而且通过bgsave等方式生成快照时，Redis服务器会新创建一个子进程，所以不会影响Redis服务器继续执行命令。

在实际项目里可以同时用到这两种方式，当出现数据误删的情况时，可以用AOF持久化文件来恢复数据，在一般情况下，可以用RDB快照来恢复数据。