Redis持久化: RDB && AOF

最新推荐文章于 2024-10-31 19:34:41 发布
最新推荐文章于 2024-10-31 19:34:41 发布
阅读量409 收藏 20
点赞数 5
分类专栏： 数据库 文章标签： redis 数据持久化
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_40023447/article/details/103629900
版权

文章目录

Redis持久化

持久化 : 将瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库中，能够长久保存）

RDB介绍

  • Redis数据库文件, 全称Redis DataBase

    • 数据持久化方式之一
    • 数据持久化默认方式
    • 按照指定时间间隔, 将内存中的数据集快照写入硬盘

  • RDB文件名(主配置文件默认)

    • dbfilename dump.rdb

RDB优缺点

  • RDB优点

    • RDB是一个非常紧凑的文件, 保存了某个时间段的数据集, 非常适合于数据集的备份
    • 高性能的持久化实现 : 创建一个子进程来执行持久化, 先将数据写入临时文件, 持久化过程结束后, 再用这个临时文件替换上次持久化好的文件; 过程中主进程不做任何IO操作
    • 比较适合大规模数据恢复, 且对数据完整性要求不是非常高的场合

  • RDB的缺点

    • 意外宕机时, 丢失最后一次持久化的所有数据
    • RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高(CPU消耗)

RDB工作过程

  • 当用户执行bgsave命令, 保存数据时
  • Redis父进程判断当前是否存在正在执行的子进程, 如RDB/AOF子进程, 若存在则bgsave命令直接返回
  • 若不存在, 则父进程调用forks, 生成子进程 fork操作中父进程会阻塞(通过info stats命令 查看 latest_fork_usec选项, 可以获取最近一个fork操作的耗时, 单位为微秒)
  • 父进程fork完后, 界面显示Background saving started 信息不再阻塞父进程, 父进程可继续响应其他命令
  • 子进程将瞬时数据集写入到一个临时RDB文件中
  • 当子进程完成对新RDB文件的写入时, Redis用新RDB文件替换原来的RDB文件, 并删除旧RDB文件
  • 进程发送信号给父进程表示完成, 父进程更新统计信息(详细信息见info Persistence)

优化设置

  • 数据从内存保存到硬盘的频率
[root@redisClient ~]# head -n 221 /etc/redis/6379.conf | tail -3
save 900 1				# 15分钟且有1个key改变即存盘
save 300 10 			# 5分钟且有10个key改变即存盘
save 60 10000 			# 1 分钟且有10000个key改变即存盘
  • 手动存盘
[root@redisClient ~]# redis-cli
127.0.0.1:6379> save 			# 阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
OK
127.0.0.1:6379> bgsave 		# Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
Background saving started 		#父进程fork完成后,返回Background saving started , 信息不再阻塞父进程
127.0.0.1:6379> INFO stats 		# 查看状态信息
... ...
latest_fork_usec:975 		# 上次fork时间为975微秒
... ...
127.0.0.1:6379> info Persistence
... ...
rdb_last_save_time:1576754896 		# 上次生成RDB时间
... ....

使用RDB文件恢复数据

  • 备份数据
    • 备份dump.rdb文件到其他位置
# 在主配置文件中查看数据库目录
[root@redisClient ~]# vim /etc/redis/6379.conf
... ...
dbfilename dump.rdb 		# 定义的RDB文件名
... ...
dir /var/lib/redis/6379 	# RDB文件存储的目录
... ...

# 拷贝dump.rdb到其他位置
[root@redisClient ~]# cp /var/lib/redis/6379/dump.rdb .
  • 恢复数据
    • 拷贝备份文件到数据库目录, 启动redis服务
# 将刚刚备份的数据拷贝给另一台搭有redis的主机(此处选择MGM主机)
[root@redisClient ~]# scp dump.rdb 192.168.4.57:

# 确认MGM的redis服务可用

# 停止服务
[root@MGM ~]# /etc/init.d/redis_6379 stop
# 将dump.rdb文件拷贝到MGM的/var/lib/redis/6379/
[root@MGM ~]# cp dump.rdb /var/lib/redis/6379/
# 启动服务
[root@MGM ~]# /etc/init.d/redis_6379 start
[root@MGM ~]# redis-cli 
127.0.0.1:6379> keys *
1) "site"
2) "list"

AOF介绍

  • Append Only File
    • 追加方式记录写操作的文件
    • 记录redis服务所有写操作(set,del,add等)
    • 不断的将新的写操作, 追加到文件末尾
    • 默认没有启用
    • 使用cat命令可以查看文件内容

