Redis系列：redis持久化（六）

最新推荐文章于 2024-08-19 03:45:32 发布
最新推荐文章于 2024-08-19 03:45:32 发布
阅读量140 收藏 1
点赞数 2
分类专栏： redis 文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37712731/article/details/110367905
版权

序言

在之前的文章种主要介绍了redis的基础部分。在memcache和redis对比中，redis提供可靠的数据持久化方案，而memcache没有数据持久化方案。在这篇文章种我将详细介绍redis所提供的持久化方案：RDB持久化和AOF持久化以及redis新特性混合持久化。
redis的持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。理解掌握持久化机制对于我们学习redis非常重要。

RDB持久化

RDB持久化方式是通过快照(snapshotting)完成的，当符合一定条件时，redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。当redis重启时，在AOF持久化未开启的，redis会读取RDB持久化生成的二进制文件(默认名称dump.rdb，可通过设置dbfilename修改)进行数据恢复，对于持久化信息可以用过命令info Persistence查看。

在这里插入图片描述

触发机制（分为：手动命令触发和自动触发）

手动触发RDB生成快照分别对应save和bgsave命令
（1）save：该命令是强制redis执行快照，这时候redis处于阻塞状态，不会响应任何其他客户端发来的请求，直到RDB快照文件执行完毕，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用（谨慎使用）
在这里插入图片描述
（2）bgsave：bgsave命令可以理解为background save即：“后台保存”。当执行bgsave命令时，redis会fork出一个子进程来执行快照生成操作。需要注意的redis是在fork子进程这个简短的时间redis是阻塞的（此段时间不会响应客户端请求），当子进程创建完成以后redis才可以响应客户端请求。（注：rdb自动触发其实也是使用bgsave来完成的）。下面的图主要是bgsave工作过程：
在这里插入图片描述

（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_*相关选项。

在这里插入图片描述
自动触发RDB的生成快照
（1）使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave

//在redis.conf中配置
save 900 1
save 300 10
save 60 10000

（2）shutdown命令触发就是redis在关闭前处于安全角度将所有数据全部保存下来，以便下次启动会恢复
（3）客户端执行数据库清空命令flushall时候，触发快照保存rdb文件
（4）主从复制时，从库全量复制同步主库数据，此时主库会执行bgsave命令进行快照保存rdb文件

故障恢复

当redis意外崩溃或者关闭再次启动时，此时AOF持久化未开启时(默认未开启)，将使用RDB快照文件恢复数据:
（1）首先我们关闭redis，然后在配置文件中添加log文件的地址：
在这里插入图片描述
（2）我们再启动redis，启动完成后，我可以查看log文件，可以看到加载了rdb文件：
在这里插入图片描述

RDB持久化的配置
#save 900 1  900秒内至少有1个key被改变则做一次快照
#save 300 10  300秒内至少有300个key被改变则做一次快照
#save 60 10000  60秒内至少有10000个key被改变则做一次快照
#关闭该规则使用svae “” 
save m n

#rdb持久化存储数据库文件名，默认为dump.rdb
dbfilename  dump.rdb

#yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件
stop-write-on-bgsave-error yes 

#在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动
rdbchecksum yes

#数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限
dir /usr/local/bin

#是否开启RDB文件压缩，该功能可以节约磁盘空间
rdbcompression yes

AOF持久化

AOF（append only file）持久化，以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。它可以将Redis执行的每一条写命令追加到磁盘文件(appendonly.aof)中,在redis启动时候优先选择从AOF文件恢复数据。由于每一次的写操作，redis都会记录到文件中，所以开启AOF持久化会对性能有一定的影响，但是大部分情况下这个影响是可以接受的，我们可以使用读写速率高的硬盘提高AOF性能。与RDB持久化相比，AOF持久化数据丢失更少，其消耗内存更少(RDB方式执行bgsve会有内存拷贝)。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

开启AOF

在默认的配置文件中，redis是关闭了AOF持久化，开启AOF通过配置appendonly为yes开启，我们修改配置文件或者在命令行直接使用config set修改，在用config rewrite同步到配置文件。（通过客户端修改好处是不用重启redis，AOF持久化直接生效）

[root@izbp19p16mcz7awt4d8kahz bin]# redis-cli
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes
OK
127.0.0.1:6379> config rewrite
OK
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"

在这里插入图片描述

AOF持久化过程

主要分为以下几个阶段：
（1）文件写入（append）：redis将每一条写命令添加至缓冲区aof_buf，采用缓冲区暂存一部分命令随后根据策略一次性写入磁盘，这样可以减少磁盘的I/O次数，提高了性能
（2）文件同步（sync）：当写命令写入aof_buf缓冲区后，redis会将缓冲区的命令写入到文件，redis提供了三种同步策略，由配置参数appendfsync决定，下面是每个策略所对应的含义：

