一、RDB快照持久化
在指定时间间隔将内存数据写入磁盘，默认持久化方式
触发方式
1. 执行save和bgsave命令
2. 配置文件设置save <seconds> <changes>规则，自动间隔性执行bgsave命令
3. 主从复制时，从库全量复制同步主库数据，主库会执行bgsave
4. 执行flushall命令清空服务器数据
5. 执行shutdown命令关闭Redis时，会执行save命令
save命令
save会阻塞redis进程，再快照创建完之前不能出来其他请求bgsave命令
bgsave不会阻塞redis进程，会fork出一个进程把全量数据写入临时rdb文件，再替换正式rdb文件
配置文件自动触发bgsave
# 900秒内有1次key改变则触发
save 900 1
# 300秒内有10次key改变则触发
save 300 10
# 60秒内有10000次key改变则触发
save 60 10000
- 优点：
RDB快照是一个压缩过的非常紧凑的文件，保存着某个时间点的数据集，适合做数据的备份，灾难恢复
可以最大化Redis的性能，在保存RDB文件，服务器进程只需fork一个子进程来完成RDB文件的创建，父进程不需要做IO操作
与AOF相比，恢复大数据集的时候会更快
- 缺点：
RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，根据配置可能要几分钟才快照一次，如果服务器宕机，那么就可能丢失几分钟的数据
Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时
二、AOF持久化
# appendonly参数开启AOF持久化
appendonly no
# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./
# 同步策略(always/everysec/no)
appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof出错如何处理
aof-load-truncated yes
# 文件重写策略
aof-rewrite-incremental-fsync yes
# 同时开启rdb、aof
aof-use-rdb-preamble yes
- append命令
开启aof，每个执行一个命令，都会把该命令以协议格式先追加到aof_buf缓存区的末尾，而不是直接写入文件，避免每次有命令都直接写入硬盘，减少硬盘IO次数
aof_buf写入aof策略：
appendfsync always：
将aof_buf缓冲区的所有内容写入并同步到AOF文件，每个写命令同步写入磁盘
appendfsync everysec：
将aof_buf缓存区的内容写入AOF文件，每秒同步一次，该操作由一个线程专门负责
appendfsync no：
将aof_buf缓存区的内容写入AOF文件，什么时候同步由操作系统来决定
- rewrite命令
随着时间推移，aof文件会越来越大，rewrite就是为了缩小aof文件的大小
rewrite不是读取aof文件，而是读redis生成新的aof文件替换老的aof文件
redis-7会把数据保存到aof目录下的rdb中，同时清空aof文件
命令触发
# fork出一个进程来执行，服务器继续执行命令，且最加到aof_buf、
# aof_rewrite_buf
127.0.0.1:6379> bgrewriteaof
- 自动触发 配置文件：
# 当AOF文件的体积大于64MB，且AOF文件的体积比上一次重写后的体积大了一倍（100%）时，会执行`bgrewriteaof`命令
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
- 优点：
数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）
AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复
- 缺点：
对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。 不过在一般情况下， 每秒 fsync 的性能依然非常高
Top comments (0)