Redis持久化学习笔记（AOF与RDB详细）

最新推荐文章于 2024-09-27 22:00:54 发布
最新推荐文章于 2024-09-27 22:00:54 发布
阅读量626 收藏 8
点赞数 1
分类专栏： Redis 文章标签： Redis持久化
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35362055/article/details/83651110
版权

Redis持久化

  • 首先是一张整理好的思维导图在这里插入图片描述

Redis持久化有两种方式，rdb和aof：

  • rdb会保存一个时间点的数据快照
  • aof会记录每一个服务器收到的写操作。在服务器启动时，这些记录的操作会逐行从aof文件中执行，从而重建原先的数据集。写操作命令记录的格式与Redis协议一致，以追加的方式进行保存
  • Redis持久化可以禁用
  • Redis两种持久化方式可以同时存在，重启redis时，aof优先用于重建

RDB

工作原理

  • redis调用fork()，产生一个子进程
  • 子进程把数据写到临时的rdb文件中
  • 当子进程写完新的rdb文件后，把旧的rdb文件替换掉

优点

  • rdb快照是一个简洁的单文件，保存了某个时间点的redis数据集
  • rdb适合做灾备，单个rdb文件能很方便的进行传输
  • 性能好。因为进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的IO操作
  • 在数据量较大的情况下，rdb启动得更快

缺点

  • 很容易造成数据的丢失，假设每5min保存一次，出现意外的话，我们可能丢失4min59s的数据
  • rdb使用fork产生子进程进行数据的持久化，如果数据比较大的话可能会花费点时间，造成redis停止服务几毫秒，如果数据量很大且cpu性能不是很好的时候，停止服务的时间甚至会到1s

rdb的启用和禁用

使Redis如果在每N秒后数据发生了M次改变就自动保存快照文件。

# 格式为：save <seconds> <changes>
# 可以设置多个。
save 900 1 #900秒后至少1个key有变动
save 300 10 #300秒后至少10个key有变动
save 60 10000 #60秒后至少10000个key有变动

禁用快照保存功能

save ""
其他的自动触发rdb的方式
  • 从节点全量复制时，主节点发送rdb给从节点完成复制操作，主节点会触发bgsave
  • 执行debug reload时
  • 执行shutdown时，如果没有开启aof，也会触发

如果rdb时发生错误

默认情况下，如果redis在后台rdb时失败，Redis则会停止接受更新操作，这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题，可能会造成灾难。 如果后台存储（持久化）操作进程再次工作，Redis会自动允许更新操作。然而，如果你已经恰当的配置了对Redis服务器的监视和备份，你也许想关掉这项功能。如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。

stop-writes-on-bgsave-error yes

数据压缩配置

默认redis会采用lzf（一种压缩算法）对数据进行压缩，禁用掉可以节省cpu

rdbcompression yes

数据校验配置

从版本5的RDB的开始，一个CRC64的校验码会放在文件的末尾。这样更能保证文件的完整性，但是在保存或者加载文件时会损失一定的性能（大概10%）。如果想追求更高的性能，可以把它禁用掉，这样文件在写入校验码时会用0替代，加载的时候看到0就会直接跳过校验。

rdbchecksum yes

手动生成快照

有两个命令

SAVE

SAVE会使用同步的方式生成RDB快照文件，这意味着在这个过程中会阻塞所有其他客户端的请求，直到持久化完成。因此不建议在生产环境使用，除非因为某种原因需要去阻止redis使用子进程进行后台生成快照。

BGSAVE

BGSAVE命令该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。而我们可以使用LASTSAVE命令查看操作的结果。

127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> LASTSAVE
(integer) 1433936394

配置文件里禁用了快照生成功能不影响SAVE和BGSAVE命令的效果

BGSAVE的原理

这里注意的是fork操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的最大内存，来尽可能降低Redis在fork时的时间消耗。以及上面提到的自动触发的频率减少fork次数，或者手动触发，根据自己的机制来完成持久化。

关于fork操作

  • 同步操作 ，fork 是一个同步操作

    • 当执行一个 bgsave 或 bgrewriteaof 首先会执行一个 fork 操作，它只是做一个内存页的拷贝，并不是拷贝所有内存，所以他的速度是非常快的。
    • 当 fork操作比较慢或卡在某一个点，这时它会阻塞redis主线程

  • 与内存量息息相关：内存越大，消耗越长（与机器类型有关）

  • info：latest_fork_usec – 可以查看 fork 的执行时间

