Redis持久化策略

Redis持久化策略

 

数据持久化功能是redis相比于其他缓存中间件具有的优势之一，它可以保证在redis重启时，数据不丢失，以提升系统的性能及可用性。

那么redis是如何实现数据持久化的呢？它提供了两种数据持久化的解决方案： RDB、AOF。

RDB

redis默认的持久化策略是RDB方案，rdb方案生成的rdb文件是一个经过压缩的二进制文件，通过它可以还原到生成RDB文件时的数据库状态，当redis仅开启了RDB方案重启时会载入rdb文件，这期间服务器处于阻塞状态，直到载入完成。

redis提供了手动和自动两种方式生成rdb文件

手动方式

• 执行save命令，该命令会让服务器处于阻塞状态直到生成RDB文件结束，这个命令会导致redis服务器暂时不可用，所以不推荐。
• 执行bgsave命令，redis会fork一个子进程，由子进程来完成生成RDB文件的操作。这个命令不会阻塞客户端请求（只有在fork进程时会发生短暂的阻塞）。

  自动方式

•  可以通过在配置文件中设置生成RDB文件的触发条件，如下是redis的默认配置 ，这几种情况(900秒内至少出现一条数据更改，300秒内至少出现10条数据更改，60秒内至少出现10000条数据更改)都会触发redis执行bgsave命令。

save 900 1
save 300 10
save 60 10000

AOF 

redis提供的另外一种持久化策略：AOF方案，它通过记录redis服务器所执行的写命令来记录数据库状态。

当AOF持久化功能处于打开状态时，服务器在执行一条写命令之后，会以协议格式将执行的写命令追加到记录服务器状态的aof_buf缓冲区的末尾。

针对何时将aof_buf缓冲区的内容写入并同步到aof文件中，redis提供了三种方式：

• always ：总是将aof_buf缓冲区的内容写入并同步到AOF文件，数据完整性好（最多丢失一个事件循环内的数据更改），但性能差。
• everysec:  将aof_buf缓冲区的内容写入AOF文件，如果距离上次同步AOF文件时间超过一秒，那么同步aof文件。性能好，但可能丢失一秒内的数据。
• no ：将aof_buf缓冲区的内容写入AOF文件，同步AOF文件操作由操作系统决定，性能与everysec差不多，但可能丢失更多的数据。

注：为了提高文件的写入效率，现代操作系统会将写入数据暂时保存在一个内存缓冲区中，当缓存区写满或达到限定时间时， 再真正将缓冲区内数据写入磁盘，但这种做法也给数据带来了安全问题，如果计算机停机，缓存区中的内容会丢失。为此系统提供了fsync和fdatasync两个同步函数，它们可以强制操作系统立即将缓存区中的内容写入到磁盘中，从而确保写入数据的安全性。

下面是同步AOF文件的默认配置：

# appendfsync always
appendfsync everysec
# appendfsync no

当执行一条 set name jason 命令时，可以直接打开AOF文件，我们可以在文件末尾看到如下内容：  

$3
set
$4
name
$5
jason

 aof文件重写

随着服务器运行时间的流逝，AOF文件中的内容会越来越多，如果不加以控制，体积过大的AOF文件可能会对redis服务器造成影响，所以redis提供了 AOF重写的机制，以应对AOF文件越来越大的问题。 执行bgrewriteaof命令，redis服务器会创建一个子进程 通过读取当前数据库的状态生成一个新的AOF文件，在命令执行期间，redis服务器会维护一个AOF重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令，当子进程创建好新的AOF文件之后，服务器会将重写缓冲区中的内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致，最后服务器会用新的AOF文件替换旧的AOF文件，完成AOF文件的重写操作。

rdb与aof的对比

RDB持久化	AOF持久化
全量备份,一次保存整个数据库	增量备份,一次保存一个修改数据库的命令
保存的间隔较长	保存的间隔默认一秒
数据还原速度快	数据还原速度一般
save会阻塞,但bgsave或者自动不会阻塞	无论是平时还是AOF重写,都不会阻塞
更适合数据备份,默认开启	更适合用来保存数据,和一般SQL持久化方式一样,默认关闭
启动优先级 : 低	启动优先级 : 高
体积 : 小	体积 : 大
恢复速度 : 快	恢复速度 : 慢
数据安全性 : 丢数据	数据安全性 : 根据策略决定
轻重 : 重	轻重: 轻