【Redis高手修炼之路】Redis的持久化——ROB和AOF持久化机制
- 💂 个人主页: 陶然同学
- 🤟 版权: 本文由【陶然同学】原创、在CSDN首发、需要转载请联系博主
- 💬 如果文章对你有帮助、欢迎关注、点赞、收藏(一键三连)和订阅专栏哦
- 💅 想寻找共同成长的小伙伴，请点击【Java全栈开发社区】
目录
1.Redis的持久化
问：把客户端和服务端都关闭了，再重新开启服务器和客户端，数据会不会丢失？
答：数据会部分或全部丢失
1.1Redis持久化概述
什么是Redis的持久化：
因为Redis中的数据都是写在内存中的，如果将内存中的数据写到硬盘的文件上，称为持久化。
Redis持久化的两种方式：
RDB格式：Redis DataBase，每过一段时间将内存中的数据写到硬盘上
AOF格式：Append Only File，以日志的方式记录服务器上的每个操作，当服务器重启的时候，将
日志中操作还原到内存中。
2.RDB持久化机制
2.1RDB持久化机制优点
1.方便备份与恢复
整个Redis数据库将只包含一个文件，默认是dump.rdb，这对于文件备份和恢复而言是非常完美
的。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。一旦系统出现灾
难性故障，我们可以非常容易的进行恢复。
2.性能最大化
对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是分叉出子进程，由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
3.启动效率更高
相比于AOF机制，如果数据集很大，RDB的启动效率会更高
2.2RDB持久化机制缺点
1.不能完全避免数据丢失
因为RDB是每隔一段时间写入数据，所以系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2.会导致服务器暂停的现象
由于RDB是通过子进程来协助完成数据持久化工作的，因此当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。一般在夜深人静的时候持久化会比较好。
2.3RDB持计划机制的配置
在redis.windows.conf配置文件中的SNAPSHOTTING快照中有如下说明：
| 语法 |
说明 |
| save <时间间隔> <修改键数> |
在指定的时间间隔内，修改了多少个键，则进行持久化的操作 |
如下面配置的是RDB方式数据持久化时机，必须两个条件都要满足
| 关键字 |
时间(秒) |
修改键数 |
解释 |
| save |
900 |
1 |
在15分钟内如果修改了1个键，则进行持久化操作 |
| save |
300 |
10 |
在5分钟内如果修改了10个键，则进行持久化操作 |
| save |
60 |
10000 |
在1分钟内如果修改了1万个键，则进行持久化操作 |
2.4演示：RDB持久化
操作步骤
修改redis.windows.conf 文件的101行
添加1行：save 20 3 (表示20秒内修改3个键，则写入到dump.rdb文件中)
使用指定的配置文件启动服务器：redis-server redis.windows.conf
向数据库中添加2个键，直接关闭服务器窗口。再开启服务器，查看所有的keys，刚才添加的数据
丢失。
在客户端添加3个键，发现服务器端有如下输出信息，表示写入到数据库dump.rdb文件中
直接关闭服务器窗口，再开启服务器，查看所有的keys，数据没有丢失。
3.AOF持久化机制
3.1AOF持久化机制优点
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。也可以通过该文件完成数据的重建。该机制可以带来更高的数据安全性，所有的持久化操作都是异步完成的。
| Redis中提供了3种同步策略 |
|
| 每秒同步 |
每过1秒记录一次操作，持久化一次 |
| 每修改同步 |
每次修改键和值，记录一次操作，持久化一次 |
| 不同步 |
不进行持久化的操作，默认值 |
3.2AOF持久化机制缺点
- 文件比RDB更大：对于相同数量的数据集而言，AOF文件通常要大于RDB文件。
- 运行效率比RDB更慢：根据同步策略的不同，AOF在运行效率上往往会慢于RDB。
3.3AOF持久化机制配置
开启AOF持久化
AOF默认是关闭的，首先需要开启AOF模式。
| 参数配置 |
说明 |
| appendonly no/yes |
yes表示开启持久化，no表示关闭，默认是关闭 如果开启会在硬盘上生成一个文件appendonly.aof |
AOF持久化时机
| 关键字 |
持久化时机 |
解释 |
| appendfsync |
always |
每次修改都持久化，效率最低 |
| appendfsync |
everysec |
每秒持久化一次 |
| appendfsync |
no |
不持久化，效率最高 |
3.4演示：AOF的持久化
操作步骤：
打开AOF的配置，找到APPEND ONLY MODE配置块，392行。设置appendonly yes
通过redis-server redis.windows.conf 启动服务器，在服务器目录下出现appendonly.aof文件。大小是0个字节。
添加3个键和值
打开appendonly.aof文件，查看文件的变化。会发现文件记录了所有操作的过程。
4.AOF重写机制介绍
4.1为什么需要AOF重写
AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以AOF文件的大小随着时间的流
逝一定会越来越大；对于Redis服务器，计算机的存储压力；AOF还原出数据库状态的时间都会增
加；
为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的
AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文
件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。
4.2AOF文件重写的实现原理
AOF重写并不需要对原有AOF文件进行任何的读取，写入，分析等操作，这个功能是通过读取服务
器当前的数据库状态来实现的。
-
# 假设服务器对键list执行了以下命令
-
127.0.0.1:6379> RPUSH list "A" "B"
-
(integer) 2
-
127.0.0.1:6379> RPUSH list "C"
-
(integer) 3
-
127.0.0.1:6379> RPUSH list "D" "E"
-
(integer) 5
-
127.0.0.1:6379> LPOP list
-
"A"
-
127.0.0.1:6379> LPOP list
-
"B"
-
127.0.0.1:6379> RPUSH list "F" "G"
-
(integer) 5
-
127.0.0.1:6379> LRANGE list 0 -1
-
1) "C"
-
2) "D"
-
3) "E"
-
4) "F"
-
5) "G"
-
127.0.0.1:6379>
当前列表键list在数据库中的值就为["C", "D", "E", "F", "G"]。要使用尽量少的命令来记录list键的状
态，最简单的方式不是去读取和分析现有AOF文件的内容，，而是直接读取list键在数据库中的当
前值，然后用一条RPUSH list "C" "D" "E" "F" "G"代替前面的6条命令。
原理：从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录该键值对的多个命令。
4.3AOF重写触发的方式
4.3.1AOF重写概述
aof_rewrite函数可以创建新的AOF文件，但是这个函数会进行大量的写入操作，所以调用这个函数
的线程将被长时间的阻塞，所以Redis将AOF重写程序放到子进程（后台）里执行的。
4.3.2AOF触发方式
手动触发：用户通过调用bgrewriteaof手动触发
自动触发：每次当服务器周期性操作函数执行时，它会检查以下条件是否满足，如果全部满足的话，就触发自动的AOF重写操作：
没有RDB持久化/AOF持久化在执行，没有bgrewriteaof在进行；
当前AOF文件大小要大于redis.conf配置的auto-aof-rewrite-min-size大小；
当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）
-
auto-aof-rewrite-percentage 100
-
auto-aof-rewrite-min-size 64mb
4.4演示：AOF手动重写
关闭服务器，删除生成的aof和rdb文件
执行以下命令
输入命令：bgrewriteaof，则aof被重写
生成旧的文件
服务器上出现提示
4.5演示：AOF后台自动重写
关闭服务器，删除生成的aof和rdb文件
修改配置文件如下：
-
# 大于原来的50%就自动重写
-
auto-aof-rewrite-percentage 50
-
# 自动重写的最小尺寸
-
auto-aof-rewrite-min-size 100b
带配置文件启动服务器
进行如下操作
生成的重写文件
服务器端的输出
文章来源: blog.csdn.net，作者：陶然同学，版权归原作者所有，如需转载，请联系作者。
原文链接：blog.csdn.net/weixin_45481821/article/details/124974650
- 点赞
- 收藏
- 关注作者
评论（0）