改善fork

  • 优先使用物理机或者高效支持fork操作的虚拟化技术

  • 控制Redis 实例最大可用内存：maxmemory

  • 合理配置Linux内存分配策略：vm.overcommit_memory = 1

  • 默认是0，当发现没有足够内存做内存分配时，就会不去分配。对于fork讲，会造成fork阻塞。

  • 降低fork频率：例如放宽AOF重写自动触发机制，不必要的全量复制

    —— 常见的持久化开发运维问题

    总之就是数据量越大fork卡顿的时间就会越长

AOF

由于rdb容易丢失最新的数据，所以aof提供了一种更可靠的持久化方式。每当redis接受到修改命令时，就会把命令追加到aof文件里去，当重启redis服务时，aof里的命令会被重新执行一次，重建数据。

工作过程

  1. 命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
  2. 缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。
  3. 文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾。如果设定的 AOF 保存条件被满足的话， fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。

优点

  • 更可靠。有三种模式不进行fsync(fsync是指把缓存中的写指令记录到磁盘中) ，每秒一次fsync，每次修改进行fsync。一般用每秒一次的，意味着你最多丢失一秒钟的数据。
  • aof日志文件是一个纯追加的文件。不会出现日志损坏问题，海域redis-check-aof可以进行修复文件
  • aof文件太大时，redis支持后台自动重写。重写是在一个新的文件上进行，同时redis继续往旧的aof文件中追加数据。新文件上会写入能重建当前数据集的最小操作命令集合。重写完毕后，redis会将新的aof文件替换掉旧的aof，然后把数据开始写到新文件上。
  • AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。例如我们不小心用FLUSHALL命令把所有数据刷掉了，只要文件没有被重写，我们可以把服务停掉，把最后那条命令删掉，然后重启服务，这样就能把被刷掉的数据恢复回来。

缺点

  • aof文件较大于rdb
  • 每秒一次fsync，每次修改进行fsync策略下，速度慢于rdb

相关的配置

appendony yes ##启用aof
dir ./ ##文件存放目录，与rdb共用
appendfilename ##默认文件名

## fsync策略（三种）
appendfsync always ## 每当有新命令追加到AOF的时候调用fsync。速度最慢，但是最安全。
appendfsync everysec ## 每秒fsync一次。速度快（2.4版本跟快照方式速度差不多），安全性不错（最多丢失1秒的数据）。
appendfsync no ## 从不fsync，交由系统去处理。这个方式速度最快，但是安全性一般。

关于appendfsync no的说明

在这种模式下，在写入内存的aof_buf后，redis仅仅将aof_buf写入到aof文件中，但不会调用fsync 函数或者 fdatasync 函数将写入的内容真正地保存到磁盘中。

在这种模式下，真正的保存只会在一下任意一种情况中被执行：

  • redis被关闭
  • aof功能被关闭
  • 系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行）

这三种情况都会引起redis主进程阻塞，always的保存功能是由redis主进程执行的，所以也会阻塞。everysec中，保存功能是由子进程进行的，所以不会引起主进程阻塞。

其日志重写原理

当写操作命令不断增加时，aof文件会不断增大，有一种aof文件优化思路是“只需要重建能够恢复当前状态的aof文件即可，也就是说如果有一个递增的计数器到100次，新的aof文件只需要记录其最后的值即可”。

重写流程如下

  • redis首先fork出一个子进程
  • 子进程根据当前数据集把新的aof写到一个临时文件里
  • 主进程持续把新的变动写到内存的buffer里和旧的aof文件里（这样可以保证重写失败数据也不会丢失）
  • 当子进程完成重写后给主进程一个信号，然后把内存里的buffer追加到新的aof里。
  • 替换新旧aof文件

在我看来，主进程将新的变动写到旧的aof里是一个备用手段，这样可能降低了一部分性能，但保证了数据的安全

  • 重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
  • 不管是RDB还是AOF都是先写入一个临时文件，然后通过 rename 完成文件的替换工作。

重写相关的命令

# Redis会记住自从上一次重写后AOF文件的大小（如果自Redis启动后还没重写过，则记住启动时使用的AOF文件的大小）。
# 如果当前的文件大小比起记住的那个大小超过指定的百分比，则会触发重写。
# 同时需要设置一个文件大小最小值，只有大于这个值文件才会重写，以防文件很小，但是已经达到百分比的情况。

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

# 要禁用自动的日志重写功能，我们可以把百分比设置为0：
auto-aof-rewrite-percentage 0

# 手动触发重写
bgrewriteaof

数据损坏修复

如果因为某些原因（例如服务器崩溃）AOF文件损坏了，导致Redis加载不了，可以通过以下步骤进行修复：

  1. 备份AOF文件。

  2. 使用redis-check-aof命令修复原始的AOF文件：

