Redis支持RDB和AOF两种持久化机制,持久化功能有效地避免因进程退出造成的数据丢失问题,当下次重启时,利用之前持久化的文件即可实现数据恢复。
RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程,触发分为手动和自动
触发机制
手动触发: save命令:阻塞当前redis服务器,知道RDB完成为止,对于内存比较大的实例影响非常大,不建议使用 bgsave命令:redis进程执行fork操作创建子进程,rdb持久化过程由子进程负责,阻塞只发生在fork阶段,一般时间很短
自动触发 1.使用save相关配置 save m n 标识m秒内 数据存在n次修改,自动触发bgsave 2.从节点全量复制时也会执行bgsave 3.debug reload 命令加载redis时,也会触发save操作 4.执行shudown操作时
触发流程
1.执行bgsave,redis父进程会判断当前是否存在正在执行的子进程,存在就直接返回 2.父进程fork子进程,过程中父进程会发生阻塞,通过info stats 的latest_fork_usec可以获取最近一次fork操作耗时,单位为微秒 3.fork完成后,返回background saving started,阻塞完毕, 4.子进程创建rdb文件,根据父进程内存生成临时快照文件,对原文件进行院子替换,执行lastsave可以获取最后一次生成rdb的时间(info命令的rdb_last_save_time) 5.进程给父进程发送信号完成,父进程更新统计信息
RDB优缺点
优点: rdb是一个紧凑压缩的二进制文件,代表redis某个时间点的数据快照 适合用于备份 redis加载rdb恢复数据远远快于aof方式 缺点: 没有办法做到实时持久化 各个版本之间的rdb存在兼容问题
copy-on-write
fork()会产生一个和父进程完全相同的子进程(除了pid) 如果按传统的做法,会直接将父进程的数据拷贝到子进程中,拷贝完之后,父进程和子进程之间的数据段和堆栈是相互独立的。 但是,以我们的使用经验来说:往往子进程都会执行exec()来做自己想要实现的功能。 所以,如果按照上面的做法的话,创建子进程时复制过去的数据是没用的(因为子进程执行exec(),原有的数据会被清空) 既然很多时候复制给子进程的数据是无效的,于是就有了Copy On Write这项技术了,原理也很简单: fork创建出的子进程,与父进程共享内存空间。也就是说,如果子进程不对内存空间进行写入操作的话,内存空间中的数据并不会复制给子进程,这样创建子进程的速度就很快了!(不用复制,直接引用父进程的物理空间)。 并且如果在fork函数返回之后,子进程第一时间exec一个新的可执行映像,那么也不会浪费时间和内存空间了。 当父子进程中有更改相应段的行为发生时,再为子进程相应的段分配物理空间。
AOF:(append only file)
AOF以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的 AOF主要作用是解决了数据持久化的实时性,目前是Redis持久化的主流方式
appendonly yes appendfilename appendonly.aof
AOF的工作流程操作: 命令写入(append) 文件同步(sync) 文件重写(rewrite) 重启加载(load) 流程如下: 1.所有的写入命令会追加到aof_buf(缓冲区)中 2.AOF缓冲区根据对应的策略向磁盘做同步操作 3.定期对AOF文件重写,达到压缩目的 4.Redis重启,加载AOF文件进行数据恢复
命令写入: 直接使用文本协议格式追加 为什么写入aof_buf? 1.单线程,如果每次都写入,性能完全取决于硬盘 2.提供多种缓冲区同步硬盘的策略 3.性能和安全性做出平衡
文件同步: appendfsync 参数控制 always 每次写入都要同步AOF文件,安全,慢,与Redis高性能背道而驰 everysync 每秒同步一次,默认配置,理论上只有在系统宕机丢失1s数据(不严谨) no 使用操作系统负责同步硬盘 快,但是安全性无法保证(最多30s同步)
重写机制: 随着命令不断写入AOF,文件越来越大,为了解决这个问题,引入了重写机制
流程说明
1.执行AOF重写请求 2.父进程执行fork创建子进程,开销等同于bgsave 3.1 主进程fork操作完成后,继续接受响应请求 所有修改命令依然写入aof_buf 并根据同步策略同步硬盘,保证原AOF机制正确性 3.2 fork 利用写时复制技术,子进程只能共享fork操作时的内存数据 由于父进程依然响应命令,redis使用aof重写缓冲区保存这部分新数据 防止新aof文件生成期间丢失这部分数据 4.子进程根据内存快照,按照命令合并规则写入新的aof,批量 5.1aof写入完成之后,通知父进程 5.2父进程把aof重写缓冲区的数据写入新的aof文件 5.3使用新aof文件替换老文件,完成aof重写