Redis的RDB和AOF持久化

最新推荐文章于 2024-06-19 08:39:38 发布

一个故事开始的地方

最新推荐文章于 2024-06-19 08:39:38 发布

阅读量184

点赞数

分类专栏： Redis

本文链接：https://blog.csdn.net/weixin_44085648/article/details/103334843

版权

Redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Redis的RDB和AOF持久化

1.Redis（全称：Remote Dictionary Server 远程字典服务）是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。（摘抄百度百科）
2.redis的持久化有两种方式第一种rdb、另一种aof，rdb是生成快照，aof是追加操作命令，两种类型的持久化方式。

一、Redis的RDB持久化

RDB持久化模式，阻塞（save）和非阻塞（bgsave）
阻塞：save执行该指令时，阻塞当前redis服务器，执行 save 指令期间，redis不能处理其他命令，直到RDB过程完成为止。
非阻塞：bgsave执行该命令时，redis会在后台异步执行快照操作，此时redis仍然可以响应客户端请求。
RDB持久化触发条件，手动触发（save）和自动触发（bgsave）
手动触发：这种方式会阻塞redis服务。
自动触发：这种方式不会阻塞redis服务。
默认是开启RDB持久化方式，在redis配置文件中配置如下。
save 900 1 # 表示900 秒内如果至少有 1 个 key 的值变化，则触发RDB
save 300 10 # 表示300 秒内如果至少有 10 个 key 的值变化，则触发RDB
save 60 10000 # 表示60 秒内如果至少有 10000 个 key 的值变化，则触发RDB
RDB持久化优缺点
优点：RDB文件占用小，非常适合定时备份，用于灾难恢复，RDB恢复时候是加载RDB文件即可恢复。
缺点：服务器故障时丢失的数据无法找回，其次fork子进程期间发生阻塞，但是一般时间都很短，如果Redis数据量特别大，fork子进程时间就会变长，而且占用内存会加倍。
RDB恢复数据：redis服务重启时候会加载RDB文件进行恢复操作。
RDB格式：是二进制数据段。
redis的RDB具体持久操作流程是，redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后会对原文件进行覆盖，并且通知父进程已经同步成功。

二、Redis的AOF持久化

