redis（二）RDB持久化和AOF持久化

最新推荐文章于 2021-12-06 11:27:36 发布

stay hungry,stay you

最新推荐文章于 2021-12-06 11:27:36 发布

阅读量107

点赞数

分类专栏： redis

本文链接：https://blog.csdn.net/weixin_41987908/article/details/104903108

版权

redis 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

Redis持久化备份数据的方式有两种：RDB(Redis DataBase) 、 AOF(Append Only File)。

（一）RDB持久化

RDB持久化是把当前进程的数据已快照的形式保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。它恢复时是将快照文件直接读到内存中，来达到恢复数据的。RDB持久化所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态。

手动触发命令：save和bgsave（可以触发生成RDB文件）

save：阻塞式，内存较大的实例在执行过程中会造成长时间的阻塞，影响主进程上的正常服务请求。

bgsave：fork子进程，RDB持久化的过程在子进程中进行，完成后自动结束进程。阻塞发生在fork阶段，时间较短

save和bgsave区别：

1：Redis是单进程单线程模型，执行save命令时会调用rdbSave,Redis会被阻塞直到保存完为之，主进程阻塞期间服务器不能处理客户端发出的任何请求。
2：Bgsave则fork出一个子进程，子进程负责带调用rdbSave，并在保存完成之后向主进程发出信号，通知保存已经完成。因为rdbSave在在子进程被调用，所有Redis服务器在执行Bgsave期间仍然可以处理客户端请求。
3：Bgsave在执行期间，客户端发送的save请求将被服务器拒绝，防止两者竞争。
4：Save命令执行的时rdb.c/rdbSave 函数，Bgsave命令执行的是rdb.c/rdbSaveBackground函数。

自动触发：满足RDB持久化条件后会自动执行持久化过程。

触发条件：

(1) 使用save相关配置
在Redis.conf 中配置持久化策略

配置格式：save <seconds> <changes> 表示<seconds>秒内数据集存在<changes>次修改时，自动触发bgsave。
       默认配置：
       # 900是ms 次数是一次（900毫秒内发生一次就持久化）
       save 900 1
       save 300 10
       save 60 10000
       #设置在保存快照出错时，是否停止redis命令的写入。例如 fork子进程内存不足或rdb文件所在的文件夹没有写入权限则不需要持久化则设为no 默认是yes
       stop-writes-on-bgsave-error yes   
       #是否在导出.rdb文件时采取LZF压缩
       rdbcompression yes 
       #到处数据库的文件每次
       dbfilename dump.rdb
       #是否开启CRC64校验
       rdbchecksum yes
       #导出数据库所在的目录
       dir ./

实现原理：

     # serverCron服务定时器每100ms执行一次检查
       if(now()-rdb_last_save_time < m(指定秒数) and  rdb_changes_since_last_save>n(修改次数)){
             bgsave();
       }

(2)从节点执行全量复制操作

(3)debug reload命令

(4)shutdown命令，如果没有开启aof自动执行bgsave

RDB持久化步骤：

1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回
2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。通过触发快照的形式，来做到将指定时间间隔内的数据持久化到dump.rdb。例如，可以2分钟内持久化一次，将对数据库的写操作，备份到磁盘上的dump.rdb。如何触发持久化呢？可以通过查看或者设置redis.conf配置文件来指定触发规则。

命令：

config set save “20 2” 动态修改rdb持久化条件
rdbconfig set dbfilename 和config set dir可以修改rdb文件的目录
config set rdbcompression 【yes|no】指定是否压缩

RDB优点与缺点：

优点：

1：如果要进行大规模数据的恢复，RDB方式要比AOF方式恢复速度要快。
2：RDB可以最大化Redis性能，父进程做的就是fork子进程，然后继续接受客户端请求，让子进程负责持久化操作，父进程无需进行IO操作。
3：RDB是一个非常紧凑(compact)的文件,它保存了某个时间点的数据集，非常适合用作备份，同时也非常适合用作灾难性恢复，它只有一个文件，内容紧凑，通过备份原文件到本机外的其他主机上，一旦本机发生宕机，就能将备份文件复制到redis安装目录下，通过启用服务就能完成数据的恢复。

