吃透Redis系列：数据持久化

欢迎关注微信公众号：互联网全栈架构

Redis是一款内存数据库，从而使得它的性能非常优越，然而，内存中的数据是容易丢失的，为了解决数据的安全性和可靠性问题，Redis引入了持久化机制。Redis支持以下三种持久化方式：

RDB(Redis Database)：快照方式，它是Redis默认的持久化方式，在一定的间隔时间内，它将内存中的数据以快照的方式写入到二进制文件当中。

AOF(Append Only File)：文件追加方式，它记录对于服务器的每一次写操作，并写入到文件中，服务器重启时，通过重新执行这些命令来恢复数据。

RDB+AOF：混合持久化，它结合了RDB和AOF两者的优点。在AOF重写(rewrite)操作时，把服务器中的数据以RDB的形式保存到AOF文件的开头，再将后续的写命令以AOF的形式存入文件，这样既保证了Redis重启时数据恢复的速度，又避免了数据丢失的风险。

接下来我们详细讲解这几种方式的优缺点以及相关的配置，文章最后再用一张思维导图来进行总结，方便理解与记忆。

一

RDB

1. RDB的触发条件

RDB将内存中某一时刻的数据快照全量写入到文件中，它可以手动触发，也可以通过配置条件自动触发。

手动触发。可通过执行命令save或者bgsave来进行，save会阻塞所有的客户请求，直到持久化完成，而bgsave在后台异步执行，但它生成的RDB文件较大。

127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started

自动触发。在文件中redis.conf中配置持久化的触发条件，比如像下面这样：

save 3600 1   # 在3600秒内至少有一次写操作
save 300 100  # 在300秒内至少有100次写操作
save 60 10000 # 在60秒内至少有10000次写操作

2. RDB的常用配置

在redis.conf中还可以配置其他的RDB持久化参数，常见的有如下这些：

# RDB文件名，默认为dump.rdb
dbfilename dump.rdb
 
# RDB文件保存的目录，默认为当前目录
dir ./

# 是否压缩
rdbcompression yes
 
# 后台保存出错时，Redis是否停止写操作
stop-write-on-bgsave-error
 
# 导入时是否检查
rdbchecksum yes

3. RDB的优缺点

RDB持久化具备以下优点：

• • RDB文件是一个紧凑的二进制文件，相对较小

  • 比较适合灾备和数据备份
    

  • 性能较好，父进程fork一个子进程来专门持久化
    

  • 恢复大的数据集时，比较AOF要快

RDB的缺点：

• • 如果Redis宕机，会丢失一段时间的数据

  • 需要经常fork子进程，导致Redis可能在短时间内不能响应客户端请求

二

AOF

1. AOF介绍

AOF是一种基于日志的持久化方式，把Redis的写命令追加到文件的末尾，它保存了所有的写操作日志记录，以保证数据的持久性和完整性。由于AOF记录了所有的写操作，当Redis服务器重启的时候，可以通过执行AOF文件来恢复服务器的数据。

由于不断地向AOF文件写入数据，随着时间的推移，AOF会变得越来越臃肿和庞大，为了解决这个问题，Redis引入了重写机制，当AOF文件达到所配置的值以后，Redis就会执行重写操作，删除冗余的写操作，从而达到精简AOF文件的目的。比如INCR这个命令（将存储的数字加1），如果我们使用了100次，那么在AOF中就保留了100条这样的命令，而精简后只需要保留一条命令，把数值直接增加到100（此例子仅为解释概念）。

2. AOF的相关配置

AOF默认是关闭，如果要开启的话则需要把appendonly的配置项改为yes，在配置文件redis.conf中或者通过命令config set appendonly yes进行修改。

# 设置AOF持久化的文件名
appendfilename "appendonly.aof"

# 是否开启AOF持久化
appendonly yes  # yes为开启AOF持久化，no不开启

# AOF持久化的频率
# appendfsync always  # 每次数据修改都同步到磁盘，安全高，效率低
appendfsync everysec  # 每秒钟同步一次
# appendfsync no      # 从不主动写入，依赖于操作系统的缓存同步机制

# AOF重写配置
auto-aof-rewrite-percentage 100  # 文件增长超过此比例时触发重写
auto-aof-rewrite-min-size 64mb   # 文件超过比例且大小超过此大小时重写

3. AOF的优缺点

AOF的优点：

• • 更好的数据完整性，每个写操作都同步到磁盘

  • 它是一个文本文件，更容易阅读、理解

  • 文件过大时，可以在后台自动重写

AOF的缺点：

• • AOF文件通常比RDB要大

  • 性能通常比RDB要低，因为它对每个写命令都要进行同步

三

RDB+AOF

混合持久化是在AOF的基础上，定期进行RDB操作，它在AOF重写时，将RDB二进制数据写入到AOF文件的开头，之后的数据再以AOF的格式追加到文件的末尾。这样的话，它就结合了两者的优点，减少了AOF文件的大小，且可以快速地恢复数据，同时可以避免数据丢失。

混合持久化的配置项是aof-use-rdb-preamble。示例如下：

# 设置RDB持久化的触发频率
save 3600 1   # 在3600秒内至少有一次写操作
save 300 100  # 在300秒内至少有100次写操作
save 60 10000 # 在60秒内至少有10000次写操作
 
# 开启AOF
appendonly yes
 
# AOF文件的更新频率
appendfsync everysec
 
# 启用混合持久化模式
aof-use-rdb-preamble yes

四

总结

从上面可以看出，RDB和AOF各有优劣，那么在实际开发中应该如何进行选择呢？按照官网的说明，一般情况下选择混合持久化的模式，这样可以达成与关系型数据库相媲美的数据安全性；如果对数据安全性要求不是太高，可以忍受一段时间的数据丢失，则可以使用RDB持久化；不推荐只使用AOF的持久化方式。

另外，如果Redis仅仅作为缓存使用，出于性能的考量，可以关闭持久化功能。（应该使用什么命令来关闭RDB，欢迎后台私信）。

最后，我们用一张思维导图来总结RDB和AOF各自的特点：

创作不易，烦请点个在看、点个赞，感谢！

推荐阅读：

吃透Redis系列：琳琅满目的数据类型（下篇，文末彩蛋）

吃透Redis系列：琳琅满目的数据类型（上篇）

吃透Redis系列：总体介绍

离大谱，MySQL竟然无视空格的存在！