AOF持久化模式，非阻塞
非阻塞：AOF持久化时，redis会在后台异步执行追加命令操作，此时redis仍然可以响应客户端请求。
AOF持久化触发条件，自动触发
自动触发：这种方式不会阻塞redis服务。
默认是关闭AOF持久化方式，在redis配置文件中配置如下。
appendonly yes #开启AOF持久化
appendfsync everysec #属性可以指定刷盘策略默认是everysec，也可以指定下面参数
always：表示每一个命令都同步缓存区的数据到AOF文件中，效率差但是安全，只会在服务故障时候丢失一个命令数据。
everysec：表示每一秒同步缓存区的数据到AOF文件中，效率快，只会在服务故障时候丢失一秒数据。
no：表示由操作系统控制同步缓存区的数据到AOF文件中，速度快，但是间隔时间长，服务故障时候丢失较多数据。
总之刷盘频率快，则读写效率下降，但是安全性高，发生宕机丢失数据较少。
AOF恢复数据：redis服务重启时候会创建一个伪客户端读取AOF文件，分析每一条命令执行后则恢复数据。
AOF重写：AOF重写会进行大量的写入操作，将被长时间阻塞，所以redis会创建一个子进程执行AOF重写操作，子进程进行AOF重写期间redis主进程还可以继续处理其他命令操作，子进程会将内存数据拷贝一份，保证数据安全，但是在子进程重写期间redis接收的命令会对现有的数据进行修改操作，从而导致当前的数据和重写后的AOF文件中的数据不一致，为解决数据不一致问题redis设置一个AOF重写缓冲区，这个缓存区在redis在fork子进程之后开始使用，当redis执行完一个命令之后，它会写入AOF缓冲区同时也会写入AOF重写缓冲区，当子进程完成AOF工作后，会通知父进程AOF重写完毕。
父进程将会处理下面操作
1.AOF重写缓冲区中的所有数据写入到新的AOF文件中，保证AOF文件数据是最新和当前AOF缓冲区保持一致。
2.会对新的AOF文件修改名字，新的AOF文件替换旧的AOF文件。
AOF重写触发条件，手动触发和自动触发
手动触发：直接调用bgrewriteaof命令。
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
在redis配置文件中配置如下
auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
auto-aof-rewrite-percentage：表示当前AOF文件空间和上一次重写后AOF文件空间的比值。
假设一下：
auto-aof-rewrite-min-size：1MB
auto-aof-rewrite-percentage：100
理论是下面这样，以此类推：
当AOF文件第一次到1M时候，触发重写策略
当AOF文件第一次到2M时候，触发重写策略
当AOF文件第一次到4M时候，触发重写策略
实际是下面这样。以此类推：
当AOF文件第一次到1M时候，触发重写策略
当AOF文件第一次到1.6M时候，触发重写策略
为什么会这样，思考中。。。。。。
其实因为重写的目地就是以通过合并命令的方式减少文件大小，到1M时候触发重写，重写后必然大小是小于1M的
按照这个思路推算：
第一次AOF文件大小1M触发重写，重写后大小变为0.8M
第二次AOF文件大小1.6M触发重写，重写后大小变为2.8M
6.AOF优缺点
优点：AOF更好的保证数据不丢失，everysec一秒一次刷盘，文件使用append-only模式追加命令，
节省硬盘开销，性能高，AOF重写机制会压缩文件，同时重写期间也不影响其他操作，适合做灾难性误删操作恢复
如果有人执行flusall命令，清空全部数据操作，只要没有触发重写操作和RDB操作，可以立即备份AOF文件，将最后一条 flusall命令删除，替换旧的AOF文件实现灾难性误删操作恢复。
缺点：AOF持久化相对于RDB持久化文件更大，恢复数据慢。
AOF恢复数据：redis服务重启时候会创建一个伪客户端读取AOF文件，分析每一条命令执行后则恢复数据。
8.AOF格式：是文本数据段。
9.redis的AOF具体持久化操作流程是，所有的写命令会追加到AOF缓存区，AOF会根据配置文件中的策略进行刷盘操作，
随着AOF文件越来越大，需要进行对AOF文件进行重写，达到压缩文件的目的，AOF文件其实内容是命令每个命令都会追加到AOF文件。

三、RDB和AOF对比

RDB	AOF
体积：小	体积：大
恢复速度：快	恢复速度：慢
数据安全性：丢数据	数据安全性：根据策略决定

四、RDB和AOF选择

1.不要单独使用RDB，因为会导致丢失很多数据（系统能够容忍除外）
2.不要仅仅使用AOF，因为那样有两个问题
（1）没有RDB备份数据效率好，RDB可以避免AOF这种复杂的备份。
（2）没有RDB恢复数据速度快，RDB可以避免AOF这种复杂的恢复。
3.综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复数据的第一选择，用RDB来做不同程度的备份，在AOF文件丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。RDB你会丢失很多数据时候，AOF数据恢复没RDB来的快，真的redis服务不可用恢复的第一时间用RDB恢复，然后AOF做数据补全，其实说这么说最终还是要看业务而定。

五、RDB和AOF之间的相互作用

1.bgsave执行的过程中，不可以执行bgrewriteaof，反之，在bgrewriteaof执行的过程中，也不可以执行bgsave，这样可以防止两个后台进程同时对磁盘进行大量的I/O操作。
假设如果bgsave正在执行，并且用户调用bgrewriteaof命令，那么redis服务器将会向用户返回一个OK状态，并告知客户端，bgrewriteaof已经被预定执行，一旦bgsave执行完毕， bgrewriteaof就会正式开始。

2.当redis启动时，如果RDB持久化和AOF持久化都被打开了，那么程序会优先使用AOF文件来恢复数据，因为AOF文件所保存的数据通常是最完整的。

欢迎大家关注公众号

一个故事开始的地方