Redis——Redis 持久化

最新推荐文章于 2024-06-30 15:56:22 发布
最新推荐文章于 2024-06-30 15:56:22 发布
阅读量2.1k 收藏 15
点赞数 9
分类专栏： Redis 文章标签： 大数据 redis 数据库 数据持久化
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Cantevenl/article/details/115824721
版权

Redis 持久化

持久化简介

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会丢失。所以Redis提供了持久化功能！

什么是持久化
利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

为什么要进行持久化
防止数据的意外丢失，确保数据安全性

持久化过程保存什么

  • 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
  • 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程
  • Redis有两种持久化的方式
    • RDB：存储方式为数据（快照）
    • AOF：存储方式为过程（日志）

RDB

什么是RDB

在这里插入图片描述

  • 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是专业讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
  • Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
  • 有时候在生产环境我们会将这个文件备份

RDB启动方式 —— save指令

  • 命令

    save

  • 作用
    手动执行一次保存操作
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set name 123
OK
127.0.0.1:6379> save
OK

在data目录里会生成一个rdb文件
[root@maomao data]# ls
6379.log  6380.log  dump.rdb

我们将rdb删除	在执行一次save
[root@maomao data]# rm -rf dump.rdb 
[root@maomao data]# ls
6379.log  6380.log

127.0.0.1:6379> set user maomao
OK
127.0.0.1:6379> save
OK

又生成了dump.rdb
[root@maomao data]# ls
6379.log  6380.log  dump.rdb

save指令相关配置

  • dbfilename dump.rdb
    说明：设置本地数据库文件名，默认值为 dump.rdb
    经验：通常设置为dump-端口号.rdb
  • dir
    说明：设置存储.rdb文件的路径
    经验：通常设置成存储空间较大的目录中，目录名称data
  • rdbcompression yes
    说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
    经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
  • rdbchecksum yes
    说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
    经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

配置文件

dbfilename dump-6379.rdb	# 将rdb文件名改成端口号

rdbcompression yes		# 开启压缩

rdbchecksum yes			# 开启校验

重启服务写了一个脚本 方便启动
#!/bin/bash
read -p '请输入你想启动的redis端口：' port

/usr/local/bin/redis-server /usr/local/bin/redis_config/redis-$port.conf
/usr/local/bin/redis-cli -p $port

[root@maomao bin]# bash qidong.sh 
请输入你想启动的redis端口：6379
127.0.0.1:6379> 

127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set name zhu
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379> set gender nan
OK


[root@maomao data]# ls		# 有了新改名的rdb文件
6379.log  6380.log  dump-6379.rdb

数据恢复

测试能否恢复数据
127.0.0.1:6379> shutdown
not connected> exit
[root@maomao bin]# ps -ef |grep redis-
root       1667   1507  0 01:15 pts/0    00:00:00 grep --color=auto redis-

[root@maomao bin]# bash qidong.sh 
请输入你想启动的redis端口：6379
127.0.0.1:6379> keys *
1) "gender"
2) "name"
3) "age"

数据存在！

触发机制

  1. save的规则满足的情况下，会自动触发rdb规则
  2. 执行flushall命令，也会触发我们的rdb规则
  3. 退出redis,也会产生 rdb文件

save指令工作原理

在这里插入图片描述

注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用

RDB启动方式 —— bgsave指令

  • 命令

    bgsave

  • 作用
    手动启动后台保存操作，但不是立即执行

127.0.0.1:6379> set addr chengdu
OK
127.0.0.1:6379> bgsave
Background saving started

查看日志
cat 6379.log
1671:M 18 Apr 2021 01:23:58.455 * Background saving started by pid 1678
1671:M 18 Apr 2021 01:23:58.482 * Background saving terminated with success

bgsave指令工作原理

在这里插入图片描述

注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

bgsave指令相关配置

dbfilename dump-6379.rdb	# 将rdb文件名改成端口号

rdbcompression yes		# 开启压缩

rdbchecksum yes			# 开启校验

stop-write-on-bgsave-error yes	# 出现错误现象，是否停止保存
  • stop-write-on-bgsave-error yes
    说明：后台存储过程中如果出现错误现象，是否停止保存操作
    经验：通常默认为开启状态

RDB自动执行

save配置

  • 配置

    save second changes

  • 作用
    满足限定时间范围内key的变化数量达到指定数量即进行持久化

  • 参数

    • second：监控时间范围
      changes：监控key的变化量
# save 3600 1
# save 300 100
# save 60 10000
save 60 5		# 测试只要60s内修改了5次key，就会触发rdb操作

127.0.0.1:6379> set name mao
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> set gender nv
OK
127.0.0.1:6379> set addr chengdu
OK
127.0.0.1:6379> set subject python
OK

[root@maomao data]# ls		# 产生了rdb文件
6379.log  6380.log  dump-6379.rdb

在时间范围内只要设定的数量的key发生变化 系统就去执行bgsave

save配置原理

在这里插入图片描述

  1. 对数据产生影响的指令 get这种不会产生影响
  2. key里面的值要变
  3. 不进行数据比对 如果两次set同一个值 影响数量也会+1

注意：

  • save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
  • save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
  • save配置启动后执行的是bgsave操作

RDB三种启动方式对比

方式save指令bgsave指令
读写同步异步
阻塞客户端指令是否
额外内存消耗否是
启动新进程否是

rdb特殊启动形式

  • 全量复制

    在主从复制中写

  • 服务器运行过程中重启

    debug reload

  • 关闭服务器时指定保存数据

    shutdown save

默认情况下执行shutdown命令时，自动执行
bgsave(如果没有开启AOF持久化功能)

RDB优缺点

RDB优点

  • RDB是一个紧凑压缩的二进制文件，存储效率较高
  • RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
  • RDB恢复数据的速度要比AOF快很多
  • 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

Rdb缺点

  • RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
  • bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
  • Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

AOF

RDB存储的弊端

  • 存储数据量较大，效率较低
    • 基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
  • 大数据量下的IO性能较低
  • 基于fork创建子进程，内存产生额外消耗
  • 宕机带来的数据丢失风险

解决思路

  • 不写全数据，仅记录部分数据
  • 降低区分数据是否改变的难度，改记录数据为记录操作过程
  • 对所有操作均进行记录，排除丢失数据的风险

什么是AOF

  • AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令
    达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
  • AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

在这里插入图片描述
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话 就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF写数据三种策略(appendfsync)

  • always(每次）
    • 每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用
  • everysec（每秒）
    • 每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
    • 在系统突然宕机的情况下丢失1秒内的数据
  • no（系统控制）
    • 由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF功能开启

  • 配置

    appendonly yes|no

  • 作用
    是否开启AOF持久化功能，默认为不开启状态

  • 配置

    appendfsync always|everysec|no

  • 作用
    AOF写数据策略

appendonly yes	# 开启AOF功能
appendfilename "appendonly-6379.aof"		# 文件名字

appendfsync always	# 先测试always

测试always

127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set name zhuer
OK
127.0.0.1:6379> lpush list a b c d e
(integer) 5

出现了aof文件
[root@maomao data]# ls
6379.log  6380.log  appendonly-6379.aof  dump-6379.rdb

查看
[root@maomao data]# cat appendonly-6379.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$5
zhuer
*7
$5
lpush
$4
list
$1
a
$1
b
$1
c
$1
d
$1
e

测试everysec

vim redis-6379.conf 

appendfsync everysec

[root@maomao bin]# bash qidong.sh 
请输入你想启动的redis端口：6379
127.0.0.1:6379> set abc abc
OK

查看aof文件
$3
abc
$3
abc

持久化成功

AOF重写

在这里插入图片描述
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重
写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用

  • 降低磁盘占用量，提高磁盘利用率
  • 提高持久化效率，降低持久化写时间，提高IO性能
  • 降低数据恢复用时，提高数据恢复效率

AOF重写规则

  • 进程内已超时的数据不再写入文件
  • 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令
    • 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
  • 对同一数据的多条写命令合并为一条命令
    • 如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
    • 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式

  • 手动重写

    bgrewriteaof

  • 自动重写

    auto-aof-rewrite-min-size size
    auto-aof-rewrite-percentage percentage

修改配置文件
appendfsync always
appendfilename "appendonly-6379.aof"

删除之前数据
[root@maomao data]# ls
6379.log  6380.log  appendonly-6379.aof  dump-6379.rdb
[root@maomao data]# rm -rf appendonly-6379.aof 
[root@maomao data]# rm -rf dump-6379.rdb

启动redis
127.0.0.1:6379> set name a
OK
127.0.0.1:6379> set name b
OK
127.0.0.1:6379> set name c
OK
127.0.0.1:6379> get name
"c"

127.0.0.1:6379> lpush list a
(integer) 1
127.0.0.1:6379> lpush list b
(integer) 2
127.0.0.1:6379> lpush list c
(integer) 3

查看aof文件
set
$4
name
$1
a
*3
$3
set
$4
name
$1
b
*3
$3
set
$4
name
$1
c
$5
lpush
$4
list
$1
a
*3
$5
lpush
$4
list
$1
b
*3
$5
lpush
$4
list
$1
c
*2
$3
del
$4
name

重写
127.0.0.1:6379> bgrewriteaof

再次查看aof文件
*2
$6
SELECT
$1
0
*3
$3
SET
$4
name
$3
c
RPUSH
$5
list
$1
c
$1
b
$1
a

重写之后 文件大小变小 并且忽略无用指令

在这里插入图片描述

AOF自动重写方式

  • 自动重写触发条件设置
    在这里插入图片描述

  • 自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）
    在这里插入图片描述

  • 自动重写触发条件
    在这里插入图片描述

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

如果aof文件大于64m，太大了！fork一个新的进程来讲我们的文件进行重写

AOF工作流程

在这里插入图片描述
重写
在这里插入图片描述

AOF缓冲区同步文件策略，由参数appendfsync控制

  • 系统调用write和fsync说明：
    • write操作会触发延迟写（delayed write）机制，Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，列如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
    • fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞知道写入硬盘完成后返回，保证了数据持久化。
    • 除了write、fsync、Linx还提供了sync、fdatasync操作

RDB与AOF区别

持久化方式RDBAOF
占用存储空间小（数据级：压缩）大（指令级：重写）
存储速度慢快
恢复速度快慢
数据安全性会丢失数据依据策略决定
资源消耗高/重量级低/轻量级
启动优先级低高

RDB与AOF的选择

  • 对数据非常敏感，建议使用默认的AOF持久化方案
    • AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
    • 注意：由于AOF文件存储体积较大，且恢复速度较慢
  • 数据呈现阶段有效性，建议使用RDB持久化方案
    • 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
    • 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低
  • 综合比对
    • RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
    • 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
    • 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
    • 灾难恢复选用RDB
    • 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量
Redis——Redis持久化原理
庄小焱
03-29 1736
Redis 的读写都是在内存中，所以它的性能较高，但在内存中的数据会随着服务器的重启而丢失，为了保证数据不丢失，我们需要将内存中的数据存储到磁盘，以便 Redis 重启时能够从磁盘中恢复原有的数据，而整个过程就叫做 Redis 持久化。Redis 持久化也是 Redis 和 Memcached 的主要区别之一，因为 Memcached 不具备持久化功能。
redis系列3——持久化
xiaodigua1024的博客
03-09 527
redis持久化分为RDB(快照)和AOF(日志)和混合持久化三种持久化方式
Redis 持久化
10-30 94
Redis 持久化 Redis 提供了不同级别的持久化方式: RDB持久化【保存的是数据】方式能够在指定的时间间隔能对你的数据进行快照存储.【就是镜像备份文件（save 900 10）[dbfilename dump.rdb]】 AOF持久化【保存的是所有执行的命令】方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追...
Redis持久化
ThinkWon的博客
09-27 7764
文章目录RDB 持久化(快照持久化)AOF 持久化重写/压缩AOFRedis 4.0 对持久化机制的优化如何选择合适的持久化方式 Redis 是内存型数据库，为了之后重用数据（比如重启机器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置，需要将内存中的数据持久化到硬盘上。 Redis 提供了RDB和AOF两种持久化方式。默认是只开启RDB，当Redis重启时，它会优先使用...
Redis——redis学习过程
01-07
Redis的持久化 Redis缓存与数据库（mysql同步）->kalafa作为异步队列 Redis知识点总结 缓存穿透、缓存雪崩，热点key 6、Redis高级配置 Redis5集群搭建 JAVA远程客户端RedisCluster实战应用 Spring
Redis——Redis用作数据库（持久化/RDB/AOF）
qq_42583242的博客
10-03 4168
Redis 用作数据库 文章目录Redis 用作数据库一、持久化之RDB1、时点性2、RDB配置3、优缺点RDB的优点RDB的缺点二、持久化之AOF1、AOF配置2、优缺点AOF 优点AOF 缺点 Redis 用作缓存，其特点之一就是数据可以丢，只需要保证其响应急速，性能较高！ 但是如果把 Redis 做数据库：数据绝对不能丢的，所以除了保证其速度之外，还必须保证其持久性，数据一定不可以丢失 而我们知道 Redis 处于内存，内存数据掉电易失！所以如果想要使用 Redis 作为数据库，必须要保证其持久性 只
Redis windows 测试redis持久化功能1
08-08
Redis 是一个高性能的键值数据库，广泛应用于缓存、数据持久化等场景。在 Windows 上测试 Redis 的持久化功能，主要是确保数据在系统重启或异常情况后能够被正确地保存和恢复。以下将详细介绍如何在 Windows 环境下...
redis面试题之持久化.zip
04-18
在实际应用中，为了保证数据的可靠性，Redis 提供了多种持久化机制。本篇将深入探讨 Redis 的持久化策略，帮助你应对相关的面试问题。 1. RDB (Redis Database Persistence) RDB 是 Redis 默认的持久化方式，它会...
Redis——Redis如何保证数据一致性？
最新发布
qq_42631788的博客
06-30 2833
Redis 通过单线程操作、事务支持、持久化机制、复制和高可用、数据结构的原子性操作以及分布式锁等多种机制，保证了数据的一致性和可靠性。这些特性使得 Redis 成为一个广泛应用于高性能、高并发场景下的数据存储解决方案。
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值