Redis-持久化

---

前言

Redis是内存型数据库
当redis服务被Kill掉，重新启动，查看数据，发现数据会被清空

kill -9 20025
redis-server /etc/redis.conf
redis-cli -h 127.0.0.1 -p 6379 -a 12345678

持久化：将内存中数据存储到磁盘
两种模式：RDB和AOF

---

一、RDB

RDB - Redis DataBase
每隔一段时间（配置），将内存中的数据作为快照写入磁盘上的临时文件，恢复时将快照文件读入内存

快照文件RDB文件

优点

• 每隔一段时间备份一次（快照） -> 全备
• 异地备份很简单
• 数据恢复速度快

缺点

• 如果发生故障时，最后数据没有达到写入条件，无法及时备份（导致数据丢失）
• RDB需要fork() 在磁盘上完成持久化，如果频率太高，增加CPU负担

适应场景

• 大规模的数据恢复
• 对数据完整性和一致性要求不高

配置/etc/redis.conf

# dir ./                  
dir /redisdata/
# 保存的文件名
dbfilename dump.rdb
# 配置保存触发条件
# 在3600s内，如果超过1个Key发生了变化就写一次RDB文件
# save 3600 1 300 100 60 10000
save 10 2

手动创建目录

mkdir /redisdata/

测试

• 看是否触发了保存RDB文件：
  set k1
  ll /redisdata -> date

• kill杀死
  会有一些没有保存的数据丢失

• shutdown停服务
  会在停之前进行一次快照

保存备份

[root@db redisdata]# cp dump.rdb dump-202508301515.rdb

模拟数据误删除

127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> keys *
(empty array)

恢复数据

127.0.0.1:6379> shutdown# 恢复备份
[root@db redisdata]#cp dump-202508301515.rdb dump.rdb
# 重启服务
[root@db redisdata]#redis-server /etc/redis.conf 
[root@db redisdata]#redis-cli -a 123456# 查看
127.0.0.1:6379> keys *1) "k6"2) "k5"3) "k3"

手动触发保存RDB文件

127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave (默认-fork一个子进程)
Background saving started

save：同步生成快照，会阻塞主进程（不推荐在生产环境使用）
bgsave：后台异步生成快照，不阻塞主进程（推荐）

查看最后一次SAVE的时间

>127.0.0.1:6379> lastsave
(integer) 1756539119
# date -d @1756539119
2025年 08月 30日 星期六 15:31:59 CST

自动触发

• 根据配置项自动触发
• 当shutdown自动触发
• flushall/flushdb自动触发
• 主从复制，主节点自动触发

传输过程，异常宕机 -> 修复rdb

[root@db redisdata]# redis-check-rdb /redisdata/dump.rdb
[offset 0] Checking RDB file /redisdata/dump.rdb
[offset 26] AUX FIELD redis-ver = ‘8.2.1’
[offset 40] AUX FIELD redis-bits = ‘64’
[offset 52] AUX FIELD ctime = ‘1756539119’
[offset 67] AUX FIELD used-mem = ‘773448’
[offset 79] AUX FIELD aof-base = ‘0’
[offset 81] Selecting DB ID 0
[offset 168] Checksum OK
[offset 168] \o/ RDB looks OK! \o/
[info] 12 keys read
[info] 0 expires
[info] 0 already expired
[info] 0 subexpires

不想启用RDB快照
配置文件 -> save ""

---

二、AOF

Append Only File

用记写操作以日志的形式记录下来
文件被追加而不是修改

默认Redis没有开启AOF => appendonly no

AOF优势

• AOF实时性比较好，当写之后，触发追加 => 缓存层(默认1s) => 磁盘
• 当数据过大，redis会在后台自动 重写AOF文件，节省空间

AOF缺点

• 相同数据集 AOF文件一般大于RDB文件
• AOF有写入策略，整体速度慢于RDB

数据写入过程

AOF支持3种写入策略

• everysec(默认):每秒一次
• always: 每次将新命令附加到AOF，速度慢（磁盘IO大），但最安全
• no: 操作系统控制回写，速度快，安全性差一点

1. 配置启用AOF

[root@db redisdata]# vim /etc/redis.conf
appendonly yes 
appendfsync everysec
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
# 暂时停用RDB
save ""

2. 重启

127.0.0.1:6379> shutdown
not connected> 
[root@db redisdata]# redis-server /etc/redis.conf 
[root@db redisdata]# redis-cli -a 12345678

3. 测试

127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 1
OK
127.0.0.1:6379> set k1 2
OK
127.0.0.1:6379> set k1 3
OK
# 观察AOF文件是否生成且更新 
[root@db appendonlydir]# ll
总用量 12
-rw-r--r-- 1 root root  88 8月  30 16:17 appendonly.aof.1.base.rdb
-rw-r--r-- 1 root root 107 8月  30 16:20 appendonly.aof.1.incr.aof
-rw-r--r-- 1 root root 102 8月  30 16:18 appendonly.aof.manifest

xx.aof.base.rdb # 全备
xx.aof.1.incr.aof # 增量
xx.aof.mnifest # 清单/目录

4. 重启看看数据有没有正常加载

修复AOF文件 -> redis-check-aof

模拟aof文件出错

vim appendonly.aof.1.incr.aof
在aof文件末尾添加一些内容

[root@db appendonlydir]# redis-check-aof --fix appendonlydir/appendonly.aof.1.incr.aof 
Start checking Old-Style AOF
AOF appendonlydir/appendonly.aof.1.incr.aof format error
AOF analyzed: filename=appendonlydir/appendonly.aof.1.incr.aof, size=130, ok_up_to=107, ok_up_to_line=27, diff=23
This will shrink the AOF appendonlydir/appendonly.aof.1.incr.aof from 130 bytes, with 23 bytes, to 107 bytes
Continue? [y/N]: y
Successfully truncated AOF appendonlydir/appendonly.aof.1.incr.aof

启动服务，查看数据

AOF瘦身

AOF持久化通过将写操作追加到AOF文件实现的 => AOF文件会不断变大

1. 占磁盘空间
2. 恢复时间变长

重写机制

• 当AOF文件超过设置大小(条件)，Redis自动启动AOF文件内容压缩
• bgrewriteaof

AOF文件重写并不对原文件内容进行整理 => 而是直接读取服务器现有的键值对，用一条命令替代之前的修改操作，生成新的文件替换原来的AOF

两个条件需要同时满足

# 当前文件大达增长百分比（100）
auto-aof-rewrite-percentage 100
# 文件至少达到64M
auto-aof-rewrite-min-size 64mb

手动触发

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

rewrite => 不是分析原来AOF文件，而是读取当前Redis内存中数据进行分析

1. 启动一个重写子进程 -> 读取当前Redis内存中数据，将它分析压缩放到新AOF文件
2. 主进程写命令放到内存缓冲区，同时写入原有AOF
3. 重写子进制完成重写工作后，给父进程发一个信号 -> 父进程收到信号后会将数据写入新的AOF文件中

AOF和RDB可以共存
AOF优先级高
同时启用RDB和AOF,重启只会加载AOF文件，不会RDB
aof-use-rdb-preamble yes