Redis（中）

1、redis的持久化

????????"Redis 如何将数据写入磁盘"，首先要明白的时候，我们使用的redis的数据保存在内存上的，也就是说，只要我们的电脑关机或者重启服务器，那么在内存中的数据就会消失，所以要想持久化的存储，就必须将我们的数据写入内存。redis的持久化的技术大致可以分为两类，一个是RDB，一个是AOF。

1.1、RDB (Redis Database)

????????RDB 持久性以指定的时间间隔执行数据集的时间点快照。在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。

????????实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。在备份的时候它执行的是全量快照，就是把内存中的所有数据都记录到磁盘中。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文(dump.rdb)，其中，RDB就是Redis DataBase的缩写。

????????RDB配置文件，首先大概了解啦，RDB是基于快照的方式，隔一段时间然后执行快照然后保存数据，那么问题是时间间隔是多久，有没有什么附加条件。随着redis的版本的更新，关于RDB的配置文件也在不断的更新。

????????在6.2以前呐，是自动触发，大概的意思就是在规定的时间间隔中，如果多少有数据发生修改，达到这个设定的阈值就触发快照。

#每隔900秒 如果有1个key发生变化的化就备份文件
save 900 1
?
#每隔300秒 如果有10个key发生变化的化就备份文件
save 300 10
?
#每隔60秒 如果有10000个key发生变化的化就备份文件
save 60 10000

????????在redis6.2开始，默认的时间频率发生了变化，但是大概的思路还是在指定的时间间隔中有多少key发生变化就触发快照，大概就是快照的频率降低了，没有之前那种更新的很频繁。

1.1.1、自动触发

????????自动触发就是修改配置文件，然后设定快照的触发条件，然后当条件触发的时候自动的执行。

修改配置文件

????????使用vim编辑器编辑redis.conf的配置文件，这里我就不做什么修改

 440 # save 3600 1 300 100 60 10000
 441 save 3600 1 300 100 60 10000

修改dump文件的保存路径

 512 # Note that you must specify a directory here, not a file name.
 513 dir /software/redis/redis-7.2.3/redisconf/dumpfiles

修改dump文件名称

#这里没有做修改
489 dbfilename dump.rdb

????????修改完毕后可以重启一下redi，然后在客户端中查看数据配置的，文件保存的路径是不是配置的。

> CONFIG GET dir
dir
/software/redis/redis-7.2.3/redisconf/dumpfiles
> CONFIG GET port
port
6379
> CONFIG GET save
save
3600 1 300 100 60 10000

????????然后当我们的数据发生变化到某一阈值就会触发快照，然后保存数据。

?

????????好了，现在有啦备份的文件，问题是怎么把它里面的数据恢复出来，将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。另外执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义。

????????重启redis的话，然后回到指定的备份文件中读取数据。既然使用清空数据库的和showdown命令都会将dump.rdb文件文件清空然后覆盖之前的备份文件，其实清空我还理解，这个关闭我有点不太理解，为什么关闭还要备份，而且是空的数据，就很离谱！

????????分机隔离可以解决上面的问题嘛，我试了一下，使用linux版本的提供服务，然后window版本的当作客户端，执行了shutdown后，对数据没有影响，备份数据可以正常恢复。使用linux下的也没有影响！！！

1.1.2、手动触发

????????手动触发就是使用redis的命令来完成生成RDB文件，分别是save和bgsave。save命令执行会阻塞当前的redis服务器，直到持久化的工作完成，而且子啊save命令执行期间，redis不能处理其他的命令，（线上禁止使用）。

????????bgsave命令的执行期间，redis会在后台异步进行快照的操作，采用的不是阻塞的方式，在备份的同时还可以响应客户端的请求，触发方式会fork一个子进程由子进程来完成备份持久化的过程。

此外使用lastsave可以获取最近一次的成功执行备份的时间戳！

?

> LASTSAVE
1704180666

1.1.3、总结

1.1.3.1、优点

????????RDB的优点，是对数据的整体的备份所以使用RDB可以进行大规模的数据备份和恢复，可以按照业务定时的备份，默认使用的是bgsave，不影响主进程。和AOF相比RDB文件在内存中的加载的速度更快。对数据完整性和一致性不高。

1.1.3.2、缺点

????????在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失。内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能。RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑。

1.1.3.3、修复dump文件

????????使用redis-check-rdb可以检查和修复dump文件。

[root@localhost redisconf]# redis-check-rdb /software/redis/redis-7.2.3/redisconf/dumpfiles/dump.rdb 
[offset 0] Checking RDB file /software/redis/redis-7.2.3/redisconf/dumpfiles/dump.rdb
[offset 26] AUX FIELD redis-ver = '7.2.3'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1704180537'
[offset 67] AUX FIELD used-mem = '988016'
[offset 79] AUX FIELD aof-base = '0'
[offset 81] Selecting DB ID 1
[offset 114] Checksum OK
[offset 114] \o/ RDB looks OK! \o/
[info] 3 keys read
[info] 0 expires
[info] 0 already expired

1.1.3.4、触发RDB的条件

• 根据配置文件中的配置触发

• 手动的save/bgsave命令

• 执行flushdb/flushall命令会产生备份文件，但是没有数据

• 执行shutdown并且没有开启AOF持久化

• 主从复制，主节点自动触发

????????关于如何禁用配置中的触发条件。可以临时配置使用

redis-cli config set save ""

????????想要永久的修改，在配置文件中修改为 save ""

1.1.3.5、RDB的优化配置

????????配置文件SNAPSHOTTING模块，前面已经修改过dump的存储目录、dump文件名以及save的参数。当然还有一些其他的配置参数可以调优。

stop-writes-on-bgsave-error yes

????????默认yes，如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求。

rdbcompression yes

????????默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。 如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能 。

rdbchecksum yes

????????默认yes ，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

rdb-del-sync-files no

????????在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。