第九章Redis持久化

第九章Redis之持久化之 RDB

文章目录

  • 第九章Redis之持久化之 RDB
    • 9.1总体介绍
    • 9.2RDB(Redis DataBase)
      • 9.2.1RDB是什么
      • 9.2.2备份是如何执行的
      • 9.2.3 Fork
      • 9.2.4RDB 持久化流程
      • 9.2.5 dump.rdb 文件
      • 9.2.6配置位置
      • 9.2.7配置文件中默认的快照配置
      • 9.2.8Save
      • 9.2.9rdb 的备份
      • 9.2.10优势
      • 9.2.11 劣势
      • 9.2.12小总结
    • 9.3AOF(Append Only File)
      • 9.3.1AOF是什么
      • 9.3.2AOF持久化流程
      • 9.3.3AOF默认不开启
      • 9.3.4AOF和RDB同时开启,redis 听谁的?
      • 9.3.5AOF同步频率设置
      • 9.5.6Rewrite 压缩
      • 9.5.7优势
      • 9.5.8劣势
      • 9.5.9小总结
    • 9.4总结

9.1总体介绍

官网介绍:http://www.redis.io

Redis 提供了 2个不同形式的持久化方式。
⚫ RDB(Redis DataBase)
⚫ AOF(Append Of File)

9.2RDB(Redis DataBase)

9.2.1RDB是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的 Snapshot 快
照,它恢复时是将快照文件直接读到内存里

9.2.2备份是如何执行的

Redis 会单独创建(fork)一个子进程来进行持久化,会先将数据写入到 一个临时文件
中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。 整个过程
中,主进程是不进行任何 IO 操作的,这就确保了极高的性能 如果需要进行大规模数
据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB方式要比 AOF方式更加
的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。

9.2.3 Fork

⚫ Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、
程序计数器等) 数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进

⚫ 在 Linux 程序中,fork()会产 生一个和父进程完全相同的子进程,但子进程在此后多
会 exec系统调用,出于效率考虑,Linux中引入了“写时复制技术”
⚫ 一般情况父进程和子进程会共用同一段物理内存,只有进程空间的各段的内容要
发生变化时,才会将父进程的内容复制一份给子进程。

9.2.4RDB 持久化流程

第九章Redis持久化_第1张图片

9.2.5 dump.rdb 文件

在 redis.conf 中配置文件名称,默认为 dump.rdb
第九章Redis持久化_第2张图片
我这是在/etc/redis.conf下面
在这里插入图片描述

第九章Redis持久化_第3张图片

9.2.6配置位置

rdb 文件的保存路径,也可以修改。默认为 Redis 启动时命令行所在的目录下
第九章Redis持久化_第4张图片

9.2.7配置文件中默认的快照配置

第九章Redis持久化_第5张图片

9.2.8Save

格式:save 秒钟 写操作次数
RDB 是整个内存的压缩过的 Snapshot,RDB的数据结构,可以配置复合的快照触发条
件,
默认是 1 分钟内改了 1 万次,或 5 分钟内改了 10 次,或 15 分钟内改了 1 次。
禁用
不设置 save 指令,或者给 save 传入空字符串

9.2.9rdb 的备份

先通过 config get dir 查询 rdb文件的目录
将*.rdb 的文件拷贝到别的地方
rdb 的恢复
◆ 关闭 Redis
◆ 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
◆ 启动 Redis, 备份数据会直接加载

9.2.10优势

⚫ 适合大规模的数据恢复
⚫ 对数据完整性和一致性要求不高更适合使用
⚫ 节省磁盘空间
⚫ 恢复速度快
第九章Redis持久化_第6张图片

9.2.11 劣势

⚫ Fork 的时候,内存中的数据被克隆了一份,大致 2倍的膨胀性需要考虑
⚫ 虽然 Redis 在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消
耗性能。
⚫ 在备份周期在一定间隔时间做一次备份,所以如果 Redis 意外 down 掉的话,
就会丢失最后一次快照后的所有修改。

9.2.12小总结

第九章Redis持久化_第7张图片

9.3AOF(Append Only File)

9.3.1AOF是什么

以日志的形式来记录每个写操作(增量保存),将 Redis 执行过的所有写指令记录下
来(读操作不记录), 只许追加文件但不可以改写文件,redis 启动之初会读取该文件重
新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一
次以完成数据的恢复工作

9.3.2AOF持久化流程

