1. 简介
Redis作为内存型数据库,数据都保存在内存中,如果重启或意外宕机后,数据会全部丢失。因此,Redis提供了完善的持久化机制,将内存中的数据持久化到磁盘上,避免了完整性和安全性的问题,也方便进行数据备份和恢复。
2. 持久化方式
- RDB:产生一个数据快照文件
- AOF:实时追加命令的日志文件
3. RDB
RDB(Redis Database Backup file),即Redis数据备份文件或Redis数据快照。通过执行save
或bgsave
命令让Redis在本地生成RDB快照文件,这个RDB文件包含了整个实例接近完整的数据内容。
- 优点
内存小:RDB将数据压缩写入,因此要比整个实例内存小;
恢复快:当宕机恢复时,可以快速加载RDB文件并恢复文件中的数据; - 缺点
数据不全:因为是某一时刻的数据对照,因此可能会数据不全;
消耗大:生成RDB文件时会消耗大量的CPU和内存资源; - 适用场景
对丢失数据不敏感的业务场景;
主从全量同步数据;
数据库备份; - 定时生成RDB
# 最近1分钟内,至少生成1次 save 60 1 # 最近5分钟内,至少生成10次 save 300 10 # 最近15分钟内,至少生成10000次 save 900 10000
- Copy On Write
通过执行save
或bgsave
命令都可以生成RDB文件,前者为前台执行,即生成RDB文件时,会阻塞整个实例,在生成之前,任何请求都是无法处理的,对于数据量非常大的实例,生成RDBwen文件将非常耗时。因此,通常会使用bgsave
命令在后台执行,这样Redis依旧可以处理客户端请求,不会阻塞整个实例。
通过执行bgsave
命令生成RDB文件采用操作系统的的Copy On Write技术,即fork系统
调用。fork系统
调用会产生一个子进程,它与父进程共享相同的内存地址空间,于是子进程在这一时刻就能拥有与父进程的相同的内存数据,操作系统将父进程的内存页表拷贝给子进程,如果整个Redis实例内存占用很大,那它的内存页表也会很大,在拷贝时就会非常耗时,同时这个过程也会消耗大量的CPU资源。在完成拷贝之前父进程处于阻塞状态,无法处理客户端请求。即fork系统
调用完成之后,子进程把全部数据写入到RDB文件中;以此同时,父进程依旧处理客户端的请求,当在处理写命令时父进程会从操作系统申请新的内存地址空间,不再与子进程共享,这样父子进程的内存会分离开,父进程在新申请的内存地址中修改数据对子进程不受影响。
由此可以看出,通过执行save
或bgsave
命令在生成RDB文件时,不仅消耗CPU资源,还有需要占用最多一倍的内存空间。因此,使用此方式时需要评估即fork系统
调用耗时,并且保证Redis实例所在的机器拥有足够的CPU和内存资源,并合理设置生成RDB的时机。
4. AOF
AOF(Append Only File)即追加日志文件。它与RDB不同的是,AOF中记录的是每一个命令的详细信息,包括完整的命令类型、参数等。只要产生写命令,就会实时写入到AOF文件中。
- 优点
数据完整:AOF数据文件更新比较及时,比RDB保存更完整的数据,这样在数据恢复时能够恢复尽量完整的数据,降低丢失数据的风险。 - 缺点
增加IO负担:随着时间增长,AOF文件会越来越大
AOF文件刷盘会增加磁盘IO的负担,可能影响Redis的性能(开启每秒刷盘时)。 - 适用场景
对丢失数据敏感的业务场景。Redis会优先使用AOF文件进行数据恢复。 - 刷盘方式
开启AOF后,Redis会把每个写操作的命令记录到文件并持久化到磁盘中,为了保证数据文件的安全性,Redis还提供了三种文件刷盘的机制:
(1)appendfsync always:每次写入都刷盘。对性能影响最大,占用磁盘IO比较高,数据安全性最高。
(2)appendfsync everysec:1秒刷一次盘,对性能影响相对较小,节点宕机时最多丢失1秒的数据。
(3)appendfsync no:按照操作系统的机制刷盘,对性能影响最小,数据安全性低,节点宕机丢失数据取决于操作系统刷盘机制。 - 开启AOF
# 开启AOF appendonly yes # AOF文件名 appendfilename "appendonly.aof" # 文件刷盘方式 appendfsync everysec
- AOF重写
Redis提供了AOF瘦身的功能,可以设置在AOF文件很大时,自动触发AOF重写,Redis会扫描整个实例的数据,重新生成一个AOF文件达成瘦身的效果。但这个重写过程也需要消耗大量的CPU资源。# AOF文件距离上次文件增长多少百分比时触发重写 auto-aof-rewrite-percentage 100 # AOF文件体积达到多少时触发重写 auto-aof-rewrite-min-size 64mb
- 性能影响
如果AOF的刷盘机制设置为每次写入都刷盘,那么会大大降低Redis的写入性能,因为每次写命令都需要写入文件并刷到磁盘中才会返回,当写入量很大时,会增加磁盘IO的负担。
虽然Redis提供了实时刷盘的机制,但是在真正场景中使用的不多。通常我们会选择每秒刷盘这种方式,既能保证良好的写入性能,在实例宕机时最多丢失1秒的数据。
5. 总结
特性 | RDB | AOF |
---|---|---|
持久化方式 | 生成某一时刻的数据快照文件 | 实时记录每一个写命令到文件 |
数据完整性 | 不完整,取决于备份周期 | 相对完整性高,取决于文件刷盘方式 |
文件大小 | 压缩二进制写入,文件较小 | 原始的操作命令,文件大 |
宕机恢复时间 | 快 | 慢 |
恢复优先级 | 低 | 高 |
持久化代价 | 高,消耗大量CPU和内存 | 低,只占用磁盘IO资源 |
使用场景 | 对丢数据不敏感的业务场景快速数据恢复;数据备份;主从全量复制 | 对于丢失数据敏感的场景 |