AOF优缺点

  • AOF优点
    • 可以灵活设置持久化方式
    • 出现意外宕机时, 仅可能丢失1秒的数据
  • AOF缺点
    • 持久化文件的体积通常会大于RDB方式
    • 执行fsync策略时的速度可能会比RDB方式慢

AOF工作过程

  • AOF持久化功能实现分为命令追加(append), 文件写入和文件同步sync,文件重写三个步骤
  • 服务器在执行完一个写命令之后, 会以协议格式被执行的写命令追求服务器状态的aof_buf缓冲区的末尾
  • redis每次追加完内容到aof_buf缓冲后会调用flushAppendOnlyFile同步函数进行将数据同步到磁盘里
  • flushAppendOnlyFile函数的行为由服务器的appendfsync选项决定

文件的写入和同步

为了提高文件的写入效率, 在现代操作系统中, 当用户调用write函数, 将一些数据写入到文件的时候, 操作系统通常会将写入数据暂时保存在一个内存缓冲区里面
等到缓冲区的空间被填满、或者超过了指定的时限之后,才真正地将缓冲区中的数据的数据写入到磁盘里面

这样做将会导致如果计算机发生宕机, 那么保存在内存缓冲区里面的写入数据将会丢失

为此, 系统提供了fsync和fdataync两个同步函数, 他们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面, 从而确保写入数据的安全性