//表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。这种情况下由于每次写命令都写到了文件中, 虽然数据比较安全，但是因为每次写操作都会同步到AOF文件中，所以在性能上会有影响，同时由于频繁的IO操作，硬盘的使用寿命会降低（速度慢）
# appendfsync always 
//使用fsync每秒一次从内核刷新到磁盘，这种方式兼顾了性能和数据安全，所以redis默认推荐使用该配置。
# appendfsync everysec 
 //不同步，这时操作系统自己同步，在linux操作系统中大约每30秒刷一次缓冲。这种情况下，缓冲区数据同步不可控，并且在大量的写操作下，aof_buf缓冲区会堆积会越来越严重，一旦redis出现故障，数据丢失严重
# appendfsync no

（3）文件重写（rewrite）：随着AOF文件会越来越大,需要定期对AOF文件进行重写，达到压缩的目的，redis将使用bgrewriteaof对AOF文件进行重写。

文件重写

（1）为什么重写？
举一个例子：先后执行了set k1 v1 set k2 v2 set k3 v3 此时AOF文件会记录三条命令，这显然不合理，因为前面的set命令都是多余的，下面是一些列举一些重写策略：

（1）重复或无效的命令不写入文件
（2）过期的数据不再写入文件
（3）多条命令合并写入（比如上面的例子set k1 v1  set k2 v2  set k3 v3）

（2）重写的触发条件（AOF文件重写触发条件可分为手动触发和自动触发）

  • 手动触发：客户端执行bgrewriteaof命令。

  • 自动触发：自动触发通过以下两个配置协作生效：

    （1）AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,这里默认配置64mb
auto-aof-rewrite-min-size 64mb
（2）当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写
auto-aof-rewrite-percentage 100

  • redis在开启AOF的情况下，会维持以下三个变量：

    aof_current_size：记录当前AOF文件大小的变量
aof_rewrite_perc：记录最后一次AOF重写之后，AOF文件大小的变量
aof_rewrite_base_size：增长百分比变量

  • 如果下面条件全部满足的话，就触发自动的AOF重写操作：

    （1）没有BGSAVE命令（RDB持久化）/AOF持久化在执行；
（2）没有BGREWRITEAOF在进行；
（3）当前AOF文件大小要大于server.aof_rewrite_min_size设置的值；
（4）当前AOF文件大小和最后一次重写后的大小之间的比率等于或者大于指定的增长百分比（auto-aof-rewrite-percentage参数）

    （3）重写的过程（图和解析）
    在这里插入图片描述

数据恢复（相比rdb优先使用AOF进行恢复）

当AOF开启时候，redis数据恢复优先选用AOF进行数据恢复，下面我们关闭redis再重启，看日志文件：
在这里插入图片描述

AOF配置参数
#AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写
auto-aof-rewrite-min-size 64mb
#当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写
auto-aof-rewrite-percentage  100

#表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。这种情况下由于每次写命令都写到了文件中, 虽然数据比较安全，但是因为每次写操作都会同步到AOF文件中，所以在性能上会有影响，同时由于频繁的IO操作，硬盘的使用寿命会降低（速度慢）
appendfsync always 
#使用fsync每秒一次从内核刷新到磁盘，这种方式兼顾了性能和数据安全，所以redis默认推荐使用该配置。
appendfsync everysec 
#不同步，这时操作系统自己同步，在linux操作系统中大约每30秒刷一次缓冲。这种情况下，缓冲区数据同步不可控，并且在大量的写操作下，aof_buf缓冲区会堆积会越来越严重，一旦redis出现故障，数据丢失严重
appendfsync no 

#当redis突然运行崩溃时，会出现aof文件被截断的情况，Redis可以在发生这种情况时退出并加载错误，以下选项控制此行为
#如果aof-load-truncated设置为yes，则加载截断的AOF文件，Redis服务器启动发出日志以通知用户该事件
#如果该选项设置为no，则服务将中止并显示错误并停止启动。当该选项设置为no时，用户需要在重启之前使用“redis-check-aof”实用程序修复AOF文件在进行启动
aof-load-truncated yes

#yes开启AOF，no关闭AOF
appendonly no 

#指定AOF文件名
appendfilename appendonly.aof

#RDB文件和AOF文件存放目录
dir  /usr/local/bin

RDB-AOF混合持久化

前面已经详细介绍了AOF持久化以及RDB持久化，这里介绍的混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据，缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性差。

开启混合持久化

通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是开启的，可通过config set修改

混合持久化过程

混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。（新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据）
在这里插入图片描述

数据恢复

