Redis的持久化机制:RDB快照(Redis Database)、AOF日志(Append-Only File)。
一、RDB快照
RDB持久化是指在指定的时间间隔内将内存中的数据集以快照的方式写入磁盘,并保存到一个名为dump.rdb的二进制文件中,也是默认的持久化方式,它恢复时是将快照文件从磁盘直接读到内存里。
RDB触发机制:save、bgsave、自动化触发。
RDB执行流程
(1)执行bgsave命令的时候,Redis主进程会检查是否有子进程在执行RDB/AOF持久化任务,如果有的话,直接返回,主要是为了性能的考虑,防止两个进程同时对磁盘进行写入操作。
(2)Redis主进程fork一个子进程来执行执行RDB操作,fork操作会对主进程造成阻塞(影响Redis的读写),fork操作完成后会发消息给主进程,从而不再阻塞主进程。
(3)RDB子进程把Redis主进程的内存数据,写入到一个临时的快照文件,持久化完成后,再使用临时快照文件替换掉原来的RDB文件。(该过程中主进程的读写不受影响,但Redis的写操作不会同步到主进程的主内存中,而是会写到一个临时的内存区域作为一个副本)。
(4)子进程完成RDB持久化后会发消息给主进程,通知RDB持久化完成,并将内存副本中的增量写数据同步到主内存。
优点
(1)RDB 文件存储的内容是经过压缩的二进制数据, 保存着某个时间点的数据集,文件很小,适合做数据的备份,灾难恢复。
(2)使用 RDB 文件恢复数据,直接解析还原数据即可,速度非常快。
缺点
(1)fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑。
(2)当进行快照持久化时,会开启一个子进程专门负责快照持久化,子进程会拥有父进程的内存数据,父进程修改内存子进程不会反应出来,所以在快照持久化期间修改的数据不会被保存,可能丢失数据。
(3)在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。
二、AOF日志
AOF是通过将所有写操作记录到 AOF 文件中来实现持久化的。当 Redis 服务器重启时,它会从 AOF 文件中重放所有写操作来恢复数据。
AOF触发机制:每修改同步、每秒同步、不同步。
AOF重写机制
因为AOF采用文件追加方式,文件会越来越大,为避免出现此种情况,需要定期进行AOF重写,当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩,只保留可以恢复数据的最小指令集。redis提供了bgrewriteaof命令,fork一个新的进程对aof文件进行重写。
AOF文件持续增长而过大时,会fork出一条新进程来重写aof文件,将内存中的整个数据库内容用命令的方式重写了一个新的aof文件(注意:在重写时并不是读取旧的aof文件),在执行 bgrewriteaof 命令时,Redis 服务器会维护一个 AOF 重写缓冲区,该缓冲区会在子进程创建新AOF文件期间,记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后,服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾,使得新旧两个AOF文件所保存的数据库状态一致。最后,服务器用新的AOF文件替换旧的AOF文件,以此来完成AOF文件重写操作。
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
优点
(1)AOF可以更好的保护数据不丢失。
(2)AOF只是追加写日志文件,对服务器性能影响较小,消耗的内存较少。
缺点
(1)AOF文件过大。