redis持久化操作【随记】

持久化

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持久化的条件有哪些?

1. 满足咱们配置的持久化条件

   ==当满足触发rdb的条件的时候,默认会使用: bgsave的姿势进行持久化.==

    384  save 3600 1
    385  save 300 100
    386  save 60 10000

2. 执行bgsave也会触发持久化

   不会阻塞当前的线程, 当前的其它客户端咱们redis依然能处理.

1. 正常关机

通过shutdown, 执行正常关闭Redis服务, 也会触发Redis操作.这里使用的是: save的方式.

1. 执行save也会发生持久化

执行的时候,是阻塞式,也就是说我在落盘的时候,会阻塞当前的redis线程.其它的客户在我持久化过程当中,是不能使用reids的.

如果我执行: save之后, 持久化时间花30秒,在这30秒之内,reids是无法处理其它客户端请求的. –> 阻塞式.

1. 执行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持久化的总结:

1. 基于文本文件的持久化机制.「命令都存储了文件当中.」

2. 重写机制

   1. 4.x之后redis才有的.

   2. bgrewriteaof, 它会将6379.aof文件当中的重复命令,可以相互抵消的命令合并.

      1. 6379.aof文件的体积会减小

      2. 使用6379.aof文件恢复数据的时候,命令数减少了,这样的恢复速度也快一些.「依然要比恢复rdb文件慢.」

      3. 重写触发条件: 配置项

         auto-aof-rewrite-percentage 100
         auto-aof-rewrite-min-size 64mb

1. 配置项

2. 从内存 —> 内核缓冲区 –> 磁盘文件

   1. 它并不是每一秒都将文件写到磁盘上.这样的话,磁盘I/O太高.

   2. 从内核缓冲区 –> 磁盘文件

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文件,会变成二进制文件.此时就没有办法了.