Redis复习笔记--持久化

最新推荐文章于 2024-07-26 23:26:48 发布

早睡早起_f

最新推荐文章于 2024-07-26 23:26:48 发布

阅读量773

点赞数 19

文章标签： redis 笔记数据库

本文链接：https://blog.csdn.net/qq_38364419/article/details/140726513

版权

Redis系列复习笔记–持久化

系列文章目录

第五章 Redis系列复习笔记–持久化
第七章 Redis系列复习笔记–Reids集群

文章目录

Redis系列复习笔记--持久化
系列文章目录

五、持久化

由于Redis是内存型数据库，一旦宕机将导致数据丢失，所以需要持久化到磁盘。Redis通常使用RDB和AOF两种持久化机制。

5.1 RDB持久化（Redis DataBase）

RDB持久化是把当前进程数据生成快照保存到硬盘的过程。是一种按一定时间间隔全量数据持久化的方式，会生成一个紧凑压缩的二进制文件。

5.1.1 触发方式

RDB持久化的触发方式有两种，手动触发和被动触发。

5.1.1.1 手动触发

使用save命令或bgsave命令。前者是阻塞的，在执行RDB持久化结束前，Redis服务是不可用的。后者是非阻塞的，从Reids进程执行fork操作创建一个子进程（fork过程是阻塞的），由子进程执行RDB持久化过程。流程如下：

1、执行bgsave命令，判断是否有子进程正在执行持久化，如果有则直接返回。
2、父进程fork创建子进程，fork过程是阻塞的。
3、父进程fork创建完毕，继续响应其它命令。
4、子进程执行持久化工作，在内存中生成临时快照文件。待快照文件完成后原子替换旧的rdb文件。
5、子进程发送信号，通知父进程RDB持久化完成。

5.1.1.2 被动触发

1、使用save相关配置。

#   save <seconds> <changes>
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed    如果900s内有至少1条key发生变化则执行持久化
#   after 300 sec (5 min) if at least 10 keys changed   如果300s内有至少10条key发生变化则执行持久化
#   after 60 sec if at least 10000 keys changed         如果60s内有至少10000条key发生变化则执行持久化

save 900 1
save 300 10
save 60 10000

2、如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。
3、执行debug reload命令重新加载Redis时，也会自动触发save操作。
4、默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

5.1.2 RDB优缺点

优点：1、压缩后的二进制rdb文件小，适用于备份、全量复制等场景。
2、Redis加载RDB恢复数据远远快于AOF的方式。
缺点：1、RDB方式数据没办法做到实时持久化/秒级持久化。
2、bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

5.2 AOF（Append Only File）

针对RDB不能实时持久化的问题，Redis提供了AOF持久化。以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。

5.2.1 AOF持久化流程

AOF流程相对简单点，如下图所示。

1、所以命令会追加到一个称为aof_buf的缓冲区。（这里注意，依然是先执行后写缓存。）
2、AOF缓冲区根据配置策略对磁盘做写操作。
3、随着AOF文件越来越大，会定期对AOF文件进行重写，以压缩大小。
4、当Redis服务器重启时，可以加载AOF文件进行数据恢复。

5.2.2 AOF文件同步

追加命令到缓冲区依旧是在内存中操作的，但写AOF文件到磁盘就比较吃性能了。好在Redis为我们提供了三种策略来平衡性能和可靠性。如下表：

可配置策略	说明	优点	缺点
always	每个命令都调用fsync写入AOF文件	可靠性高	性能差
everysec	调用write操作，每秒调用fsync写入AOF文件	可靠性较高	性能较好
no	调用write操作，但不调用fsync	可靠性低，持久化周期不可控	性能好

这里说下Linux系统的fsync命令是针对单文件做强制磁盘同步操作。而write命令是先将数据写入系统缓冲区后线程会同步返回，待特定时间或缓冲页写满才同步磁盘。
下面列举一些相关配置：

#是否开启AOF
appendonly no

# The name of the append only file (default: "appendonly.aof")  文件名
appendfilename "appendonly.aof"

#文件保存位置，AOF和RDB都是此配置
dir ./

#三种文件同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

#自动重写触发条件
auto-aof-rewrite-percentage 100      #当前AOF文件大小和上一次重写后AOF文件大小的差值
auto-aof-rewrite-min-size 64mb       #运行AOF重写时文件的最小大小

#每生成32MB数据，fsync同步到文件
aof-rewrite-incremental-fsync yes

5.2.3 AOF文件重写

AOF文件重写其实就是一个文件压缩的过程。比如去除无效指令（同个key多次set只留最后一次），合并指令（队列多次push等效一次push多value）等。
AOF文件重写可以通过bgrewriteaof命令手动触发，也可以根据配置自动触发（见上面5.2.2）。不过AOF文件重写过程会比较复杂，主要是因为子进程重写过程中，父进程依旧在执行命令。如下图所示。

1、执行AOF重写请求。
2、fork创建子进程。
3.1、创建子进程完毕，父进程继续执行其它命令。依然写入AOF缓冲区。
3.2、由于子进程只能共享fork时的内存数据，所以父进程新数据还会写入一份到AOF重写缓冲区。
4、子进程根据内存快照写入到新AOF文件。
5.1、子进程写入完成通知父进程。
5.2、父进程把AOF重写缓冲区更新写入到新AOF文件。
5.3、使用新AOF文件替换旧AOF文件。

5.2.4 重启加载

AOF和RDB文件都可以用于服务器重启时的数据恢复。其持久化文件加载流程如下。

Redis重启会优先加载AOF文件。AOF关闭或AOF文件不存在再加载RDB文件。不过虽然是优先加载AOF文件，但是数据恢复速度其实是RDB比较快。因为RDB文件是全量数据的二进制文件，解析后可以直接加载到内存；而AOF文件是命令追加方式，会以启动伪客户端执行命令的方式恢复数据。

5.2.5 AOF文件校验

加载损坏的AOF文件时会拒绝启动并打印错误日志。可以采用redis-check-aof–fix命令进行修复。

5.2.6 AOF优缺点

优点：1、可靠性高。
2、可读性高，可用于数据操作分析。
缺点：1、文件较大，传输速度较慢。
2、数据恢复速度较慢。

5.3 AOF和RDB混合使用

高版本的Redis提出AOF和RDB混合使用。即在两次RDB持久化间隔中间，使用AOF持久化，直到下一次RDB持久化完成删除AOF文件。可以使用如下配置开启混合使用，兼顾性能和可靠性。

aof-use-rdb-preamble yes

参考文献

1、书籍《Redis开发与运维》
2、redis文档：https://redis.io/docs/latest/develop/
3、redisson文档：https://github.com/redisson/redisson/wiki/Table-of-Content
4、jedis文档：https://redis.io/docs/connect/clients/java/
5、https://pdai.tech/md/db/nosql-redis/db-redis-overview.html
6、https://xiaolincoding.com/redis/base/redis_interview.html#lru-%E7%AE%97%E6%B3%95%E5%92%8C-lfu-%E7%AE%97%E6%B3%95%E6%9C%89%E4%BB%80%E4%B9%88%E5%8C%BA%E5%88%AB
7、其它