Redis基础（六）—— 持久化

笑容不是为了我
830 阅读7分钟

这是我参与8月更文挑战的第9天，活动详情查看：8月更文挑战

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会消失，所以Redis提供了持久化功能。

持久化就是把内存中的数据写到磁盘中去，防止服务器宕机了内存数据丢失；

Redis 提供了两种持久化方式：RDB（默认）和 AOF

RDB（默认）

RDB 是 Redis Database的缩写

把当前数据生成快照保存在硬盘上

功能核心函数 rdbSave（生成RDB文件）和 rdbLoad（从文件加载到内存）两个函数

image-20210729185754324

快照是默认的持久化方式，这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为 dump.rdb

RDB持久化可以手动触发，也可以自动触发

1. 手动触发

save和bgsave命令都可以手动触发RDB持久化。

save命令

执行save命令会手动触发RDB持久化，但是save命令会阻塞Redis服务，直到RDB持久化完成。

当Redis服务储存大量数据时，会造成较长时间的阻塞，不建议使用。

  1. 执行
 127.0.0.1:6379> save
  1. 日志文件
 20947:M 29 Jul 2021 23:28:56.615 * DB loaded from disk: 0.000 seconds
 20947:M 29 Jul 2021 23:28:56.615 * Ready to accept connections
 20947:M 29 Jul 2021 23:29:11.551 * DB saved on disk

** ps：日志文件查看

(1). 查看 redis.conf 文件中 logfile 属性对应的文件位置；（我这里本来没有，自己写上想要保存日志的位置）

 logfile "/usr/local/redis/log/redis.log"

(2). 重启 redis 服务端

bgsave

执行bgsave命令也会手动触发RDB持久化，和save命令不同是：Redis服务一般不会阻塞。

Redis进程会执行fork操作创建子进程，RDB持久化由子进程负责，不会阻塞Redis服务进程。

Redis服务的阻塞只发生在fork阶段，一般情况时间很短。

  1. 执行

     127.0.0.1:6379> bgsave
 Background saving started

  2. 日志文件

     20947:M 29 Jul 2021 23:30:52.144 * Background saving started by pid 21044
 21044:C 29 Jul 2021 23:30:52.148 * DB saved on disk
 21044:C 29 Jul 2021 23:30:52.149 * RDB: 0 MB of memory used by copy-on-write
 20947:M 29 Jul 2021 23:30:52.193 * Background saving terminated with success

bgsave执行流程

image-20210809081510265
  1. 执行bgsave命令，Redis进程先判断当前是否存在正在执行的RDB或AOF子线程，如果存在就是直接结束。
  2. Redis进程执行fork操作创建子线程，在fork操作的过程中Redis进程会被阻塞。
  3. Redis进程fork完成后，bgsave命令就结束了，自此Redis进程不会被阻塞，可以响应其他命令。
  4. 子进程根据Redis进程的内存生成快照文件，并替换原有的RDB文件。
  5. 子进程通过信号量通知Redis进程已完成。

2. 自动触发

自动触发的RDB持久化都是采用bgsave的方式，减少Redis进程的阻塞。

那么，在什么场景下会自动触发呢？

触发场景

  1. 在配置文件中设置了save的相关配置，如save m n，它表示在m秒内数据被修改过n次时，自动触发bgsave操作；

     save 900 1      # 每 900 秒（15分钟）至少 1 个key发生变化，产生快照
 save 300 10     # 每 300 秒（5分钟）至少 10 个key发生变化，产生快照
 save 60 10000   # 每 60 秒（1分钟）至少 10000 个key发生变化，产生快照

  2. 当从节点做全量复制时，主节点会自动执行bgsave操作，并且把生成的RDB文件发送给从节点；

  3. 执行debug reload命令时，也会自动触发bgsave操作；

  4. 执行shutdown命令时，如果没有开启AOF持久化也会自动触发bgsave操作。

优点：

  • 快照保存数据极快、还原数据极快；
  • 适用于灾难备份

缺点：

  • 小内存及其不适合使用，RDB机制符合要求就会照快照；
  • 频繁执行成本过高，所以无法做到实时持久化，或者秒级持久化；
  • fork进程会消耗一定内存空间；
  • 另外，由于Redis版本的不断迭代，存在不同格式的RDB版本，有可能出现低版本的RDB格式无法兼容高版本RDB文件的问题。

AOF

AOF（Append Only File）持久化是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了。

AOF解决了数据持久化的实时性，也是目前主流的Redis持久化方式。

流程图

image-20210730145125360

  1. 命令追加（append）：所有写命令都会被追加到AOF缓存区（aof_buf）中。
  2. 文件同步（sync）：根据不同策略将AOF缓存区同步到AOF文件中。
  3. 文件重写（rewrite）：定期对AOF文件进行重写，以达到压缩的目的。
  4. 数据加载（load）：当需要恢复数据时，重新执行AOF文件中的命令。

配置

AOF持久化默认是不开启的，需要修改 redis.conf 配置文件，如：

 # appendonly改为yes，开启AOF
 appendonly yes
 # AOF文件的名字
 appendfilename "appendonly.aof"
 ​
 # AOF文件的写入方式
 # everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
 # appendfsync always
 appendfsync everysec
 # appendfsync no
 ​
 # 运行AOF重写时AOF文件大小的增长率的最小值
 auto-aof-rewrite-percentage 100
 # 运行AOF重写时文件大小的最小值
 auto-aof-rewrite-min-size 64mb

文件同步（sync）策略

  1. always：每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Redis高并发，不建议配置。
  2. no：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不可控，而且增大了每次同步的硬盘的数据量。
  3. eversec (默认) ：每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建议的同步策略，也是默认的策略。

触发文件重写

文件重写：因为如果重写写入命令，aof文件会越来越大，通过读取数据库的键值，来完成重写。

是为了合并多余命令，减小文件大小；

例如：对一个字符串进行四次操作，我只需要读取最终的值，最后用一条命令来写入；

fork 一个新的进程进行文件重写。

  1. 手动触发：使用 bgrewriteaof 命令

     127.0.0.1:6379> bgrewriteaof
 Background append only file rewriting started

    日志

     20947:M 30 Jul 2021 15:04:54.888 * Background append only file rewriting started by pid 6083

  2. 自动触发：

    根据 auto-aof-rewrite-min-size 和auto-aof-rewrite-percentage配置确定自动触发的时机。

    auto-aof-rewrite-min-size表示运行AOF重写时文件大小的最小值，默认为64MB；

    auto-aof-rewrite-percentage表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为100。

    只用前两者同时超过时才会自动触发 文件重写。

优点：

  • 数据实时同步，根据 AOF 默认文件同步策略，当服务器宕机时，最多会丢失一秒钟的数据；

缺点：

  • 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件体积；
  • AOF运行效率低于 RDB
avatar
文章
阅读
粉丝