持久化

10 分钟阅读 • 1099 字 + 1352 词
七、Redis的持久化（==重要==）
1、概念
redis是属于 内存数据库 ，数据是存放在内存中的，如果 断电之后 ， 数据就会丢失 ，为了防止这个现象， reids会定期的将内存中的数据备份到磁盘中 ，断电重启之后，将数据从磁盘加载到内存中。
2、分类
RDB持久化 ：将当前数据保存到硬盘（原理是 将Reids在内存中的数据库记录定时dump到磁盘上 ）
AOF持久化 ：将 每次执行的写命令保存到硬盘 （原理是 将Reids的操作日志以追加的方式写入文件，类似于MySQL的binlog ）
3、RDB持久化
3.1、概念
默认的 持久化方案。 在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中 。即在 指定目录下生成一个dump.rdb文件 。Redis 重启会通过加载 dump.rdb文件恢复数据 。（/var/lib/redis/6379）
3.2、触发快照的方式
1、执行 shutdown命令，会触发快照
2、 flushall命令，也会触发快照。
3、 手动执行save命令，也可以触发快照 。（bgsave （异步）命令）
4、 在指定的时间间隔内，执行指定次数的写操作。
bash
save 30 2   #该命令的含义是，在30s以内，执行两次写操作，写的次数要有2次以上，并且时间要达到30s，才能触发快照。如果时间达到了30s，但是写次数没有达到2次以上，就不会触发快照；如果写次数达到了2次以上，但是时间没有达到30s，也不会触发快照（时间与写次数要同时达到）xx:yy:40   save  set set xx:y(y+1):01
3.3、RDB优缺点
优点：
1、 适合大规模的数据恢复，与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些 2、 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
1、 对数据的完整性与一致性不高。
2、 备份时占用内存（备份时会独立创建一个fork子进程，将数据写入到一个临时文件，最后再将临时文件替换之前的备份文件）
4、AOF持久化
4.1、概念
AOF方式是将执行过的 写指令 记录下来， 在数据恢复时按照从前到后的顺序再将指令都执行一遍。主流的持久化方案 。
image-20230704161852601
redis
set k1 1
incy k1  #将该命令执行99次。  k1 = 100;

set k1 100
4.2、重写
因为 AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。举个例子， 如果你对一个计数器调用了 100 次 INCR ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。然而在实际上，只使用一条 SET 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。
为了处理这种情况， Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild） 。执行 BGREWRITEAOF命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令 。Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写， 具体信息请查看 配置文件。
redis
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
BGREWRITEAOF手动触发重写。
4.3、AOF优缺点
优点
1、 对数据的完整性与一致性比较高。
缺点
1、 执行写命令，花费时间比较久。
2、 文件追加的形式，可能导致文件体积变大。
5、总结
1、如果对数据的完整性与一致性要求比较高，可以选择aof持久化；如果想让数据恢复快一些，可以使用rdb，默认情况使用的是rdb持久化方式
2、两种持久化的方式是可以一起使用的，可以起到互补的作用。
3、 如果只有aof持久化方式，是可以启动redis服务器的。如果aof是唯一的持久化方式，但是aof文件被损坏了，那么redis服务器是启动不成功的。
4、 如果aof持久化是唯一的方式，那么aof文件损坏之后，服务器不能正常启动，但是可以通过命令修复aof文件。
image-20230704163821497

目录