如何让 Redis 更持久?本文教你!

dbfilename dump-test.rdb  # 文件名为 dump-test.rdb

save 3600 1  # 在 3600 秒内发生一次更改,便会执行 bgsave

我们通过 redis-cli 进入操作

0465448be6acfffd97ac344b9ce919b2.png

然后我们退出后便可在当前目录下看到刚刚生成的 dump-test.rdb 文件

792e0b5d9d4862d7ac80bb5a9fc2a808.png

说明我们配置是生效的,接着我们直接重启 Redis ,看是否还存在我们刚刚保存的数据

e4ab08ab87c499d8bf607fcdfea47e4c.png

看到我们的数据,就说明 redis 持久化成功了。然后我们把刚刚生成的  dump-test.rdb 文件删除后重启 redis

ca5ee42d2c264484e074657d3a2565b8.png

这可以说明Redis 启动时是靠 .rdb 来恢复文件数据的。那我们上面一直说到的 bgsave,那 bgsave 又是如何执行的呢?

我们在前面有说过两个概念 forkcow,不知道是否还有印象,这两个概念便是关键~!

bgsave 开始的时候会 fork 主进程得到一个新的子进程,而 子进程共享 主进程的内存数据的。子进程会将数据写到磁盘上的一个临时的 .rdb 文件中,当子进程写完临时文件后,会将原来的 .rdb文件替换掉。这个就是 fork 的核心,那什么是 cow 呢?cow 全称 copy-on-write 技术,当主进程执行读操作的时候是访问共享内存的,而主进程执行写操作的时候,则会拷贝一份数据,执行写操作。

具体流程如下:

42263f3c7a9bdfd715281e50819ac458.png

这种持久化方式有什么优点呢?

  • 方便持久化,只有一个 dump.rdb 文件

  • 容灾性好,可以将文件保存到安全的磁盘中

  • 性能最大化,fork 子进程来完成写操作,让主进程继续处理命令,将 IO 最大化,保证 Redis 的高性能

缺点也是有的:

  • 数据安全性低,RDB 是间隔一段时间来持久化 (save) ,如果持久化期间 Redis 发生故障,那么就会造成数据丢失,所以这种方式适用于数据要求不是很严谨的情况下使用

  • 保存时间长,如果数据量很大,保存快照的时间就会很长,会占用磁盘空间

优劣均沾,斟酌使用

点击关注公众号,Java干货****及时送达424121790fa259fc56b2997ce66f66b4.png

二、AOF

AOF 全称 Append Only File (追加文件)。作用便是 Redis 处理的每一个写命令都会记录在 AOF 文件中,可以看做是命令日志文件。

该功能默认是关闭的,我们可以在 redis.conf 文件中查看有关于 AOF 相关的配置项

1、

appendonly yes   # 开启 AOF 日志记录功能,默认是关闭的

2、

appendfilename “appendonly.aof”  # AOF 文件的名称

以上两个配置项便是用来开启 AOF 日志记录,那么还有个额外的配置项也需要了解

3、

appendfsync everysec   # AOF 命令记录的频率

该配置项有三个可选值

| 配置项 | 刷盘时机 | 优点 | 缺点 |

| — | — | — | — |

| Always | 同步刷盘 | 可靠性高,几乎不会丢失数据 | 性能影响较大 |

| everysec | 每秒刷盘 | 性能适中 | 最多丢失1秒的数据 |

| no | 操作系统控制 | 性能最好 | 可靠性较差,可能丢失大量的数据 |

有了解 Mysqlrelay log 日志的同学,就不会对这种模型很陌生。

原理:它是将写命令追加到 AOF 文件的末尾,使用 AOF 持久化需要设置同步选项,从而确保写命令同步到磁盘文件上的时机,这是因为对文件进行写入并不会马上将内存同步到磁盘上,而是先存储到缓存区中,然后由操作系统决定什么时候同步到磁盘。

我们开启 AOF 记录功能查看下:

519ac7eedafe00c64f424c8c44a85d16.png

可以看出我们的每一个操作都已经记录到 AOF 文件中,我们这边通过重启 Redis 也一样能获取到刚刚存储的数据,说明持久化是有生效的~

如果你还在到处找面试题,不如上这个Java面试库面试小程序。

b38ff7d3d2f343dcc75090e148b5480d.png

我们看到上面的 AOF 记录文件是不是觉得很规整?但是在线上环境中越规整反而不好,因为这文件主要是给机器看的,而不是跟我们看的,因此我们最好能够进行压缩。

为了解决AOF文件体积不断增大的问题,用户可以向Redis发送 bgrewriteaof命令,这个命令会通过 通过移除AOF文件中的冗余命令 来重写(rewrite)AOF文件,使AOF文件的体积变得尽可能地小。bgrewriteaof的工作原理和 bgsave 创建快照的工作原理非常相似:Redis会创建一个子进程,然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程,所以快照持久化因为创建子进程而导致的性能问题和内存占用问题,在AOF持久化中也同样存在。

既然存在手动触发压缩,那也存在自动触发压缩,这就得说到配置文件中的两个配置项

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

该配置项的意思为当AOF文件的体积大于64MB,并且AOF文件的体积比上一次重写之后的体积大了至少一倍(100%)的时候,Redis将执行bgrewriteaof命令。

总结下,它的优点如下:

  • 数据安全。AOF 持久化可以配置 appendfsync 属性中的 always,每进行一次写命令操作就会记录到 AOF 文件中一次

  • 一致性。通过 append 模型写文件,即使中途服务器宕机,也可以通过 redis-check-aof 工具来解决数据一致性问题

缺点如下:

  • AOF 文件比 RDB 文件大,而且恢复速度慢

  • 数据集大的时候比 RDB 文件启动效率低

同样是优劣均沾,斟酌使用

三、两者区别

分别介绍了两者,我们回顾一下两者有什么区别?

| 方面 | RDB | AOF |

| — | — | — |

| 持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |

| 数据完整性 | 不完整,两次备份之间会丢失 | 相对完整。取决于刷盘策略 |

| 文件大小 | 会有压缩,文件体积小 | 记录命令,文件体积很大 |

| 宕机恢复速度 | 很快 | 慢 |

| 数据恢复优先级 | 低,因为数据完整性不如AOF | 高,因为数据完整性更高 |

| 系统资源占用 | 高,大量CPU和内存消耗 | 低,主要是磁盘IO资源。且 AOF 重写时会占用大量CPU和内存资源 |

| 使用场景 | 可以容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求较高 |

看完上面后,想必对两种持久化机制都有一定的了解了。两者都有优劣势,那我们该如何选择?这里给出几点意见~

读者福利

秋招我借这份PDF的复习思路,收获美团,小米,京东等Java岗offer

更多笔记分享

秋招我借这份PDF的复习思路,收获美团,小米,京东等Java岗offer

统资源占用 | 高,大量CPU和内存消耗 | 低,主要是磁盘IO资源。且 AOF 重写时会占用大量CPU和内存资源 |

| 使用场景 | 可以容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求较高 |

看完上面后,想必对两种持久化机制都有一定的了解了。两者都有优劣势,那我们该如何选择?这里给出几点意见~

读者福利

[外链图片转存中…(img-0BTtdNCB-1719195981786)]

更多笔记分享

[外链图片转存中…(img-B7L2T3DI-1719195981787)]

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值