(1)客户端的请求写命令会被 append 追加到 AOF 缓冲区内;
(2)AOF 缓冲区根据 AOF 持久化策略[always,everysec,no]将操作 sync 同步到磁盘的AOF 文件中;
(3)AOF 文件大小超过重写策略或手动重写时,会对 AOF 文件 rewrite 重 写,压缩
AOF 文件容量;
(4)Redis 服务重启时,会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的
第九章Redis持久化_第8张图片

9.3.3AOF默认不开启

可以在 redis.conf 中配置文件名称,默认为 appendonly.aof
AOF 文件的保存路径,同 RDB的路径一致。

9.3.4AOF和RDB同时开启,redis 听谁的?

AOF 和 RDB 同时开启,系统默认取 AOF 的数据(数据不会存在丢失)

9.3.5AOF同步频率设置

appendfsync always
始终同步,每次 Redis 的写入都会立刻记入日志;性能较差但数据完整性比较好
appendfsync everysec
每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
appendfsync no
redis 不主动进行同步,把同步时机交给操作系统。

9.5.6Rewrite 压缩

1 是什么:
AOF 采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制, 当
AOF 文件的大小超过所设定的阈值时,Redis 就会启动 AOF 文件的内容压缩, 只保留
可以恢复数据的最小指令集.可以使用命令 bgrewriteaof
2 重写原理,如何实现重写
AOF 文件持续增长而过大时,会 fork 出一条新进程来将文件重写(也是先写临时文件最
后再 rename),redis4.0 版本后的重写,是指上就是把 rdb 的快照,以二级制的形式附
在新的 aof 头部,作为已有的历史数据,替换掉原来的流水账操作。
no-appendfsync-on-rewrite:
如果 no-appendfsync-on-rewrite=yes ,不写入 aof 文件只写入缓存,用户请求不会阻
塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。(降低数据安全性,提高
性能)
如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷,但是遇到重
写操作,可能会发生阻塞。(数据安全,但是性能降低)
触发机制,何时重写Redis 会记录上次重写时的 AOF 大小,默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定 Redis 要满足一定条件才会进行重写。
auto-aof-rewrite-percentage:设置重写的基准值,文件达到 100%时开始重写(文件
是原来重写后文件的 2 倍时触发)
auto-aof-rewrite-min-size:设置重写的基准值,最小文件 64MB。达到这个值开始重
写。
例如:文件达到 70MB 开始重写,降到 50MB,下次什么时候开始重写?100MB
系统载入时或者上次重写完毕时,Redis 会记录此时 AOF 大小,设为 base_size,
如果 Redis 的 AOF 当前大小>= base_size +base_size*100% (默认)且当前大
小>=64mb(默认)的情况下,Redis 会对 AOF 进行重写。
3、重写流程
(1)bgrewriteaof 触发重写,判断是否当前有 bgsave 或 bgrewriteaof 在运行,如果
有,则等待该命令结束后再继续执行。
(2)主进程 fork 出子进程执行重写操作,保证主进程不会阻塞。
(3)子进程遍历 redis 内存中数据到临时文件,客户端的写请求同时写入 aof_buf 缓
冲区和 aof_rewrite_buf 重写缓冲区保证原 AOF 文件完整以及新 AOF 文件生成期间的
新的数据修改动作不会丢失。
(4)1).子进程写完新的 AOF 文件后,向主进程发信号,父进程更新统计信息。2).主
进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件。
(5)使用新的 AOF 文件覆盖旧的 AOF 文件,完成 AOF 重写。
第九章Redis持久化_第9张图片

9.5.7优势

第九章Redis持久化_第10张图片

9.5.8劣势

第九章Redis持久化_第11张图片

9.5.9小总结

第九章Redis持久化_第12张图片

9.4总结

官方推荐两个都启用。
如果对数据不敏感,可以选单独用 RDB。
不建议单独用 AOF,因为可能会出现 Bug。
如果只是做纯内存缓存,可以都不用。

⚫ RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储
⚫ AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
命令来恢复原始的数据,AOF 命令以 redis 协议追加保存每次写的操作到文件末尾.
⚫ Redis 还能对 AOF 文件进行后台重写,使得 AOF 文件的体积不至于过大
⚫ 只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何
持久化方式.
⚫ 同时开启两种持久化方式
⚫ 在这种情况下,当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据, 因为在
通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整.
⚫ RDB 的数据不实时,同时使用两者时服务器重启也只会找 AOF 文件。那要不要只
使用 AOF 呢?
⚫ 建议不要,因为 RDB 更适合用于备份数据库(AOF在不断变化不好备份), 快速重
启,而且不会有 AOF可能潜在的 bug,留着作为一个万一的手段。
⚫ 性能建议

你可能感兴趣的:(数据库,redis,数据库,linux)