Redis持久化

目录

一、RDB

1.两种场景

1.1主动停机

1.2突然宕机

2.bgsave原理

3.RDB缺点

二、AOF

1.三种记录频率比较

 三、RDB 和 AOF 比较

---

Redis数据持久化机制有两种：RDB、AOF

一、RDB

Redis Database Backup file(Redis数据备份文件)，也叫Redis数据快照，把内存中的所有数据记录到磁盘中，redis重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

• 执行save，Redis主进程来执行RDB，会阻塞所有命令。
• 执行bsave，返回Background saving started 后台保存，异步执行，有另外的线程单独执行。

1.两种场景

1.1主动停机

会自动执行sava

当Redis客户端停机会打印：Saving the final RDB snapshot before exting。 保存完成会有“DB saved  on  disk”提示信息。

1.2突然宕机

Redis 内部有出发RDB的机制，可以在redis.conf文件中找到，格式：

save  900 1

save 300 100

save  60 10000

save  900 1  表示在900s内至少有1个key被修改，则执行bgsave，如果是save  “ ” 则表示禁用RDB。

RDB的其他配置在redis.conf文件中设置：

是否压缩，将以不开启，压缩也会消耗cpu

rdbconpression yes

RDB文件名称

dbfilename  dump.rdb

文件保存的路径目录

dir ./

2.bgsave原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据，完成fork后读取内存数据并写入RDB文件，fork采用的是copy-on-write技术：

当主进程执行读操作时，访问共享内存；

当主进程进行写操作时，则会拷贝一份数据，进行写操作。

fork主进程得到一个子进程，共享内存空间

子进程读取内存数据并写入新的RDB文件（异步）

用新RDB文件替换旧的RDB文件

3.RDB缺点

RDB执行时间长，两次RDB之间写入数据有丢失的风险，fork子进程，压缩写出RDB文件都比较耗时。

二、AOF

Append Only File（追加文件），Redis处理的每一个写命令都会记录在AOF文件里，可看做是命令日志文件。

AOF默认是关闭的，需要修改redis.conf配置文件开启AOF：

是否开启AOF功能，默认关闭 no

appendonly yes

AOF文件名称

appendfilename  “appendonly.aof”

AOF的命令记录的频率通过redis.conf文件配置：

表示每执行一次命令，立即记录到AOF文件

appendfsync always

写命令执行完先放AOF缓冲区，然后每个1秒将缓冲区数据写到AOF文件，是默认方案

appendsync  everysec

写命令执行完先放AOF缓冲区，有操作系统决定何时将缓冲区内容写回磁盘。

appendfsync no

配置完成后，修改数据，停掉客户端：

Calling fsync()  on the AOF  file

重开客户端：DB  loaded  from append only file :0.000 seconds

1.三种记录频率比较

配置项	刷盘时机	优点	缺点
always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1s数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

 三、RDB 和 AOF 比较

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积大
宕机恢复速度	快	慢
数据恢复优先级	低，数据完整性比AOF较差	高，数据完成性高
系统资源占用	高，大量cpu和内存消耗	低，主要是磁盘IO
使用场景	可以容忍数分钟数据丢失，追求更快的启动速度。	对数据完全性要求较高