当我们开启了混合持久化时，启动redis依然优先加载aof文件，aof文件加载可能有两种情况如下：
（1）aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof
（2）aof文件开头不是rdb的格式，直接以aof格式加载整个文件

优缺点

RDB：

优点：
（1）RDB 是一个非常紧凑（compact）的文件，体积小，因此在传输速度上比较快，因此适合灾难恢复
（2）RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作
（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

缺点：
（1）RDB是一个快照过程，无法完整的保存所以数据，尤其在数据量比较大时候，一旦出现故障丢失的数据将更多
（2）当redis中数据集比较大时候，RDB由于RDB方式需要对数据进行完成拷贝并生成快照文件，fork的子进程会耗CPU，并且数据越大，RDB快照生成会越耗时
（3）RDB文件是特定的格式，阅读性差，由于格式固定，可能存在不兼容情况

AOF：

优点：
（1）数据更完整，秒级数据丢失(取决于设置fsync策略)
（2）兼容性较高，由于是基于redis通讯协议而形成的命令追加方式，无论何种版本的redis都兼容，再者aof文件是明文的，可阅读性较好
缺点：
（1）数据文件体积较大,即使有重写机制，但是在相同的数据集情况下，AOF文件通常比RDB文件大
（2）相对RDB方式，AOF速度慢于RDB，并且在数据量大时候，恢复速度AOF速度也是慢于RDB
（3）由于频繁地将命令同步到文件中，AOF持久化对性能的影响相对RDB较大，但是对于我们来说是可以接受的

混合持久化：

