Redis的持久化方式

版权声明：本文为博主原创文章，转载请标明出处。 https://blog.csdn.net/qq2430/article/details/80686675

在Redis中，有2种持久化方式，分别为RDB和AOF的方式，下面分别介绍这两种方式。

RDB

RDB是直接将内存中的数据写入到文件中。我们可以使用save、bgsave命令和自动配置的方式保存数据。

1. save命令：同步保存操作，会阻塞所有客户端，将当前 redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

2. bgsave命令：异步保存当前数据库的数据到磁盘。命令执行之后立即返回 OK，然后 fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，文件保存结束后退出子进程。

3. 自动配置：通过配置文件中的持久化策略来自动保存文件，例如满足下列配置文件中的任意一策略，redis会自动执行bgsave操作。

save 900 1 //900秒内改变了1条数据
save 300 10 //300秒内改变了10条数据
save 60 10000 //60秒内改变了10000条数据

AOF

AOF是将写命令追加到文件中。Redis接受到写命令后，会将数据写入到缓冲区，然后通过刷新缓冲区的方式来将数据写入硬盘中。在Redis中提供了3种策略来保存数据

always //每条命令都写入到硬盘中
everysec //每秒把缓冲区数据写入到硬盘中
no //由操作系统决定何时将数据写入到硬盘中

AOF重写

AOF是将命令写入到文件中，但这样会有个问题，AOF文件的大小随着时间的流逝一定会越来越大。为了解决这个问题，redis提供了AOF重写功能：创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令。

我们来举个例子来说明AOF文件重写功能

例如原始的AOF文件如下所示：

set hello world
set hello java
set hello redis
incr count
incr count

那么经过重写后的文件如下所示,：

扫描二维码关注公众号，回复： 3037709 查看本文章

set hello redis
incr count 2

在redis可以使用bgrewriteaof命令类似于bgsave命令，或者通过配置的方式来自动进行aof重写。当aof文件的大小大于重写所需要的尺寸，以及文件增长率大于配置的增长率时，aof会自动进行重写。

auto-aof-rewrite-min-size //AOF文件重写需要的尺寸
auto-aof-rewrite-percentage //AOF文件的增长率

RDB和AOF的比较

看了RDB和AOF两种持久化方式，我们来比较下这两种方式的。

命令优先级：RDB的优先级小于AOF，当即使用RDB和AOF时，启动时优先加载的是AOF文件。

文件尺寸：RDB的文件尺寸要小于AOF文件。

恢复速度：使用RDB恢复数据要比使用AOF快。

数据安全性：RDB的数据安全性要比AOF低，因为使用RDB不可能频繁的执行持久化操作。如果某一时间redis宕机了，那么有可能会丢失数据。但是AOF配置every sec时，只会丢失1秒钟的数据。

操作轻重：RDB的操作更像是重量级操作，而AOF更像是轻量级操作。因为RDB是将整个数据集写入到硬盘中，如果RDB文件存在，则会进行替换。而AOF是不断的进行追加操作。