百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

Redis持久化RDB和AOF,看这一篇就够了

nanshan 2025-05-22 12:23 4 浏览 0 评论

推荐学习

前言

我们都知道,redis是基于内存的K-V数据库。由于内存是断电易失的,所以redis提供了相应的持久化机制。

本篇主要讲解redis提供的RDB和AOF两种持久化方式,以及他们的实现原理。

RDB

RDB(Redis DataBase)是指把某个时刻内存中的数据生成快照(snapshot),以dump.rdb文件的形式存在磁盘上。RDB每次生成的快照(snapshot)都是redis中的全量数据

生成快照可以由两个命令完成,分别是save和bgsave,先看下这两个命令的描述

127.0.0.1:6379> help save

  SAVE -
  summary: Synchronously save the dataset to disk
  since: 1.0.0
  group: server
127.0.0.1:6379> help bgsave

  BGSAVE -
  summary: Asynchronously save the dataset to disk
  since: 1.0.0
  group: server

从描述上来看,这两个命令实现的功能一模一样,只是save是以同步的方式写入磁盘,而bgsave是以异步的方式,bg就是Background的意思。

事实上调用save命令后,redis进程会被阻塞,直到快照生成完成,期间redis不能对外提供服务。而bgsave会调用Linux的fork()函数来创建一个子进程,让子进程来生成快照,期间redis依然可以对外提供服务

了解了RDB的相关命令,再来思考下这个问题:假设redis中有6G数据,要给这6G数据生成一个快照,不可能在一瞬间完成,肯定会持续一段时间。那么从快照开始生成(t1),到快照生成成功(t2)的这段时间内,redis中被修改的数据应该怎么处理?持久化的数据应该是t1时刻的数据,还是t2时刻的数据呢?

对于save的方式来说,生成快照期间,redis不能对外提供服务,所以在t1到t2期间不会有数据被修改。但是对于bgsave方式来说,生成快照期间,redis依然可以对外提供服务,所以极有可能有些数据被修改。这时子进程是根据t1时刻的数据来生成快照的。t1到t2期间被修改的数据只能在下一次生成快照时处理。但是在t1到t2期间被修改的值,对外部调用方来说是可以实时访问的。也就是说redis不仅要存储快照生成点(t1)时刻的所有值,还要存储变量的最新值。这样的话,redis中6G的数据,在生成快照的时候,会瞬间变成12G。

但是事实并非如此,以性能著称的redis肯定不允许这样的事发生。那这个问题是如果解决的呢?这样就不得不说copy on write机制了

copy on write(COW,写时复制)是一种计算机程序设计领域的优化策略。

其核心思想是,如果有多个调用者(callers)同时请求相同资源(如内存或磁盘上的数据存储),他们会共同获取相同的指针指向相同的资源,直到某个调用者试图修改资源的内容时,系统才会真正复制一份专用副本(private copy)给该调用者,而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的(transparently)。

前文提到调用bgsave时,会调用linux系统的fork()函数来创建子进程,让子进程去生成快照。fork()函数实现了copy on write机制。

如下图所示,redis调用bgsave之后,bgsave调用fork。也就是在t1时刻,内存中的数据并不会为了两个进程而复制成两份,而是两个进程中的指针都指向同一个内存地址。

此时子进程开始生成快照,如果在生成快照期间,redis中的数据被修改了,k3的值由c变成了d。操作系统仅仅会把k3复制一份,而没有变化的k1和k2不会被复制。这就是写时复制(copy on write)机制。可以看到此时子进程取到的数据还是t1时刻的数据,而redis对外提供的服务也能获取最新数据。

此处用copy on write优化的前提是生成快照的过程持续的时间较短期间只有少量的数据发生了变化。如果期间所有的数据都发生了变化,也就相当于真的把6G数据变成了12G。

写时复制是一种优化思想,在JDK中也能看它的实现

配置

前文说RDB模式生成快照的命令是save和bgsave,但是在实际使用redis的时候,也没见我们定期手动执行这两个命令。所以快照的生成还有一种自动的触发方式,在配置文件中可以找到相关的配置

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

save配置表示调用bgsave。save 60 10000表示如果在60秒内,超过10000个key被修改了,就调用一次bgsave。同理save 300 10表示300秒内,超过10个key被修改了,就调用一次bgsave。多个save不是互斥的,如果配置多个save,只要满足其中一个就会执行bgsave,配置多个是为了适应不同的场景。

配置save ""或者注释所有的save表示不开启RDB。

从配置文件配置的save参数来看,如果每60秒执行一次bgsave,而在59秒的时候服务宕机了,这样就丢失了59秒内修改的数据,因为还没来得及生成快照。数据丢失量这么大,肯定是不被允许的。为此,redis还提供了另一种持久化方式,那就是AOF

AOF