$ redis-check-aof --fix

  1. 可以使用diff -u命令看下两个文件的差异。

  2. 使用修复过的文件重启Redis服务。

从RDB切换到AOF

  • 备份一个最新的dump.rdb的文件，并把备份文件放在一个安全的地方。

  • 运行以下两条命令：

    $ redis-cli config set appendonly yes # 打开aof
$ redis-cli config set save "" # 关闭rdb

  • 确保数据跟切换前一致。

  • 确保数据正确的写到AOF文件里。

  • 如果有需要，更改redis.conf中启用aof和关闭rdb，因为命令行方式修改配置在重启Redis后就会失效。

第二条命令是用来禁用RDB的持久化方式，但是这不是必须的，因为你可以同时启用两种持久化方式。

备份

建议的备份方法：

  • 创建一个定时任务，每小时和每天创建一个快照，保存在不同的文件夹里。
  • 定时任务运行时，把太旧的文件进行删除。例如只保留48小时的按小时创建的快照和一到两个月的按天创建的快照。
  • 每天确保一次把快照文件传输到数据中心外的地方进行保存，至少不能保存在Redis服务所在的服务器。

线上性能建议

  • 如果redis数据不是特别重要或者可以通过其他方式重写生成数据，可以关闭持久化
  • 自己制定策略定期检查redis情况，然后可以手动触发备份、重写数据
  • 单机多个实例的话，要防止多个机器同时运行持久化或重写操作，防止出现内存、cpu、io资源竞争，让持久化变为串行
  • 加入主从机器，从从机上进行备份
  • rdb与aof可以同时存在，可以配合使用

参考文章