优点：
（1）混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。
缺点：
（1）兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差
Jaksioncc
关注
专栏目录
Redis持久化的两种方式
BodyCoding
07-11 525
前言 Redis是一种K-V数据库，它的数据也可以进行持久化操作。因为redis的数据都保存在内存中，如果不进行及时的持久化，可能就会因为重启导致数据的丢失。这时候就需要对redis进行持久化操作，将数据保存在磁盘上。 redis提供了两种持久化方式，分别是AOF和RDB。下面分别对这里持久化方式进行解析。 1.RDB RDB是将redis 的数据生成快照保存在磁盘上。 工作流程如下： 执行bg...
一文深度揭开Redis的磁盘持久化机制
m0_74931226的博客
12-24 891
Redis 是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将 Redis 中的数据以数据或命令的形式从内存保存到本地磁盘。当下次 Redis 重启时，利用持久化文件进行数据恢复。Redis 提供了 RDB 和 AOF 两种持久化机制，前者将当前的数据保存到磁盘，后者则是将每次执行的写命令保存到磁盘（类似于 MySQL 的 Binlog）。本文将详细介绍 RDB 和 AOF 两种持久化方案，包括操作方法和持久化的实现原理。
Redis 学习笔记（七）-- Redis 持久化
weixin_43989102的博客
05-18 626
Redis 持久化 Redis 是内存数据库，如果不能将内存中的数据库状态保存到磁盘，那么一旦服务进程退出，服务器中的数据库状态也会消失，所以 Redis 提供了持久化功能！ Redis 的持久化机制有哪几种？ RDB、AOF、混合持久化（redis4.0引入） RDB，简而言之，就是在不同的时间点，将 redis 存储的数据生成快照并存储到磁盘等介质上； AOF，则是换了一个角度来实现持久化，那就是将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复
redis持久化方案(持久到磁盘上)
weixin_45067832的博客
02-23 365
第一种持久化方案：bgsave 比如说先存储一个name为zhangsan的数据 客户端查看： 假设意外宕机了： 此时查看数据库已经不在了： 所以引入了bgsave： 再次宕机测试，发现数据此时任然存在： 优点:命令简单，方便操作 缺点：需要频繁使用这个命令 第二种方案持久化方案：rdb 查询配置可以发现： dir ./说明在本地 打开之后 看不懂，继续找配置文件，可以发现： 这个就是rdb持久化方案的配置文件： save 900 1：900秒之内只有有一个key的值发生变化把数据持久化
redis配置持久化到磁盘
xp_lx12的博客
11-13 5228
一、Redis 持久化介绍 Redis 是一种内存数据库，将数据保存在内存中，读写效率要比传统的将数据保存在磁盘上的数据库要快很多。但是一旦进程退出，Redis 的数据就会丢失。 为了解决这个问题，Redis 提供了 RDB 和 AOF 两种持久化方案，将内存中的数据保存到磁盘中，避免数据丢失。Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)...
y-redis:Yjs的Redis持久层
04-29
【y-redis: Yjs的Redis持久层】 在IT行业中，数据持久化是任何应用程序的重要组成部分，特别是对于协作编辑和分布式系统来说。`y-redis`是一个专为Yjs设计的Redis持久层，它允许Yjs的状态在服务器崩溃或网络断开时...
Redis学习笔记—Redis持久化机制
01-07
1. Redis使用的持久化机制(存储数据的方式) (1)RDB 1） RDB：是redis的默认持久化机制。 RDB相当于照快照，保存的是一种状态。如果你有几十G数据 ，它能把它压缩为 几KB的快照 2）快照是默认的持久化方式，这种方式...
Redis：持久化
m0_46669446的博客
01-23 1050
redis：持久化 redis：主从复制 redis：哨兵 redis：集群 1 概述 持久化的功能：Redis是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘；当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。 Redis持久化分为RDB持久化和AOF持久化：前者将当前数据保存到硬盘，后者则是将每次执行的写命令保存到硬盘（类似于MySQL的binlo
redis数据的两种持久化方式对比
01-19
•redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。 •...
【redis】– redis的持久化（作为数据库）
01-07
在说redis持久化的时候，我们先来聊聊其他的知识。linux的父子进程。在Linux中使用fork()函数会给当前正在运行的进程创建一个子进程。那么现在问题就来了，fork时父子进程中的数据有什么关系呢？一般说到进程我们...
redis 数据写入磁盘
Lucky____Boy的博客
05-31 3885
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。 Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把...
Redis总结（四）Redis 的持久化
weixin_30892763的博客
12-04 573
前面已经总结了Redis 的安装和使用，大家可以这这里查看Redis 系列文章：https://www.cnblogs.com/zhangweizhong/category/771056.html 今天讲下Redis 的持久化。 redis跟memcached类似，都是内存数据库，不过redis支持数据持久化，也就是说redis可以将内存中的数据同步到磁盘来持久化，以确保redis 的数...
redis设置保存硬盘
最新发布
weixin_41518898的博客
08-19 62
如何配置 Redis 将数据保存到硬盘 Redis 是一个高性能的键值存储，它在内存中管理数据，同时也提供了将数据持久化到硬盘的功能，以防止数据丢失。本文将介绍如何配置 Redis 将数据保存到硬盘，以及具体的操作步骤。 流程概述 下面是 Redis 数据持久化到硬盘的基本流程： 步骤 描述 1 安装 Red...
Redis数据存储
天然玩家的博客
05-07 1903
1 数据存储 2 数据备份 数据持久化到磁盘：rdb和aof两种方式，默认rdb方式。 2.1 快照持久化 rdb文件位置：/var/lib/redis，文件为dump.rdb，使用vim打开，内容如下： REDIS0008ú redis-ver^E4.0.9ú redis-bitsÀ@ú^EctimeÂ<98>±ª^ú^Hused-memÂ^@^Q^L^@ú^Laof-pr...
redis 同步到磁盘
weixin_40872404的博客
07-06 33
如何实现Redis同步到磁盘 整体流程 首先，让我们来看一下整个过程的步骤： 步骤 操作 1 将Redis中的数据同步到磁盘 2 配置Redis持久化选项 3 重启Redis服务器 具体步骤及代码 步骤1：将Redis中的数据同步到磁盘 首先，我们需要将Redis中的数据同步到磁盘。为此，我们可...
redis的持久化
qq_51921514的博客
04-01 480
1.redis 在运行时，所有的数据都保存在内存里，进程结束以后，会将数据写入到硬盘中。启动时，会读取硬盘里的内容，并将内容全部加载到内存中（会大量占用内存）2.redis 的持久化有两种形式RDB和AOF 默认为RDB ：直接镜像内存里的数据，把内存里的数据保存到dump.rdb文件里，默认在 . / (当前目录下) 配置Redis的持久化机制-AOF（append only file）,将修改的每一条指令记录进app
Redis是如何持久化到硬盘的
wujialv的博客
03-30 1045
Redis为什么需要持久化 我们在项目中或多或少会用到Redis，Redis主要用作缓存数据库。使用Redis可以大大提升我们程序是性能，使用Redis之所以快的原因之一是Redis的数据是存储在内存中，应用程序访问Redis只需要从内存中读取即可。 从内存中读取数据确实能提高访问速度，但是当Redis挂了，内存中的数据就会丢失掉，为了防止数据丢失，我们需要将数据持久化到硬盘中。当Redis挂了，数据已经存储到硬盘中了，Redis重启后，硬盘中的数据就会重新加载到内存中。 那么，问题来了。
Redis实战：命令、持久化与主从复制详解
总结，Redis的学习和应用涉及广泛，包括基本命令、服务管理、数据持久化、高可用架构等多个方面，深入理解这些知识点对于有效利用Redis提升系统性能至关重要。在实践中，应结合具体业务需求选择合适的配置和使用策略...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值