【Redis学习系列】Redis持久化

/ Redis / 没有评论 / 1290浏览

Redis

Redis持久化

redis 作为缓存的优秀数据库，也提供了将缓存中的数据写入到硬盘的手段。有两种：一种是 RDB，另一种则是 AOF。

RDB模式

RDB（Redis Database）简介

在指定的时间间隔内将内存中的数据集快照写入到硬盘中，也就是 snapshot 快照，它恢复时是将快照文件直接读取到内存中。

RDB 机制

Redis 会单独创建（fork）一个子进程来进行持久化，先将数据写入到硬盘中的一个临时文件中，等到持久化过程结束，就用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何与之相关的IO操作，这就确保了 Redis 的极高性能 什么叫 fork？ Redis 会复制一个与当前进程一样的进程。新进程的所有数据（eg:程序计数器）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

RDB 比 AOF 更高效！

RDB的劣势：最后一次的持久化后的数据可能会丢失。

RDB 配置

请查看上一章节，Redis配置详情部分。

==AOF机制默认是关闭的==！如果要开启在redis.conf中配置

appendonly on

重启redis即可生效。

RDB触发机制

  1. 满足save设置的机制，在指定的时间间隔内，执行指定次数的操作；
  2. flushall命令执行时；
  3. shutdown Redis时；
  4. 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令。

以上机制出发后会在redis.conf 配置配置的rdb存放文件夹下创建一个持久化文件；默认为： ./dump.rdb

127.0.0.1:6379> config get dir
1) "dir"
2) "/root/redis"   #可以通过命令行查看rdb文件的保存目录。

RDB优缺点

优点：
  1. 适合大规模的数据备份；
  2. 如果业务对数据完整性和一致性要求不高，RDB是很好的选择；
缺点：

  1. 需要一定的备份时间间隔；如果redis宕机，最后一个未触发的时间间隔数据会丢失。

  2. fork进程会占用一点的内存空间。因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。

所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

其他

AOF模式

AOF 简介

Append only file。以日志的形式记录每个写操作（不记录读操作），只需追加文件但不可以改写文件，Redis启动之初会读取该文件中的命令逐条执行重新弄构建数据。

AOF模式保存的文件和RDB模式在同一个文件夹中，文件名称为：appendonly.aof

AOF 配置

请查看上一章节，Redis配置详情部分。

AOF的触发机制

根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

AOF数据恢复

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。

随意修改appendonly.aof

 vim appendonly.aof 
 # 在结尾随便修改部分字符串

执行appendonly.aof修复

root@AY140210092026Z:~/redis# redis-check-aof --fix /root/redis/appendonly.aof 
0x              76: Expected prefix '*', got: '$'
AOF analyzed: size=134, ok_up_to=118, diff=16
This will shrink the AOF from 134 bytes, with 16 bytes, to 118 bytes
Continue? [y/N]: y
Successfully truncated AOF

==RDB和AOF可以同时存在，且优先加载AOF文件。==

AOF 重写机制

AOF 采用文件追加的方式，文件会越来越大为避免出现此种情况，新增重写机制。当 AOF 文件大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof

原理

​ AOF 文件持续增长而过大时，会 fork 出一条新进程来讲文件重写（先写临时文件最后在改名,默认名字为 appendonly.aof)，遍历新进程的内存中数据，每条记录有一条 set 语句，重写 aof 文件，并没有读取旧的 aof 文件，而是将整个内存中的数据用命令的方式重写了一个新的 aof 文件，这点和快照有点类似。

AOF优缺点

优点：
  1. 每次修改都会同步，文件的完整性更好；
  2. 每秒同步一次；可能会造成1秒的数据丢失；
  3. 设置为不同步效率更高；等同于 rdb模式。
缺点：
  1. 相同数据集的数据而言 aof 文件要远大于 rdb 文件，恢复速度慢于 rdb
  2. aof 运行效率要慢于 rdb, everysec 同步策略效率较好，no 同步策略效率和 rdb 相同

尚未理解透彻

开启了主从复制且开启了持久化 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，即只保留save 900 1这条规则。 如果开启 AOF，好处是在最恶劣情况下也只会丢失不超过30秒数据，启动脚本较简单只加载自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF 重写的最后将重写过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF 重写的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值，例如80%。 如果不开启 AOF ，仅靠主从复制实现高可用性也可以。能省掉一大笔IO也减少了重写时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件以便载入较新的文件。

本文由 huzd 创作，采用 知识共享署名4.0 国际许可协议进行许可本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名最后编辑时间
为: 2021/02/10 22:37

→ ← ↓ ↑