AOF文件重写

  • 当Redis服务器执行的写命令越来越多, AOF文件也会越来越大 过大的AOF文件会影响服务器的正常运行同时也会导致数据恢复需要的时间过长
  • 因此需要文件重写, AOF重写是把redis进程内的数据转化为写命令, 同步到新的AOF文件, 不会对旧的AOF文件进行任何读取或写入操作
  • 文件重写流程 :
    • Redis父进程首先判断当前是否存在正在执行 bgsave/bgrewriteaof的子进程，如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。
    • 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的
    • 父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确
    • 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区(图中的aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区
    • 子进程根据内存快照，按照命令合并规则写入到新的AOF文件
    • 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看
    • 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致
    • 使用新的AOF文件替换老文件，完成AOF重写

优化配置

  • 定义文件名
[root@MGM ~]# vim +674 /etc/redis/6379.conf
... ...
appendonly yes 				# 启用aof, 默认no
appendfilename "appendonly.aof" 		# 指定文件名
... ...
  • AOF文件记录写操作的方式
appendfsync always 			# 实时记录, 并完成磁盘同步(将aof_buf缓冲区中的所有内容写入并同步到AOF文件中)
appendfsync everysec 		# 每秒记录一次, 并完成磁盘同步(将aof_buf缓冲去中所有内容写入到AOF文件中, 每间隔一秒, 则再次对AOF文件进行同步, 且同步过程由一个线程专门负责执行的)
appendfsync no 				# 写入aof, 不执行磁盘同步(将aof_buf缓冲区中的所有内容写入到AOF文件, 但并不对AOF文件进行同步)
  • 日志文件会不断增大, 何时触发日志重写?
# 手动触发 
[root@MGM ~]# redis-cli 
127.0.0.1:6379> BGREWRITEAOF 		# 该命令同bgsave类似 都是fork子进程进行具体的工作，且都只有在fork时阻塞
Background append only file rewriting started

# 自动触发, 根据主配置文件中 auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数
auto-aof-rewrite-min-size 64mb 		# 执行AOF重写时，文件的最小体积，默认值为64MB
auto-aof-rewrite-percentage 100 		# 执行AOF重写时，当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值
  • 修复AOF文件
    • 把文件恢复到最后一次的正确操作
# 比如AOF文件受损
[root@MGM ~]# echo 1 >> /var/lib/redis/6379/appendonly.aof
[root@MGM ~]# redis-check-aof --fix /var/lib/redis/6379/appendonly.aof  # 恢复AOF文件
0x             13e: Expected prefix '*', got: '1'
AOF analyzed: size=320, ok_up_to=318, diff=2
This will shrink the AOF from 320 bytes, with 2 bytes, to 318 bytes
Continue? [y/N]: y
Successfully truncated AOF

使用AOF文件恢复数据

  • 启用AOF
[root@redisClient ~]# redis-cli  				# 不停服务启用AOF
127.0.0.1:6379> config set appendonly yes 	# 临时启用
OK
127.0.0.1:6379> config rewrite 				# 写入配置文件, 永久配置
OK
  • 备份数据
    • 备份appendonly.aof文件到其他位置
[root@redisClient ~]# redis-cli 
127.0.0.1:6379> mset a 0 b 1 c 2 d 3 		# 存储数据, redis实时生成aof文件
OK
127.0.0.1:6379> exit
[root@redisClient ~]# ls /var/lib/redis/6379/appendonly.aof 
/var/lib/redis/6379/appendonly.aof
  • 恢复数据
    • 拷贝备份文件到数据库目录
    • 启动redis服务
# 开启另一台主机的aof功能
[root@MGM ~]# redis-cli
127.0.0.1:6379> CONFIG set appendonly yes
OK
127.0.0.1:6379> CONFIG REWRITE
OK
# 停止MGM的redis服务, 避免拷贝后重启服务 覆盖掉拷贝过来的文件
[root@MGM ~]# /etc/init.d/redis_6379 stop

# 将数据拷贝给另一台搭有redis服务的主机
[root@redisClient ~]# scp /var/lib/redis/6379/appendonly.aof 192.168.4.57:/var/lib/redis/6379/appendonly.aof

# MGM启动服务
[root@MGM ~]# /etc/init.d/redis_6379 start
# 查看
[root@MGM ~]# redis-cli  
127.0.0.1:6379> keys *  		# 成功恢复数据
1) "b"
2) "site"
3) "a"
4) "c"
5) "d"
6) "list"
Touchl
关注
专栏目录
Redis 持久化之RDB和AOF.doc
10-09
Redis 持久化是确保数据安全的重要机制，它提供了两种主要的方法：RDB（Redis Database）和 AOF（Append Only File）。RDB 是一种快照式的持久化方式，而 AOF 则记录每次写操作的日志。 RDB 持久化在特定条件下将...
Redis AOF之执行flushdb或flushall之后的后悔药
小楼一夜听春雨，深巷明朝卖杏花
07-18 1904
FLUSHALL ASYNC(Redis 4.0.0 or greater) Redis is now able to delete keys in the background in a different thread without blocking the server. AnASYNCoption was added toFLUSHALLandFLUSHDBin order to let the entire dataset or a single database to be f...
Redis持久化存储(AOF与RDB两种模式)
热门推荐
不能说的秘密的博客
10-21 4万+
cache-only即只做为“缓存”服务，不持久数据，数据在服务终止后将消失，此模式下也将不存在“数据恢复”的手段，是一种安全性低/效率高/容易扩展的方式； persistence即为内存中的数据持久备份到磁盘文件，在服务重启后可以恢复，此模式下数据相对安全。
Redis持久化RDB和AOF区别详解
12-14
为了确保数据在服务器重启或异常情况下的安全，Redis提供了两种主要的持久化机制：RDB（Redis Database Persistence，即快照）和AOF（Append Only File，追加日志）。下面将详细解释这两种持久化方式的区别。 **RDB...
Redis持久化 - RDB和AOF
08-17
“Redis持久化 - RDB和AOF” Redis持久化是指将数据库中的数据保存到永久存储设备中，以避免数据丢失。Redis提供了两种持久化方式：RDB（快照方式）和AOF（写日志方式）。 RDB（Redis Database）是一种快照方式的...
Redis两种持久化方案RDB和AOF详解
09-09
它提供了两种主要的持久化方案：RDB（Redis DataBase）和AOF（Append Only File）。这两种方式各有特点，适用于不同的场景需求。 **RDB持久化**： RDB是Redis的默认持久化策略，它会在特定条件下生成数据的快照并...
Redis持久化一一RDB
01-07
Redis的持久化存储提供两种方式：RDB与AOF。RDB是默认配置。默认是关闭AOF模式的，AOF需要手动开启 RDB（Redis DataBase）:在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时...
Redis-发布/订阅交互模式
sq2048935747@163.com的博客
10-31 234
消息代理”（Message Broker）是一种软件组件，它在不同的应用程序之间传递消息。在Redis的上下文中，消息代理的功能允许Redis作为一个中间人，帮助应用程序之间进行异步通信。具体来说，Redis支持发布/订阅（pub/sub）模式，这是一种消息传递机制，其中一个或多个发布者（publishers）发送消息到一个频道（channel），而订阅者（subscribers）监听这些频道以接收消息。
图解Redis 05 | Zset数据类型的原理及应用场景
大厂小码农的博客
10-29 497
Zset 类型（有序集合）与 Set 类型相比，增加了一个排序属性 score。对于有序集合 Zset，每个元素由两个部分组成：一个是元素的值，另一个是用于排序的分数 score。有序集合继承了Set中成员唯一（元素值不能重复，分数可以重复）的特性，但不同之处在于，有序集合中的元素是按分数进行排序的。
群控系统服务端开发模式-应用开发-业务架构逻辑开发Redis封装
龙哥·三年风水从2011年开始做IT工作，从ps画图到前端开发->后端开发->框架开发->业务架构设计及开发->业务需求整理、开发->技术经理->技术总监
10-28 270
群控系统服务端开发模式-应用开发-业务架构逻辑开发Redis封装
Redis & 主从同步 & 总结
说淑人的所思所想
10-26 1105
主从同步的本质是数据复制机制。 主从同步机制无法避免在主机宕机时丢失数据。 Redis存在“一主多从/级联”两种主从同步架构。
短信登录的实现-redis和session的比较
2301_79748665的博客
10-29 689
我们之前只有一个拦截器，但是拦截的路径不是所有，如果用户一直访问的是不需要拦截的路径，那么他的token就不会刷新，就会失去登录状态，我们可以再加一个拦截器，第一个拦截一切路径，并且刷新有效期，第二个做登录校验；用户信息的key使用一个token来保存，一个是保证key的唯一性，一个是保证数据的安全性，因为token也就是key是要存在浏览器中的；因为session是存储在tomcat服务器中的，我们将来部署集群进行负载均衡，那么我们存储在一台tomcat服务器的数据无法实现共享；
Redis中储存含LocalDateTime属性对象的序列化实现
Charles_Clark的博客
10-29 597
上面代码中配置 RedisTemplate 的序列化机制，以便能够序列化和反序列化包含 LocalDateTime 等 Java 8 时间类型的对象。•作用ObjectMapper 是 Jackson 库的核心类，用来将 Java 对象转换为 JSON 字符串，或者将 JSON 字符串解析为 Java 对象。Jackson 是一个非常流行的 JSON 序列化和反序列化库，ObjectMapper 是它的主要接口，用于处理复杂的对象和数据结构。•作用。
redis详细教程（5.AOP和RDB持久化）
2301_81490350的博客
10-30 385
AOF（Append Only File）日志和RDB（Redis Database Backup）持久化是Redis中两种重要的数据持久化机制。 RDB持久化机制原理RDB是Redis提供的一种数据快照保存机制，它将某个时间点的数据库状态保存到一个RDB文件中。这个文件非常适合用于灾难恢复，因为它是自包含的，并且可以被复制到任何其他支持RDB格式的Redis服务器上。 RDB RDB的触发方式有两种： 自动触发：Redis可以在配置文件中设置自动保存点，例如save 60 1000，意味着如果60
Redis常见面试题总结(下)
最新发布
y050505的博客
10-31 341
需要注意的是，即使启用了持久化机制，也不能完全保证 Redis 事务的持久性。因为持久化机制是在事务执行之后进行的，如果事务执行成功但持久化过程中发生故障（比如磁盘故障、写入错误等），那么事务中的数据修改仍然可能会丢失。然而，需要注意的是，由于Redis是单线程执行的，所以乐观锁机制在Redis中的效果可能不如在传统关系型数据库中那么显著。Redis事务是一种将多个命令打包在一起执行的功能，它可以确保这些命令按照顺序执行，并且具有一定的特性。Redis 的事务和我们平时理解的关系型数据库的事务不同。
Redis & 淘汰策略 & 问题
说淑人的所思所想
10-26 577
最近/长期使用频率的模拟：Redis并不会对数据的最近/长期使用频率进行精确计算，而是会使用最近访问时间/概率访问总数来进行模拟。局部比较代替全量比较：为了最大程度的提升性能/降低开销，Redis不会去比较全量数据的最近/长期使用频率，而只会随机抽取{maxmemory-samples}配置项数量的数据来进行局部比较，并将最近/长期使用频率最小的数据淘汰。Redis对LRU/LFU类型的淘汰策略采用的是近似实现，因此统计/对比所有目标数据的最近/完全使用次数/频率是非常耗费性能的行为…
Redis特性和应用场景以及安装
chaodddddd的博客
10-31 559
介绍Redis特性和应用场景以及安装
Redis 初学者指南
特立独行的博客
10-31 672
Redis是一个开源的、基于内存的、支持持久化的日志型Key-Value数据库。
Redis技术入门与实践指南
m0_59344541的博客
10-27 900
【代码】Redis技术入门与实践指南。
Redis持久化：RDB与AOF详解及恢复
"Redis的两种持久化机制是RDB（Redis DataBase）和AOF（Append Only File）。RDB是默认的持久化方案，通过在指定时间间隔内保存内存中的数据快照到磁盘上的dump.rdb文件。AOF则记录每一次写操作，形成日志文件，用于...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值