AOF(Append Only File)是把对redis的修改命令以特定的格式记录在指定文件中。也就是说RDB记录的是数据快照,而AOF记录的是命令。AOF默认是关闭的。

############################## APPEND ONLY MODE ###############################

# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

如果开启了AOF,相应的命令会记录在appendonly.aof文件中。

appendonly.aof这个文件的内容本身也需要写到磁盘中,如果appendonly.aof还未来得及写入磁盘,服务就宕机了,也会造成appendonly.aof文件内容丢失,而丢失redis的修改命令,进而丢失redis的修改数据。

为此redis为appendonly.aof的持久化提供了三种配置方式:

# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

这三种方式都是通过参数appendfsync来指定。

  • no:并不是不持久化,只将数据写到OS buffer,由操作系统决定何时将数据写到磁盘,这种方式速度最快
  • always:每次在appendonly.aof中追加内容,都调用fsync()将数据写入磁盘,这种方式最慢,但是最安全
  • everysec:默认配置,表示每秒调用一次fsync(),将数据写入磁盘,是一种折中的方式

根据配置可以知道,如果每秒将appendonly.aof的内容写到磁盘一次。那么在两次写磁盘的间隔,如果服务宕机了,还是有可能丢失部分命令,从而导致redis的修改数据丢失,不过相比于RDB来说,这种丢失已经非常非常小了。

除此之外,appendonly.aof文件是以追加的方式写入命令,对于长时间运行的服务,必定会导致该文件过大。万一服务宕机需要根据appendonly.aof文件恢复数据,将会消耗相当长的时间来执行appendonly.aof中记录的命令。

为了解决appendonly.aof文件过大的问题redis提供了一种机制,叫bgrewriteaof。

bgrewriteaof

bgrewriteaof命令描述如下

127.0.0.1:6379> help bgrewriteaof

  BGREWRITEAOF -
  summary: Asynchronously rewrite the append-only file
  since: 1.0.0
  group: server

这个命令的作用就是fork()出一个子进程来对appendonly.aof文件进行重写。这个重写操作在redis4.0以前和4.0以后有不同的实现方式。

redis4.0以前的重写主要有两点:删除抵消的命令合并重复的命令。对于set key1 a和del key1这样相互抵消的命令会被直接删除。对于set key1 a和set key1 b这样重复的命令会进行合并。这样一通操作之后,AOF文件可能会变得很小。

redis4.0之后,开启了RDB和AOF的混合模式。也就是将已有的数据以RDB的方式记录在appendonly.aof文件的头部,对于之后的增量数据以AOF的方式继续追加在appendonly.aof文件中,也就是appendonly.aof文件前半段是快照数据,后半段是redis指令。

这样的混合模式结合了RDB和AOF的优点,既能最大限度的减少数据丢失,又能在Redis重启后迅速恢复数据。

那么在什么情况下会触发bgrewriteaof呢?除了手动触发,配置文件中提供了几个相关参数来实现自动触发

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

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

auto-aof-rewrite-min-size参数设置成64mb,意思是redis尚未执行过bgrewriteaof(从启动开始算),AOF文件需要达到64mb才会第一次执行bgrewriteaof(此后不会再使用auto-aof-rewrite-min-size参数),redis会记录每次执行bgrewriteaof之后,AOF文件的大小。

auto-aof-rewrite-percentage设置成100,表示当前的AOF文件大小超过上一次bgrewriteaof后AOF文件的百分比后触发bgrewriteaof。如果上次bgrewriteaof后,AOF为200mb,现在需要AOF文件达到400mb才会执行bgrewriteaof。

auto-aof-rewrite-percentage设置成0,表示禁用bgrewriteaof。auto-aof-rewrite-min-size参数的作用就是在AOF文件比较小的时候,防止因为增长过快而频繁调用bgrewriteaof。

no-appendfsync-on-rewrite

redis主进程在写AOF文件采用always或者everysec配置,和子进程在重写AOF文件的时候,都会产生大量的I/O操作。可能会使fsync阻塞很长时间,为了缓解这个问题,redis提供了no-appendfsync-on-rewrite这个参数

# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.
#
# In order to mitigate this problem it's possible to use the following option
# that will prevent fsync() from being called in the main process while a
# BGSAVE or BGREWRITEAOF is in progress.
#
# This means that while another child is saving, the durability of Redis is
# the same as "appendfsync none". In practical terms, this means that it is
# possible to lose up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.

no-appendfsync-on-rewrite no

如果开启该参数,表示在bgsave和bgrewriteaof的过程中,主线程写入AOF不会调用fsync(),相当于配置appendfsync no。这样有可能会导致redis的修改命令丢失,Linux默认配置下,最多丢失30秒的数据。

如果关闭该参数,表示在bgsave和bgrewriteaof的过程中,主线程写入AOF会调用fsync(),并且被阻塞,这样是最安全的,不会丢失数据。

