redis的持久化(RDB与AOF)

1、为什么redis要实现持久化?

避免因宕机、断电等场景导致进程退出后数据丢失,如果redis的数据都只存放于内存,那么进程退出后数据就丢失了。持久化机制可以持久化内存数据到硬盘,重启redis后基于持久化数据进行恢复。

2、redis持久化的方式有哪些

2.1 RDB,定时对进程数据拍摄快照存储到硬盘的持久化方式

2.1.1如何触发RDB持久化?

2.1.1.1手动触发

1.【不推荐】Redis Save 命令执行一个同步保存操作,将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。此命令会阻塞当前Redis服务器,直到RDB过程完成为止,对于内存比较大的实例会造成长时间阻塞,线上环境不建议使用。
命令如下

redis 127.0.0.1:6379> SAVE 
OK

2.【推荐】为了解决SAVE命令对redis实例的阻塞问题,redis提供另一个命令:BGSAVE。
Redis BGSAVE 命令用于在后台异步保存当前数据库的数据到磁盘。

BGSAVE 命令执行之后立即返回 OK ,然后 Redis fork 出一个新子进程,原来的 Redis 进程(父进程)继续处理客户端请求,而子进程则负责将数据保存到磁盘,然后退出。
命令如下:

redis> BGSAVE
Background saving started

显然BGSAVE 命令是针对SAVE阻塞问题做的优化。因此Redis内部所有的涉
及RDB的操作都采用BGSAVE 的方式,而SAVE命令已经废弃。

2.1.1.2 自动触发

REDIS在以下场景会自动触发RDB落盘:

  • 使用save相关配置,如“save m n”。表示m秒内数据集存在n次修改
    时,自动触发bgsave。
  • 如果从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点,更多细节见6.3节介绍的复制原理。
  • 执行debug reload命令重新加载Redis时,也会自动触发save操作。
  • 默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则
    自动执行bgsave。

2.1.2 BGSAVE处理流程

BGSAVE命令处理流程

1.执行bgsave命令,Redis父进程判断当前是否存在正在执行的子进
程,如RDB/AOF子进程,如果存在bgsave命令直接返回。

2.父进程执行fork操作创建子进程,fork操作过程中父进程会阻塞,通
过info stats命令查看latest_fork_usec选项,可以获取最近一个fork操作的耗
时,单位为微秒。

3.父进程fork完成后,bgsave命令返回“Background saving started”信息
并不再阻塞父进程,可以继续响应其他命令。

4.子进程创建RDB文件,根据父进程内存生成临时快照文件,完成后
对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的
时间,对应info统计的rdb_last_save_time选项。

5.进程发送信号给父进程表示完成,父进程更新统计信息,具体见
info Persistence下的rdb_*相关选项。

2.1.3 RDB日志文件在哪?

保存在dir参数指定的目录下。
改变RDB日志文件存储目录命令:

config set dir {newDir}

改变RDB日志文件名命令:

config set dbfilename {newFileName}

\color{red}{当遇到坏盘或磁盘写满等情况时,可以通过config set dir{newDir}在线 修改文件路径到可用的磁盘路径,之后执行bgsave进行磁盘切换,同样适用 于AOF持久化文件}
Redis默认采用LZF算法对生成的RDB文件做压缩处理,压缩后的
文件远远小于内存大小,默认开启,可以通过参数config set rdbcompression{yes|no}动态修改。
虽然压缩RDB会消耗CPU,但可大幅降低文件的体积,方便保存到硬盘
或通过网络发送给从节点,因此线上建议开启。

2.2 AOF,基于日志文件记录写命令日志的高实时性持久化方式

2.2.1 那么我怎么才能把AOF用起来呢?

很简单,只需要修改redis.conf文件的一个配置参数即可,如下

appendonly yes  #开启AOF模式

按AOF日志文件恢复数据的流程如下:


AOF日志文件加载流程

2.2.2 记录AOF日志的流程是啥样的?

AOF写入流程

1.所有的写入命令会追加到aof_buf(缓冲区)中。

2.AOF缓冲区根据对应的策略向硬盘做同步操作。

3.随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩
的目的。

4.当Redis服务器重启时,可以加载AOF文件进行数据恢复。

AOF日志使用文本协议格式存储,set hello world命令的AOF日志格式如下:

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

2.2.3 AOF缓冲区和磁盘AOF文件同步的策略有哪些?

AOF缓冲区和磁盘同步策略
  • 配置为everysec,是建议的同步策略,也是默认配置,做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。

  • 配置为no,由于操作系统每次同步AOF文件的周期不可控,而且会加大每次同步硬盘的数据量,虽然提升了性能,但数据安全性无法保证。

  • 配置为always时,每次写入都要同步AOF文件,在一般的SATA硬盘上,Redis只能支持大约几百TPS写入,显然跟Redis高性能特性背道而驰,不建议配置。

2.2.4 缩小AOF日志文件的体积的方法:AOF重写

  • 手动触发:直接调用bgrewriteaof命令。

  • 自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参
    数确定自动触发时机

3.两种持久化方式的优劣对比

  • RDB性能优于AOF,在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储,启动效率比AOF高。例如三点十分拍摄快照,随后写入了几条数据,在三点十五分宕机,那么这几条数据就丢失了,实时性差。

  • AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录,弥补了RDB的实时性问题。

  • 二者选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(aof),还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行save的时候,再做备份(rdb)。rdb这个就更有些 eventually consistent的意思了。不过生产环境其实更多都是二者结合使用的。

你可能感兴趣的:(redis的持久化(RDB与AOF))