谈谈Redis持久化

目录

前言

RDB 

AOF

总结


前言

我们都知道Redis 是基于内存的数据库,一旦服务器的进程退出,数据库数据就会随之丢失,这不是我们想看到的,为了避免这个问题,Redis 为我们提供了俩种持久化方案,将数据保存到磁盘上去,避免数据的丢失。

数据的持久化存储是 Redis 的重要特性之一,它能够将内存中的数据保存到本地磁盘中,实现对数据的持久存储。这样即使在服务器发生故障之后,也能通过本地磁盘对数据进行恢复。

RDB 

RDB 即快照模式,它是 Redis 默认的数据持久化方式,它会将数据库的快照保存在 dump.rdb 这个二进制文件中。

RDB持久化产生的RDB文件是一个经过压缩的二进制文件,这个文件被保存在硬盘中,redis可以通过这个文件还原数据库当时的状态。

RDB 持久化提供了两种触发策略:一种是手动触发,另一种是自动触发。

手动触发是通过SAVAE命令或者BGSAVE命令将内存数据保存到磁盘文件中。

  • SAVE:阻塞redis的服务器进程,直到RDB文件被创建完毕。
  • BGSAVE:派生(fork)一个子进程来创建新的RDB文件,记录接收到BGSAVE当时的数据库状态,父进程继续处理接收到的命令,子进程完成文件的创建之后,会发送信号给父进程,而与此同时,父进程处理命令的同时,通过轮询来接收子进程的信号。

 自动触发策略,是指 Redis 在指定的时间内,数据发生了多少次变化时,会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中:


# 以下配置表示的条件:
# 服务器在900秒之内被修改了1次
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000
  • save 900 1 表示在 900 秒内,至少更新了 1 条数据,Redis 自动触发 BGSAVE 命令,将数据保存到硬盘。
  • save 300 10 表示在 300 秒内,至少更新了 10 条数据,Redis 自动触 BGSAVE 命令,将数据保存到硬盘。
  • save 60 10000 表示 60 秒内,至少更新了 10000 条数据,Redis 自动触发 BGSAVE 命令,将数据保存到硬盘。

 优点

1.RDB是二进制压缩文件,占用空间小,便于传输(传给slaver);
2.主进程fork子进程,可以最大化Redis性能;
3.使用RDB文件来恢复数据较快。

缺点

1、不保证数据完整性,会丢失最后一次快照以后更改的所有数据;
2、父进程在fork子进程的时候如果主进程比较大会阻塞;

AOF

AOF 被称为追加模式,或日志模式,是 Redis 提供的另一种持久化策略,它能够存储 Redis 服务器已经执行过的的命令,并且只记录对内存有过修改的命令,这种数据记录方法,被叫做“增量复制”,其默认存储文件为appendonly.aof

具体配置可以在配置文件中进行配置:

#AOF 和 RDB 持久化方式可以同时启动并且无冲突。  
#如果AOF开启,启动redis时会加载aof文件,这些文件能够提供更好的保证。 
appendonly yes

# 只增文件的文件名称。(默认是appendonly.aof)  
# appendfilename appendonly.aof 
#redis支持三种不同的写入方式:  
#  
# no:不调用,之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。  
# always: 每次更新数据都写入仅增日志文件。慢,但是最安全。
# everysec: 每秒调用一次。折中。
appendfsync everysec  

# 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no  

# 自动重写只增文件。  
# redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件,如果日志文件增长了指定的百分比。  
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100  
# 当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

服务器配置中有一项appendfsync,这个配置会影响服务器多久完成一次命令的记录:

  • always:将缓存区的内容总是即时写到AOF文件中。
  • everysec:将缓存区的内容每隔一秒写入AOF文件中。
  • no :写入AOF文件中的操作由操作系统决定,一般而言为了提高效率,操作系统会等待缓存区被填满,才会开始同步数据到磁盘。

redis默认实用的是everysec

在RDB和AOF备份文件都有的情况下,redis会优先载入AOF备份文件

Redis 在长期运行的过程中,aof 文件会越变越长。如果机器宕机重启,“重演”整个 aof 文件会非常耗时,导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动。Redis 提供了 AOF 重写机制,手动执行BGREWRITEAOF命令,开始重写 aof 文件

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
  • 新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致;
  • 新的 aof 文件会使用尽可能少的命令来记录数据库数据,因此新的 aof 文件的体积会小很多;
  • AOF 重写期间,服务器不会被阻塞,它可以正常处理客户端发送的命令

优点

  • 更好的保护数据不丢失,性能高,可做紧恢复

缺点

  • 等量级的命令,AOF持久化文件要大于RDB持久化文件
  • 恢复速度慢于RDB

总结

RDB持久化 AOF持久化
全量备份,一次保存整个数据库。 增量备份,一次只保存一个修改数据库的命令。
每次执行持久化操作的间隔时间较长。 保存的间隔默认为一秒钟(Everysec)
数据保存为二进制格式,其还原速度快。 使用文本格式还原数据,所以数据还原速度一般。
执行 SAVE 命令时会阻塞服务器,但手动或者自动触发的 BGSAVE 不会阻塞服务器 AOF持久化无论何时都不会阻塞服务器。

如果进行数据恢复时,既有 dump.rdb文件,又有 appendonly.aof 文件,您应该先通过 appendonly.aof 恢复数据,这能最大程度地保证数据的安全性。 

你可能感兴趣的:(闲聊杂谈,java,服务器,数据库,开发语言,springboot,redis,缓存)