总结

本文主要讲解redis两种持久化方式RDB和AOF,以及他们的实现原理。此外,还讲解了AOF文件过大怎么处理。了解这些内容,可以帮助我们更好的使用redis。

作者:Sicimike

原文链接:
https://blog.csdn.net/Baisitao_/article/details/105461153

相关推荐

虚拟机“播放器”:VMware Player 12.0.1下载

IT之家讯免费虚拟机软件VMwareWorkstationPlayer更新至12.0.1,本次更新为维护性更新,同今天更新的WorkstationPro版本一样,解决了某些情况下Skylake...

ZLG嵌入式笔记 | 移动硬盘和虚拟机的那些事儿

在Linux开发中,编译内核是一项常见任务,但不少开发者在移动硬盘或虚拟机环境下尝试时会遭遇失败。本文将简要探讨这些问题的成因,并介绍一些虚拟机使用技巧,帮助大家更好地应对相关问题。在移动硬盘里编译...

IT 技术小课堂「虚拟机」

你知道什么是虚拟机吗?虚拟机就是可以用一台电脑变成多台电脑的计算机魔法。推荐上手最快的虚拟机软件VMwareWorkstation。如果你的物理机是Win10以下的可以安装VMwareWo...

最简单的虚拟机安装黑苹果

给所有还没体验过Macos的人们。本文会以最简单的方式介绍虚拟机安装黑苹果的教程,准备四个工具,一次性安装黑苹果,中间基本不会有出现任何问题。一、准备工具,先把以下工具都准备好,网上搜索即可。1、...

VMware虚拟机与物理机文件交互,这8种方法送给你

上一期我们讲解过用VMWare虚拟机打造一个金刚不坏之身的操作系统,小伙伴们反应说方法不错,只是虚拟机与物理机文件交互方式不好操作,这期应小伙伴们的要求,给大家讲解下虚拟机与物理机文件交互的8种方式,...

VMware虚拟机:第二节安装VMware并创建Win10虚拟机

VMware虚拟机:第二节安装VMware并创建Windows10虚拟机本节我们介绍如何安装VMwareWorkStationPro17.6.2,以及利用VMware创建Windows10虚拟机。...

vSphere环境虚拟机安装VMware Tools(Windows操作系统)

本文描述Windows操作系统的VMwareTools安装。Windows操作系统的VMwareTools安装操作步骤Windows操作系统安装完成后,VMwarevSphere控制台会提示“该...

windows7虚拟机VMware tools报错——一招解决

前言最近,把VMwareworkstation更新到版本17后,在一次安装windows7虚拟机的时候,发现VMwaretools各种安装报错,安装无法正常进行,这可愁坏了我,让我把自己本来不多的...

博通紧急修复VMware Tools高危认证绕过漏洞

IT之家3月26日消息,博通昨日(3月25日)发布安全公告,修复VMwareToolsforWindows中存在的高危认证绕过漏洞(CVE-2025-22230)。该漏洞由俄罗...

linux中如何安装VMwaretools--一定要保存

安装好VMware后,有时候我想把真机的文件放到虚拟机了,除了使用远程工具外,也会用到VMwaretools,今天给大家说说如何安装VMwaretools。其实在网上也可以搜到,只是网上的东西太乱了。...

精品博文解决安装Ubuntu14.04不弹出图像界面的问题

今天遇到一个糗事,不写出来不足以解恨。暑期开始了,给一个辅导班做嵌入式系统的讲座。问题就出在讲完以后系统的安装这个环境。班里面好些同学安装好以后进入不了图像界面,举手问我啊,oh,mygod!就到了这...

虚拟机VMware Workstation 17教程,从入门到精通No.3-vmwaretools

安装VMwareTools是创建新的虚拟机过程的一部分,而升级VMwareTools是使虚拟机更易于使用的关键。尽管客户机操作系统在未安装VMwareTools的情况下仍可运行,但许...

国产操作系统虚拟机安装vm-tools

使用vmwareworkstation安装国产化操作系统虚拟机后,不会像windows一样自动安装vmtools工具,按vmware默认的由虚拟机菜单中安装的方法步骤比较复杂,且最终结果不理想,经实...

VmwareTools的安装 这个功能很强大 #计算机

vmwareTools的安装。现在装完之后,这么点看起来也别扭,怎么办?装工具:vmwaretools。·在这个地方选择虚拟机,虚拟机这里边有安装vmwaretools,安装这个工具点击一下。·下边这...

VMware Tools安装失败?手把手教你本地安装

VMwareTools安装失败?作为虚拟机与物理机之间的"桥梁",VMwareTools能实现文件拖拽、剪贴板共享、分辨率自适应等关键功能。没有它,VMware虚拟机就变得非常不好...

取消回复欢迎 发表评论: