Redis持久化原理以及配置

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
日志服务 SLS,月写入数据量 50GB 1个月
简介: Redis持久化原理以及配置


一、Redis 持久化

redis 的数据全部在内存中,如果突然宕机,数据就会全部丢失,因此需要持久化来保证 Redis 的

数据不会因为故障而丢失,redis 重启的时候可以重新加载持久化文件来恢复数据

Redis的持久化主要有4种方式:

  1. aof
  2. rdb
  3. aof-rewrite
  4. aof-rdb混用

核心知识点:

rdb与aof区别

aof-rewrite解决aof什么问题

aof-rdb混用解决aof-rewrite什么问题

二、aof

append only file

aof 日志存储的是 Redis 服务器的顺序指令序列,aof 日志只记录对内存修改的指令记录

1、aof的执行流程

1.执行命令

2.会判断是否开启aof,

3.如果开启的话,就将命令写入aof buffer中

4.最后根据策略,将aof buffer中的数据刷入磁盘中

需要了解的内容

刷盘策略是什么?

持久化什么内容?这条命令的协议数据

如何恢复(具体原理)?加载保存的协议数据,解析协议数据成命令,重新执行这些命令

2、redis.conf中配置aof

在redis.conf中由aof的相关配置

是否开启aof

appendonly为是否开启aof,如果如yes,则说明开启aof。默认是关闭的

appendonly no

aof的保存文件的前缀名

保存的aof文件都以这个为前缀

appendfilename "appendonly.aof"

刷入磁盘的策略

everysec:定时器使得每秒都会刷入磁盘(每秒都进行持久化)

always:每执行一个命令都会刷入磁盘(持久化)

no:交由系统刷盘

# appendfsync always
appendfsync everysec
# appendfsync no

3、aof持久化的内容是什么

设置相应的redis.conf(自己取个名字,比如我取了redis_aof.conf),通过这个conf去运行redis-server

dir /home/xuheding/redis-data/default
port 6379
daemonize yes
appendonly yes
appendfsync everysec
save ""

运行

redis-server redis_aof.conf

可以发现当前目录下,多了一些aof文件(appendonly.aof暂时是空的)

然后进行redis-cli,随便输入一个命令

然后可以看到appendonly.aof中的内容了

持久化的内容是这条命令的协议数据

4、aof的缺点

随着时间越长,aof 日志会越来越长,如果 redis 重启,重放整个 aof 日志会非常耗时,导致

redis 长时间无法对外提供服务;

三、aof rewrite

1、原理

aof 持久化策略会持久化所有修改命令;里面的很多命令其实可以合并或者删除;

aof rewrite 在 aof 的基础上,满足一定策略则 fork 进程,根据当前内存状态,转换成一系列

的 redis 命令,序列化成一个新的 aof 日志文件中,序列化完毕后再将操作期间发生的增量 aof 日

志追加到新的 aof 日志文件中国你,追加完毕后替换旧的 aof 日志文件;以此达到对 aof 日志瘦

身的目的;

注意:aof rewrite 开启的前提是开启 aof

由于aof的缺点,aof日志比较长,读取过慢。有些命令其实可以合并或者删除

比如

下面这两条命令完全可以一起删除

lpush list dog
lpop list dog

像下面三条命令,分开执行效率慢,可以合并成一条lpush list p1 p2 p3

lpush list p1
lpush list p2
lpush list p2

在aof中除了网络io,还会有磁盘io,磁盘io会占用主线程,会影响性能,而在aof rewrite中,通过fork另起一个进程的方式,通过子进程,对数据进行磁盘io操作,从而不会影响主进程。在主进程修改时,也不会对该子进程的数据产生影响(写时复制)

子进程复写结束后,通过pipe管道去通知主进程复写完了,主进程之后添加的命令,都时在复写后的aof文件的后面添加的。

2、配置

# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 关闭 混合持久化
aof-use-rdb-preamble no
# 关闭 rdb
save ""

3、策略

这里设置了最小aof-rewrite内存大小,当大于等于64mb的时候就会进行一次复写

而aof-rewrite-percentage 100表示,下一次复写就是原来两倍大小,比如第一次aof文件大小64mb复写,第二次就是128mb,第三次256mb,以此类推

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

4、缺点

aof复写在 aof 基础上实现了瘦身,但是 aof 复写的数据量仍然很大;加载会非常慢

四、rdb

1、原理

基于 aof 或 aof 复写文件大的缺点,rdb 是一种快照持久化;它通过 fork 主进程,在子进程中将

内存当中的数据键值对按照存储方式持久化到 rdb 文件中;rdb 存储的是经过压缩的二进制数

据;

将内存中的数据直接写入磁盘,读取得时候直接读入内存就行了

2、配置

在使用rdb的时候要把aof,和aof-rewrite都关闭

要开启rdb,首先要把save ”“注释掉

# 关闭 aof 同时也关闭了 aof复写
appendonly no
# 关闭 aof复写
auto-aof-rewrite-percentage 0
# 关闭 混合持久化
aof-use-rdb-preamble no
# 开启 rdb 也就是注释 save ""
# save ""
save 3600 1
save 300 100
save 60 10000

3、策略

save 3600 1表示3600秒(1小时)内有1次修改数据

save 300 100 表示300秒内有100次修改数据

save 60 10000 表示60秒内有10000次修改数据

上述save语句中,满足任意一个就fork子进程进行rdb写

4、缺点

若采用 rdb 持久化,一旦 redis 宕机,redis 将丢失一段时间的数据;

RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候,fork 的过程是非常耗

时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且 CPU 性能

不是很好的情况下,这种情况会持续1秒,AOF 也需要 fork,但是你可以调节重写日志文件的频率

来提高数据集的耐久度

五、混合持久化

原理

从上面知道,rdb 文件小且加载快但丢失多,aof 文件大且加载慢但丢失少;混合持久化是吸取

rdb 和 aof 两者优点的一种持久化方案;aof 复写的时候实际持久化的内容是 rdb,等持久化后,

持久化期间修改的数据以 aof 的形式附加到文件的尾部;

混合持久化实际上是在 aof rewrite 基础上进行优化;所以需要先开启 aof rewrite;

复写的流程,是通过rdb的数据方式存储的(直接存储 数据)

也就是持久化文件中,前面部分是rdb数据,后面是aof数据

配置

# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 开启 混合持久化
aof-use-rdb-preamble yes
# 关闭 rdb
save ""
# save 3600 1
# save 300 100
# save 60 10000

六、应用

  1. MySQL 缓存方案中,redis 不开启持久化,redis 只存储热点数据,数据的依据来源于
    MySQL;若某些数据经常访问需要开启持久化,此时可以选择 rdb 持久化方案,也就是允许
    丢失一段时间数据;
  2. 对数据可靠性要求高,在机器性能,内存也安全 (fork 写时复制 最差的情况下 96G)的情况
    下,可以让 redis 同时开启 aof 和 rdb,注意此时不是混合持久化;redis 重启优先从 aof 加
    载数据,理论上 aof 包含更多最新数据;如果只开启一种,那么使用混合持久化;
  3. 在允许丢失的情况下,亦可采用主redis不持久化(96G 90G),从redis进行持久化;
  4. 伪装从库;

七、数据安全策略

问题:拷贝持久化文件是否安全? 是安全的,持久化 文件一旦被创建, 就不会进行任何修改。 当服务器要创建一个新的持久化文件 时, 它先将文件的内容保存在一个临时文件里面, 当临时文件写入完毕时, 程序才使用 rename(2) 原子地用临时文件替换原来的持久化文件。

数据安全要考虑两个问题:

  1. 节点宕机(redis 是内存数据库,宕机数据会丢失)
  2. 磁盘故障
  • 创建一个定期任务(cron job), 每小时将一个 RDB 文件备份到一个文件夹, 并且每天将一个
    RDB 文件备份到另一个文件夹。
  • 确保快照的备份都带有相应的日期和时间信息, 每次执行定期任务脚本时, 使用 find 命令来删除
    过期的快照: 比如说, 你可以保留最近 48 小时内的每小时快照, 还可以保留最近一两个月的每
    日快照。
  • 至少每天一次, 将 RDB 备份到你的数据中心之外, 或者至少是备份到你运行 Redis 服务器的物理
    机器之外。

当既有aof又有rdb文件的时候,会默认读取aof文件(因此aof文件最新)

如果想要读取rdb文件,那么可以将aof文件改名作为备份用

相关文章
|
7月前
|
存储 NoSQL 安全
Redis的两种持久化方式---RDB、AOF
通过本文的介绍,我们详细讲解了Redis的两种主要持久化方式:RDB和AOF。每种方式都有其独特的优缺点和适用场景。在实际应用中,可以根据具体需求选择合适的持久化方式,或者同时启用RDB和AOF,以达到最佳效果。希望本文能帮助您更好地理解和应用Redis的持久化机制,构建高效、可靠的数据存储解决方案。
559 79
|
7月前
|
消息中间件 缓存 NoSQL
Redis原理—5.性能和使用总结
本文详细探讨了Redis的阻塞原因、性能优化、缓存相关问题及数据库与缓存的一致性问题。同时还列举了不同缓存操作方案下的并发情况,帮助读者理解并选择合适的缓存管理策略。最终得出结论,在实际应用中应尽量采用“先更新数据库再删除缓存”的方案,并结合异步重试机制来保证数据的一致性和系统的高性能。
Redis原理—5.性能和使用总结
|
7月前
|
NoSQL 算法 安全
Redis原理—1.Redis数据结构
本文介绍了Redis 的主要数据结构及应用。
Redis原理—1.Redis数据结构
|
7月前
|
缓存 NoSQL Redis
Redis原理—2.单机数据库的实现
本文概述了Redis数据库的核心结构和操作机制。
Redis原理—2.单机数据库的实现
|
6月前
|
NoSQL Redis
Redis的数据持久化策略有哪些 ?
Redis 提供了两种方式,实现数据的持久化到硬盘。 1. RDB 持久化(全量),是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 2. AOF持久化(增量),以日志的形式记录服务器所处理的每一个写、删除操作 RDB和AOF一起使用, 在Redis4.0版本支持混合持久化方式 ( 设置 aof-use-rdb-preamble yes )
|
6月前
|
NoSQL Ubuntu 网络安全
在 Ubuntu 20.04 上安装和配置 Redis
在 Ubuntu 20.04 上安装和配置 Redis 的步骤如下:首先更新系统包,然后通过 `apt` 安装 Redis。安装后,启用并启动 Redis 服务,检查其运行状态。可选配置包括修改绑定 IP、端口等,并确保防火墙设置允许外部访问。最后,使用 `redis-cli` 测试 Redis 功能,如设置和获取键值对。
247 1
|
7月前
|
存储 缓存 NoSQL
Redis原理—4.核心原理摘要
Redis 是一个基于内存的高性能NoSQL数据库,支持分布式集群和持久化。其网络通信模型采用多路复用监听与文件事件机制,通过单线程串行化处理大量并发请求,确保高效运行。本文主要简单介绍了 Redis 的核心特性。
|
7月前
|
缓存 NoSQL Redis
Redis原理—3.复制、哨兵和集群
详细介绍了Redis的复制原理、哨兵原理和集群原理。
|
9月前
|
存储 NoSQL Redis
Redis 持久化揭秘:选择 RDB、AOF 还是混合持久化?
Redis 是一个内存数据库,意味着它主要将数据存储在内存中,从而能够提供极高的性能。然而,作为内存数据库,Redis 默认情况下的数据不会永久保存。为了确保数据在重启或故障后能够恢复,Redis 提供了几种 **持久化机制**。这些机制允许 Redis 将内存中的数据保存到硬盘上,从而实现数据持久化。
505 22
Redis 持久化揭秘:选择 RDB、AOF 还是混合持久化?
|
8月前
|
存储 监控 NoSQL
NoSQL与Redis配置与优化
通过合理配置和优化Redis,可以显著提高其性能和可靠性。选择合适的数据结构、优化内存使用、合理设置持久化策略、使用Pipeline批量执行命令、以及采用分布式集群方案,都是提升Redis性能的重要手段。同时,定期监控和维护Redis实例,及时调整配置,能够确保系统的稳定运行。希望本文对您在Redis的配置与优化方面有所帮助。
154 23