Redis持久化机制

Redis持久化机制

RDB

​RDB​是一种快照存储持久化方式，具体就是将Redis​某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb​，而在Redis​服务器启动时，会重新加载dump.rdb​文件的数据到内存当中恢复数据。

手动触发

save

# 同步数据到磁盘上
> save

当客户端向服务器发送save命令请求进行持久化时，服务器会阻塞save命令之后的其他客户端的请求，直到数据同步完成。

bgsave

# 异步保存数据集到磁盘上
> bgsave

当客户端发服务发出bgsave​命令时，Redis​服务器主进程会forks​一个子进程来数据同步问题，在将数据保存到rdb​文件之后，子进程会退出。

主进程在forks​ 进程时会停止接收其他命令。

服务器配置自动触发

配置文件redis.conf​指定如下的选项：

# 900s内至少达到一条写命令
save 900 1
# 300s内至少达至10条写命令
save 300 10
# 60s内至少达到10000条写命令
save 60 10000

加载配置文件

# 启动服务器加载配置文件
redis-server redis.conf

这种通过服务器配置文件触发RDB​的方式，与bgsave​命令类似，达到触发条件时，会forks​一个子进程进行数据同步，不过最好不要通过这方式来触发RDB​持久化，因为设置触发的时间太短，则容易频繁写入rdb​文件，影响服务器性能，时间设置太长则会造成数据丢失。

rdb文件

前面介绍了三种让服务器生成rdb​文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：

1. 生成临时rdb​文件，并写入数据。
2. 完成数据写入，用临时文代替代正式rdb​文件。
3. 删除原来的db​文件。

​RDB​默认生成的文件名为dump.rdb​，当然，我可以通过配置文件进行更加详细配置，比如在单机下启动多个redis​服务器进程时，可以通过端口号配置不同的rdb​名称，如下所示：

# 是否压缩rdb文件
rdbcompression yes

# rdb文件的名称
dbfilename redis-6379.rdb

# rdb文件保存目录
dir ~/redis/

AOF

与RDB​存储某个时刻的快照不同，AOF​持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis​协议追加保存到以后缀为aof​文件末尾，在Redis​服务器重启时，会加载并运行aof​文件的命令，以达到恢复数据的目的。

开启AOF持久化方式

​Redis​默认不开启AOF​持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redis.conf​文件：

# 开启aof机制
appendonly yes

# aof文件名
appendfilename "appendonly.aof"

# 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或no
appendfsync always

# 默认不重写aof文件
no-appendfsync-on-rewrite no

# 保存目录
dir ~/redis/

写入策略

我们可以通过appendfsync​选项指定写入策略,有三个选项：

appendfsync always
# appendfsync everysec
# appendfsync no

always

这表示每当有写操作发生时，Redis都会立即将aof_buf中的内容写入磁盘。这意味着写入操作是同步进行的，由主服务器线程直接控制，这提供了最高的数据安全性，但可能会影响到Redis的性能，因为它等待磁盘I/O完成。

everysec

​appendfsync​的默认写入策略，每秒写入一次aof​文件，因此，最多可能会丢失1s的数据。这是默认设置，意味着Redis每秒会自动将aof_buf​中的内容写入磁盘一次。在这个模式下，写入操作仍然是由主服务器线程触发，但是它使用了操作系统的页缓存机制，因此在大多数情况下，实际的磁盘I/O会在后台异步完成，不会显著影响Redis的响应时间。

no

在这种模式下，写入aof_buf​的操作仍然由主服务器线程控制，但是将缓冲区内容写入磁盘的同步则完全交给了操作系统，由操作系统决定何时真正将数据刷新到磁盘。这种方式提供了最佳的性能，但牺牲了数据的持久性。

AOF文件重写

​AOF​将客户端的每一个写操作都追加到aof​文件末尾，比如对一个key​多次执行incr​命令，这时候，aof​保存每一次命令到aof​文件中，aof​文件会变得非常大。

incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000

aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：

set num 100000

aof文件是一个二进制文件，并不是像上面的例子一样，直接保存每个命令，而使用Redis自己的格式。

自动重写

通过在redis.conf​配置文件中的选项no-appendfsync-on-rewrite​可以设置是否开启重写，这种方式会在每次fsync​时都重写，影响服务器性以，因此默认值为no，不推荐使用。

# 默认不重写aof文件
no-appendfsync-on-rewrite no

手动重写

客户端向服务器发送bgrewriteaof​命令。

# 让服务器异步重写追加aof文件命令
> bgrewriteaof

修复AOF文件

写入aof​日志文件时，如果Redis​服务器宕机，则aof​日志文件文件会出格式错误，在重启Redis​服务器时，Redis​服务器会拒绝载入这个aof​文件，可以通过以下步骤修复aof​并恢复数据。

1. 备份现在aof文件，以防万一。
2. 使用redis-check-aof -fix file.aof​命令修复aof​文件。
3. 重启Redis服务器，加载已经修复的aof文件，恢复数据。

混合持久化

重启Redis​时，我们很少使用rdb​来恢复内存状态，因为会丢失大量数据。我们通常使用AOF​日志重放，但是重放AOF​日志性能相对rdb​来说要慢很多，这样在Redis​实例很大的情况下，启动需要花费很长的时间。

​Redis 4.0​ 为了解决这个问题，带来了一个新的持久化选项——混合持久化。AOF​在重写(aof​文件里可能有太多没用指令，所以aof​会定期根据内存的最新数据生成aof​文件)时将重写这一刻之前的内存rdb​快照文件的内容和增量的 AOF​修改内存数据的命令日志文件存在一起，都写入新的aof​文件，新的文件一开始不叫appendonly.aof​，等到重写完新的AOF​文件才会进行改名，原子的覆盖原有的AOF​文件，完成新旧两个AOF​文件的替换；AOF​根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof​重写AOF​。 于是在 Redis​ 重启的时候，可以先加载 rdb​ 的内容，然后再重放增量 AOF​ 日志就可以完全替代之前的 AOF​ 全量文件重放，重启效率因此大幅得到提升。

#redis 4.0引入
# 是否开启混合持久化
aof-use-rdb-preamble yes

‍