第一种是 RDB 快照,第二种是 AOF 日志。
RDB 快照是某一个时间节点的一次全量备份,二进制文件;AOF 日志是追加式的增量备份,内存数据修改的指令记录;
RDB 触发机制:
RDB 持久化触发机制 :手动触发和自动触发
执行 save 命令:阻塞当前服务器进程,直到 RDB 过程完成,一旦数据量过大可能会造成长时间的进程阻塞,线上环境一般禁止;
使用 bigsave(background save) 命令 :执行 bgsave 命令时 Redis 主进程会 fork 一个子进程来完成 RDB 持久化过程,完成后自动结束(操作系统的多进程 Copy On Write 机制)。
所以 Redis 主进程阻塞时间只有 fork 这一阶段,相对于 save 阻塞时间很短。
自动触发 :
场景一:配置 redis.conf 触发规则:
当在规定的时间内,Redis 发生了写操作的个数满足条件,自动触发发生 BGSAVE 命令(当用户设置了多个save的选项配置,只要其中任一条满足,Redis都会触发一次BGSAVE操作)
save 900 1 #900秒之内至少一次写操作
save 300 10 #300秒之内至少发生10次写操作
save 60 10000 #60秒之内发生至少10000次写操作
场景二:执行 shutdown 命令关闭服务器时,如果没有开启 AOF 持久化功能,那么会自动执行一次 bgsave
场景三:主从同步(slave和master建立同步机制)
如何关闭RDB快照持久化方式:
注掉 save 配置;
RDB 的执行流程:
Redis 使用操作系统的多进程 Copy On Write 机制来实现 RDB 快照持久化
1)执行 bgsave 命令,Redis 主进程会检查是否有子进程在执行 RDB/AOF 持久化任务,如果有,直接返回,主线程继续接收 redis 命令并执行;
2)如果没有,Redis 主进程会 fork 一个子进程执行执行 RDB 操作,fork 操作这一过程不会对主进程造成阻塞(Redis 主进程正常接收命令);
3)RDB 子进程会根据 Redis 主进程的内存生成临时的快照文件,持久化完成后会使用临时快照文件替换掉原来的RDB文件;
(子线程与主线程共享内存,RDB 操作过程中,主线程修改一块数据,该过程中主进程的读写不受影响,子线程与主线程共享内存,Redis 的写操作不会同步到主进程的主内存,而是会写到一个临时的内存区域作为一个副本)
4)子进程完成 RDB 持久化后会发消息给主进程,通知 主进程RDB 持久化完成(将上阶段内存副本中的增量写数据同步到主内存)
优点:
文件小,定时备份
redis加载RDB文件的速度比AOF(RDB文件直接存储内存数据,AOF文件中存储的是一条条命令,需要回放命令)
缺点:
RDB 无法做到实时持久化,若在两次 bgsave 间宕机,则会丢失一部分(分钟级)的增量数据,不适用于实时性要求较高的场景
RDB 的 Copy On Write 机制中,fork子进程属于重量级操作,并且会阻塞 redis 主进程
注*** 存在老版本的 Redis 不兼容新版本 RDB 格式文件的问题
--- 删除 rdb 文件/usr/local/redis/data/6379/dump.rdb
---重启 redis
AOF 日志:
Redis 收到的每一条写入命令,并以文本形式保存;
属于持续增量的备份,是基于写命令存储的可读的文本文件;
目前 AOF 是 Redis 持久化的主流方式;
AOF 触发机制 :手动触发、自动触发
手动触发:调用 bgrewriteaof 命令
redis-cli -h ip地址 -p 端口号 bgrewriteaof
自动触发:
根据 auto-aof-rewrite-min-size 、 auto-aof-rewrite-percentage 参数确定自动触发时机
auto-aof-rewrite-min-size : 表示运行 AOF 重写时文件最小体积,默认 64MB(建议 512MB)。
auto-aof-rewrite-percentage : 代表当前 AOF 文件空间(aof_current_size)和上一次重写后 AOF 文件空间(aof_base_size)的比值
自动触发时机 :(aof_current_size > auto-aof-rewrite-min-size ) && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
AOF日志会在持续运行中持续增大,由于 Redis 重启过程需要优先加载AOF日志进行指令重放以恢复数据,恢复特别耗时,所以需要定期进行AOF重写,对AOF日志进行瘦身。
开启方式:
AOF 默认是关闭的,通过 redis.conf 配置文件进行开启:
## 此选项是 aof 功能的开关,默认 no,配置 yes 开启 aof 功能 ,此时 aof 重写、文件同步等特性才会生效
appendonly yes
## 指定 aof 文件名称
appendfilename appendonly.aof
## 指定 aof 操作中文件同步策略,可选参数 :always everysec no, 默认 everysec
## always:每执行一条写命令,都会触发AOF 持久化机制(每次写入,都会调用fsync函数,缓存数据同步到磁盘文件)
## everysec:每秒调用一次fsync函数,将缓存数据写入AOF文件(一旦遇到物理服务器故障,可能导致最多1秒的 AOF 记录丢失)
## no :操作系统决定何时同步到磁盘文件(写操作不会调用fsync函数,是由操作系统自动调度将内存数据刷新到磁盘文件)
appendfsync everysec
## 在 aof-rewrite 期间,appendfsync 是否暂缓文件同步,no - 不暂缓,yes - 暂缓,默认 no
no-appendfsync-on-rewrite no
## aof 文件 rewrite 触发的最小文件大小(mb,gb),只有大于此 aof 文件,才会触发 rewrite,默认 64mb,建议 512mb
auto-aof-rewrite-min-size 64mb
## 相对于上一次 rewrite,本次 rewrite 触发时 aof 文件应该增长的百分比(每一次 rewrite 之后,redis 都会记录下此时“新 aof ”文件的大小)
## aof 文件增长到A*(1 + p)之后,触发下一次 rewrite,每一次 aof 记录的添加,都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100
注***:
AOF 是文件操作命令文本,对于变更操作比较密集的 server ,将造成磁盘 IO 负荷加重。
linux 对文件操作采取“延迟写入”,并非每次 write 操作都会触发实际磁盘操作,而是先写入buffer(缓存),一旦 buffer 数据达到阀值时,触发实际写入(也有其他时机)
--- linux 对文件系统的一种优化手段。Linux 的 glibc 提供了fsync(int fd)函数可以将指定文件的内容强制从内存刷入到磁盘。
---
fsync 是AOF 文件的一个刷盘命令,将缓存数据写入 appendonly.aof 文件,只要 Redis 进程实时调用 fsync 函数就可以保证 aof 日志不丢失。
但是 作为一个磁盘 IO 操作,慢!如果 Redis 执行一条指令就要 fsync 一次,Redis 性能就无法保证了!!!
AOF 重写机制:
AOF 日志运行中持续增大,需要定期进行 AOF 重写,对日志进行瘦身。
AOF Rewrite 是“压缩”AOF文件的过程,但并非采用“基于原AOF文件”重写或压缩,而是采取了类似 RDB 快照的方式:
基于 Copy On Write 全量遍历内存中数据,然后逐个追加写入 AOF 文件。
AOF 重写(bgrewriteaof)和 RDB 快照写入(bgsave)过程类似,消耗磁盘 IO 。
Redis采取了“schedule”策略:无论是“人工干预”还是“系统触发”,快照和重写需要逐个被执行。
重写过程,Redis 对于新的变更操作命令仍然写入到原AOF文件,同时将这些新的变更操作收集起来。内存中的数据被全部写入到新的AOF文件之后,收集的新的变更操作也将被一并追加到新的AOF文件。然后将新AOF文件重命名为appendonly.aof,使用新AOF文件替换老文件,此后所有的操作都将被写入新的AOF文件。
AOF 优点:
追加写日志文件,对服务器性能影响较小,速度比 RDB 快,消耗的内存较少
一般AOF日志保存的数据比RDB文件一致性更高
AOF 缺点:
AOF 生成的日志文件过大,需要不断重写 AOF文件,进行文件瘦身
数据重构、数据恢复,AOF 重放恢复数据的速度,比 RDB 慢
混合持久化:
rdb 文件的内容和增量的 AOF 日志文件一起保存,AOF 日志不再是全量的日志,而是自持久化开始到持久化结束的这段时间数据修改的增量 AOF 日志
---不仅仅将内存数据转换数据修改命令写入 AOF 文件,而是将重写这一刻之前的内存数据以RDB快照处理,并将RDB快照与增量的AOF修改命令保存在一起写入新的临时文件,从写完成之后,命名为 appendonly.aof,替代原来旧的AOF文件,redis 重启时,先加载RDB快照,再重放增量的AOF日志,完成数据恢复
Redis 重启的时候,可以先加载 rdb 的内容,然后再重放增量 AOF 日志,替代 AOF 全量文件重放,大幅度提高重启效率
---数据量大情况下,粗粒度(时间上)的rdb快照方式,性能高,恢复速度快
---增量数据,细粒度(时间上)的 AOF 日志方式,尽量保证数据的不丢失
开启混合持久化(必须先开启AOF)配置:
# aof‐use‐rdb‐preamble yes
混合持久化 --- 本质上还是AOF持久化方式,唯一区别只是在AOF文件重写的时候,将内存中之前保存的数据以快照的形式写入到AOF文件中保存
另外:
Master 采用 AOF 日志,Slave 采用 RDB 快照;
master 需要首先确保数据完整性,它作为数据备份的第一选择;
slave 提供只读服务或仅作为备机,它的主要目的就是快速响应客户端 read 请求或容灾切换