反正CPU闲着也是闲着
关注
专栏目录
深入学习 Redis - 谈谈你对 Redis 的 RDB、AOF、混合持久化的了解吧？
CYK_byte的博客
08-05 1586
bgsave 操作流程是通过 fork 创建子进程，让子进程来完成持久化操作~ 持久化就会把要生成的快照数据先保存到一个临时文件中，当这个快照生成完后，再删除之前的 rdb 文件，把新生成临时 rdb 文件名字改成刚才的删除的 rdb 文件的名字，然后使用新的文件替换旧的文件（rdb 对于 fork 之后的新数据，就置之不理了，这里要对比着 aof 来看）.Ps：这后台处理是怎么做到的？并非如此，实际上这是一个 并发编程 的场景，此处 redis 使用的是 “多进程” 的方式来完成并发编程。
Redis 持久化之RDB和AOF.doc
10-09
Redis 持久化是确保数据安全的重要机制，它提供了两种主要的方法：RDB（Redis Database）和 AOF（Append Only File）。RDB 是一种快照式的持久化方式，而 AOF 则记录每次写操作的日志。 RDB 持久化在特定条件下将...
Redis持久化方式AOF和RDB(一)RDB
笔头先生
05-16 1668
跳转到------Redis持久化方式--&gt;AOFRedis持久化RDB（Redis DB）------数据AOF（AppendOnlyFiel）------命令默认情况下，RDB开启，AOF不开启。这两种形式都可以将存储在内存中的数据库数据以文件形式保存到硬盘中，防止数据丢失。...
Redis学习笔记——持久化RDB和AOF
shen的博客
09-22 232
RDB（Redis DataBase） 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读入到内存里。 Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。 如果需要进行大规模...
【Redis】持久化机制--RDB和AOF
最新发布
qq_45875349的博客
09-27 1305
文章介绍了Redis的两种持久化机制以及其详细的流程、细节问题。
Redis持久化（RDB、AOF）
一个闲人
07-03 1568
过期的数据不再写入文件；**无效的命令不再写入文件： ** 如有些数据被重复设值(set ydq 123， set ydq 321)、有些数据被删除了(set ky20 ydq 、 rename ky20 kgc、del kgc。三条一起执行的语句没有意义就会被删除。) 等。如sadd myset 123, sadd myset 1234，sadd myset 12345 可以合并为sadd myset123 1234 12345。
redis持久化:RDB和AOF
qi341500的博客
11-25 1583
redis持久化有两种方式：RDB和AOF RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。 AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据
【Redis】深入理解 Redis 持久化机制 —— RDB 和 AOF
qq_61635026的博客
09-15 4768
虽然 Redis 是一个内存数据库，但由于各种原因，如 Redis 服务器的重启、意外崩溃等，内存中的数据可能会丢失。为了确保数据的持久性和可靠性，Redis引入了持久化机制，允许将数据定期保存到磁盘中，以便在下次启动 Redis 时能够恢复原来的数据到内存中。 Redis 的持久化机制是 Redis 数据库的一个重要组成部分，它允许将内存中的数据以不同的方式写入磁盘，以防止数据丢失。这对于许多应用场景非常关键，特别是需要长期保存数据或具有高可用性要求的系统。
Redis持久化RDB和AOF区别详解
12-14
为了确保数据在服务器重启或异常情况下的安全，Redis提供了两种主要的持久化机制：RDB（Redis Database Persistence，即快照）和AOF（Append Only File，追加日志）。下面将详细解释这两种持久化方式的区别。 **RDB...
Redis学习笔记——持久化RDB与AOF
qq_37863891的博客
04-06 158
文章目录持久化RDBRDB的启动方式savesave具体指令save指令相关配置save工作原理bgsavebgsave具体指令bgsave指令相关配置bgsave工作原理自动调用bgsaveRDB的特殊启动方式RDB优缺点优点缺点AOFAOF写数据三种策略(appendfsync)AOF功能开启相关配置AOF重写手动重写自动重写RDB与AOF区别两者优缺点RDB与AOF的选择之惑 持久化 所谓的...
Redis学习笔记(一)：Redis持久化——RDB与AOF
蛋壳城堡
09-02 371
引子 前两天晚上下班的时候，和朋友走在路上聊起了Redis的主从复制与哨兵模式。突然觉得自己对这一块的知识还没有一个比较系统化的了解。所以，现在就开始仔细学习一下相关的知识，整理一下Redis相关的知识点，这里做个记录，同时也希望能帮助到大家。 系统环境 CentOS 7.6.1810 Redis 5.0.5 Redis安装 这里，我将简单记录下Redis安装的一些关键命令，...
Redis持久化：RDB和AOF
qq13321123的博客
05-11 1631
在 Redis 执行“写”指令的过程中，内存数据一直会变化，所谓内存快照，指的就是 Redis 内存中数据在某一时刻的状态数据，好比时间定格在某一时刻。当我们拍照时，通过照片就能把某一时刻的瞬间画面完全记录下来。Redis 跟这个类似，就是把某一刻的数据以文件的形式拍下来，写到磁盘上，这个快照文件叫做 RDB 文件，RDB 就是 Redis Database 的缩写。
redis学习笔记——RDB和AOF持久化一
weixin_30593261的博客
08-03 148
为防止数据丢失，需要将 Redis 中的数据从内存中 dump 到磁盘，这就是持久化。Redis 提供两种持久化方式：RDB 和 AOF。Redis 允许两者结合，也允许两者同时关闭。 RDB 可以定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集。 AOF(append only file) 可以记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行...
Redis持久化（RDB、AOF）详解
喻师傅的学习笔记
06-25 2961
Redis持久化机制详解
Redis 数据存储位置 导出数据
chenrui310的博客
02-18 7276
文章 Redis 快照持久化学习笔记 介绍 Redis 快照持久化的功能，除了快照持久化外，Redis 还提供了 AOF（Append Only File）持久化功能。与快照持久化通过直接保存 Redis 的键值对数据不同，AOF 持久化是通过保存 Redis 执行的写命令来记录 Redis 的内存数据。 AOF 持久化的原理 理论上说，只要我们保存了所有可能修改 Redis 内存数据的命令（也...
redis学习笔记之持久化(AOF&RDB)
小贱的博客
05-10 1291
概述 redis将数据全部在内存中，如果一不小心宕机，那么数据就会丢失，为了解决这个问题redis通过持久化来解决这个问题。在redis中持久化分为两种：RDB(redisDataBase)和AOF(append only file)，接下来我们简单了解下这两种持久化机制。 RDB(redisDataBase) 实现原理 RDB持久化是通过COW(copy on write)机制来实现持久化的。通过fork产生一个子进程，将数据进行遍历读取，然后序列化写到磁盘中。子进程只会对数据进行持久化，并不会对
面试中经常被问到的 Redis 持久化与恢复
weixin_33845881的博客
03-25 173
本文主要讲了 Redis 的持久化相关功能，持久化一直是影响 Redis 性能的高发地，也是面试中经常被问到的。包括 RDB 相关的特定和优缺点，AOF 的优缺点，事实上，由于 RDB 的数据实时性问题，目前用 AOF 比较多了。而持久化恢复也是优先 AOF。RDB 是旧的模式，现在基本上都使用 AOF。当然，两个都会一起说到。RDBRDB 流程图RDB 特点RDB 是一种快照模式，即——保存的是...
Redis持久化
二次方生存
02-25 471
FROM: https://www.toutiao.com/a6660250022401016327/?tt_from=weixin&amp;utm_campaign=client_share&amp;wxshare_count=1&amp;timestamp=1550713408&amp;app=news_article&amp;utm_source=weixin&amp;iid=5968615...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值