缺点：

1：Redis意外宕机时，会丢失数据
2：当Redis数据量比较大时，fork的过程时非常耗时的，fork子进程是会阻塞的，在这期间Redis就会出现服务器暂停客户端请求
3：RDB文件的致命缺点是在于其数据快照的持久化方式决定了必然做不到实时持久化。而在数据越来越重要的今天，数据的大量丢失时无法接受的，因此AOF是主流。
4：RDB文件需要满足特定格式，兼容性差。redis版本变了可能就不能通用了。

载入RDB文件:

是由rdb.c/rdbLoad函数完成

文件校验：

对于错误格式的RDB文件，用redis-check-rdb工具进行修复

AOF和RDB文件载入条件：
在这里插入图片描述
（二）AOF持久化

AOF持久化是通过保存Redis服务器所执行的写命令(包括删除，修改，新增)来记录数据库状态，也就是每当Redis执行一个改变数据集命令时(比如set),这个命令就会被追加到AOF文件的末尾。

开启AOF：

修改redis,conf文件把默认的appengonly no(关闭)改为appengonly yes(开启)。

执行流程：

1：所有的写入命令会追加到aof_buf（缓冲区）中（如果每次都直接写入硬盘回导致硬盘IO成为Redis的性能瓶颈）。
2：AOF缓冲区根据对应的策略向硬盘做同步操作。
3：随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4：当Redis服务器重启时，可以加载AOF文件进行数据恢复。

AOF文件采用文本协议格式的好处：

1：文本协议具有很好的兼容性。
2：文本协议具有可读性，方便直接修改和处理。
3：开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。

文件同步和文件写入：

文件写入：只是写入到了内存缓存区，可能还没有同步到硬盘
文件同步：将内存缓存区的内容刷新到硬盘上。

AOF文件的载入：

aof-load-truncated作用：
Redis载入AOF文件时，会对AOF文件进行校验如果文件损坏则日志会打印错误信息，则Redis去启动失败。但是如果AOF文件结尾不完整(机器突然宕机容易导致文件尾部不完整)。如果 aof-load-truncated开启则会输出警告，Redis忽略文件尾部，Redis启动成功。

AOF文件重写：

重写触发机制：

1：手动触发，直接调用bgrewriteaof命令。
2：自动触发，根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件
空间（aof_base_size）的比值。默认100

即aof超过64M且aof文件是上次aof文件按的两倍。这才触发！！！！

重写工作流程：

1）执行AOF重写请求。如果当前进程正在执行AOF重写则不执行重写操作，如果进程在执行bgsave则等待执行完毕后再执行。
2）父进程执行fork创建子进程，开销等同于bgsave过程。
3.1）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略
同步到硬盘，保证原有AOF机制正确性。
3.2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-
rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。
5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。
5.3）使用新AOF文件替换老文件，完成AOF重写。

AOF配置图：
在这里插入图片描述
AOF优缺点：

优点：

1：支持秒级持久化。
2：可用于不同版本的Redis服务器，兼容性强。
3：AOF文件可读性高，分析容易。

缺点：

文件大，回复速度慢，对性能影响大

（三）AOF持久化
在这里插入图片描述

stay hungry,stay you

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
redis（二）RDB持久化和AOF持久化

   Redis持久化备份数据的方式有两种：RDB(Redis DataBase) 、 AOF(Append Only File)。（一）RDB持久化   RDB持久化是把当前进程的数据已快照的形式保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。它恢复时是将快照文件直接读到内存中，来达到恢复数据的。RDB持久化所生成的...
复制链接

扫一扫

专栏目录