Redis持久化
2024-01-08 本文已影响0人
我可能是个假开发
一、RDB
1.概述
RDB全称Redis Database Backup file (Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据快照文件称为RDB文件，默认是保存在当前运行目录。
image.png
Redis停机时会执行一次RDB
Redis内部有触发RDB的机制，可以在redis.conf文件中找到：
image.png
image.png
2.底层原理
bogsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术:
当主进程执行读操作时，访问共享内存:
当主进程执行写操作时，则会拷贝一份数据，执行写操作。
image.png
bogsave的基本流程：
- fork主进程的到子进程，共享内存空间
- 子进程读取内存数据并写入新的RDB文件
- 用新的RDB文件替换旧的RDB文件
RDB执行时机
- RDB默认是在服务停止时执行
- 配置
save 60 1000代表60s内至少执行1000次修改则触发RDB
RDB缺点
- RDB执行间隔时间长，两次RDB之前写入数据有丢失的风险
- fork子进程，压缩，写出RDB文件都比较耗时
二、AOF
1.概述
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF写文件中，可以看做是命令日志文件。
image.png
AOF默认关闭，修改redis.conf开启AOF：
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF记录命令的频率：
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsvnc everysec
#写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
| 配置项 | 刷盘时机 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步刷盘 | 可靠性高，几乎不丢数据 | 性能影响较大 |
| everysec | 每秒刷盘 | 性能适中 | 最多丢失1s数据 |
| no | 操作系统控制 | 性能最好 | 可靠性较差，可能丢失大量数据 |
2.日志过大问题解决
因为是记录命令，AOF文件会比RDB文件大很多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。
通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。
image.png
Redis会在阈值触发时自动去重写AOF文件，在redis.conf中配置：
#AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
三、对比
在实际开发中会结合两者来使用
| RDB | AOF | |
|---|---|---|
| 持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
| 数据完整性 | 不完整，两次备份之间会丢数据 | 相对完整，取决于刷盘策略 |
| 文件大小 | 会有压缩，文件体积小 | 记录命令，文件体积大 |
| 宕机恢复速度 | 快 | 慢 |
| 数据恢复优先级 | 低，因为数据完整性不如AOF | 高，数据完整性高 |
| 系统资源占用 | 高，大量CPU和内存消耗 | 低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源 |
| 使用场景 | 可以容忍数分钟的数据丢失，追求更快的启动速度 | 对数据安全性较高 |
