持久化
Redis它是将数据保存到内存当中,内存里的数据最大特点: 断电易失.保存在内存的数据就没有了.如果如果这些数据还有用,业务使用啥的,不能就让它这么没有了.
redis当中提供持久化机制, 说白了,将
内存的数据 —-> 写入到磁盘. –> 持久化.
1 rdb方式
redis database, 持久化机制.
相当在内存做了一快照.
################################ SNAPSHOTTING ################################
364
365 # Save the DB to disk.
366 #
367 # save <seconds> <changes>
368 #
369 # Redis will save the DB if both the given number of seconds and the given
370 # number of write operations against the DB occurred.
371 #
372 # Snapshotting can be completely disabled with a single empty string argument
373 # as in following example:
374 #
375 # save ""
376 #
377 # Unless specified otherwise, by default Redis will save the DB:
378 # * After 3600 seconds (an hour) if at least 1 key changed
379 # * After 300 seconds (5 minutes) if at least 100 keys changed
380 # * After 60 seconds if at least 10000 keys changed
381 #
382 # You can set these explicitly by uncommenting the three following lines.
383 #
384 save 3600 1
385 save 300 100
386 save 60 10000配置一下文件名称: dbfilename 6379.rdb –> 建议修改成6379, 因为之后会启动多台服务器
配置一下持久化的文件目录: dir ./ –> 可以修改成你自己喜欢的目录
1.2 触发rdb持久化的条件有哪些?
-
满足咱们配置的持久化条件
==当满足触发rdb的条件的时候,默认会使用: bgsave的姿势进行持久化.==
384 save 3600 1 385 save 300 100 386 save 60 10000
-
执行bgsave也会触发持久化
不会阻塞当前的线程, 当前的其它客户端咱们redis依然能处理.
-
正常关机
通过shutdown, 执行正常关闭Redis服务, 也会触发Redis操作.这里使用的是: save的方式.
-
执行save也会发生持久化
执行的时候,是阻塞式,也就是说我在落盘的时候,会阻塞当前的redis线程.其它的客户在我持久化过程当中,是不能使用reids的.
如果我执行: save之后, 持久化时间花30秒,在这30秒之内,reids是无法处理其它客户端请求的. –> 阻塞式.
-
执行flushdb也会触发
总结一下:
bgsave
copy on write
fork(), 创建子进程
这两东西都是内核提供提供的机制.
配置的save当满足条件了,执行的也是
bgsave持久化方式.
redis正常启动的时候,会从默认的 rdb目录加载6379.rdb文件, 将数据恢复到内存当中.
恢复的速度,非常的快,因为rdb是二进制存储的.
rdb持久化操作的缺点:
无法保证数据安全
没有办示确保内存数据会一定落盘到磁盘.它可能会丢失一个时间段之内的所有数据.
它不支持拉链存储
最终存储数据只有一个6379.rdb文件,之前被覆盖,之后的行为会覆盖掉当前的数据.
如果想要某个时间段的,只有手动备份.
2 aof
append only file.采用记录日志的姿势来存储数据.日志写在文件当中,这样丢失少一些,同样,存储的是文本, 恢复速度慢.
需要我们进行配置的:
appendonly no –> appendonly yes, 表示开启aof
appendfilename "6379.aof", 保存到磁盘上的文件名称.
aof持久化策略配置:
将内存的数据写入到aof文件的时机.
no, 表示由操作系统决定啥时候写入.
always, 表示如果有key发生更改,就写入.
everysec, 表示一秒钟写入一次.
1269 # no: don't fsync, just let the OS flush the data when it wants. Faster.
1270 # always: fsync after every write to the append only log. Slow, Safest.
1271 # everysec: fsync only one time every second. Compromise.
1286 # appendfsync always
1287 appendfsync everysec
1288 # appendfsync no
默认的aof文件的保存位置,是在配置文件当中的dir目录配置的.
我们这里配置的是: dir '/usr/local/yyds2305/redis-6.2.13/redis-rdb-aof/' 目录.
*2 $6 SELECT $1 0 *3 $3 SET $3 age $2 26 # aof文件内容,是上边的样子.
2.1 重写机制
bgrewriteaof, 会合并记录的日志6379.aof文件当中,合并重复的命令,合并相互抵消的命令.
对这个日志何种进行减少.
aof恢复记录的方式, 是将日志文件,一条接一条执行一遍. 如果日志条数太多了,则恢复速度肯定会被拖慢.
1328 auto-aof-rewrite-percentage 100 # 1倍的大小,再次触发bgrewriteaof
1329 auto-aof-rewrite-min-size 64mb # aof文件的默认大小,到达了64MB, 触发bgrewriteaof. 重写机制
对于aof持久化的总结:
基于文本文件的持久化机制.「命令都存储了文件当中.」
重写机制
4.x之后redis才有的.
bgrewriteaof, 它会将6379.aof文件当中的重复命令,可以相互抵消的命令合并.
6379.aof文件的体积会减小
使用6379.aof文件恢复数据的时候,命令数减少了,这样的恢复速度也快一些.「依然要比恢复rdb文件慢.」
重写触发条件: 配置项
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
配置项
从内存 —> 内核缓冲区 –> 磁盘文件
它并不是每一秒都将文件写到磁盘上.这样的话,磁盘I/O太高.
从内核缓冲区 –> 磁盘文件
2.2 rdb + aof 混合体
rdb: 基于二进制的,恢复速度快,但是丢失数据比较多.
aof: 基于文件存储,恢复速度慢, 但是丢失数据比较少.
能不能, 让两者结合下,既要rdb快,也要aof丢失数据量,还要文件何种减少.
开启混合体的配置项:
开启aof
开启rdb
开启混全开关
# When loading, Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, then continues loading the AOF
# tail.
aof-use-rdb-preamble no --> yes, 这个就表示开启混合模式. 默认就是开启的.基本流程:
同时开启rdb + aof , 在配置文件当中进行配置.
开启配置项: aof-use-rdb-preamble yes
生成的文件
会同时生成rdb和aof文件.
rdb二进制的文件, aof文本文件.
如果执行了: bgrewriteaof, 可以这么理解: 将rdb文件的内容覆盖掉aof文件.此时rdb文件和aof文件,文件大小一样,保存的内容也是一样的,同时此时的aof文件也保存的是二进制的内容.
在这之后,如果再次发了写操作,此时,命令会以日志的文件追加到aof文件,此时aof文件是一个rdb内容 + aof 的混合体.
从硬盘恢复数据:
如果开启了混合模式,则恢复的时候,只恢复aof文件.
如果命令当中执行了: flushdb/flushall,此时咱们可以打开aof文件,将这个命令行删除掉, 然后重启redis服务.
数据不会丢失.也不会被删除.
如果执行完
bgrewriteaof之后,此时aof文件,会变成二进制文件.此时就没有办法了.
标签：aof,持久,文件,redis,rdb,save,随记 From： https://blog.csdn.net/weixin_64296810/article/details/139855141