谈谈Redis持久化

前言

我们都知道Redis 是基于内存的数据库，一旦服务器的进程退出，数据库数据就会随之丢失，这不是我们想看到的，为了避免这个问题，Redis 为我们提供了俩种持久化方案，将数据保存到磁盘上去，避免数据的丢失。

数据的持久化存储是 Redis 的重要特性之一，它能够将内存中的数据保存到本地磁盘中，实现对数据的持久存储。这样即使在服务器发生故障之后，也能通过本地磁盘对数据进行恢复。

RDB

RDB 即快照模式，它是 Redis 默认的数据持久化方式，它会将数据库的快照保存在 dump.rdb 这个二进制文件中。

RDB持久化产生的RDB文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态。

RDB 持久化提供了两种触发策略：一种是手动触发，另一种是自动触发。

手动触发是通过SAVAE命令或者BGSAVE命令将内存数据保存到磁盘文件中。

• SAVE：阻塞redis的服务器进程，直到RDB文件被创建完毕。
• BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。

自动触发策略，是指 Redis 在指定的时间内，数据发生了多少次变化时，会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中：

# 以下配置表示的条件：
# 服务器在900秒之内被修改了1次
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000

• save 900 1 表示在 900 秒内，至少更新了 1 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
• save 300 10 表示在 300 秒内，至少更新了 10 条数据，Redis 自动触 BGSAVE 命令，将数据保存到硬盘。
• save 60 10000 表示 60 秒内，至少更新了 10000 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。

优点

1.RDB是二进制压缩文件，占用空间小，便于传输（传给slaver）；

2.主进程fork子进程，可以最大化Redis性能；

3.使用RDB文件来恢复数据较快。

缺点

1、不保证数据完整性，会丢失最后一次快照以后更改的所有数据；

2、父进程在fork子进程的时候如果主进程比较大会阻塞；

AOF

AOF 被称为追加模式，或日志模式，是 Redis 提供的另一种持久化策略，它能够存储 Redis 服务器已经执行过的的命令，并且只记录对内存有过修改的命令，这种数据记录方法，被叫做“增量复制”，其默认存储文件为appendonly.aof。

具体配置可以在配置文件中进行配置：

#AOF 和 RDB 持久化方式可以同时启动并且无冲突。  
#如果AOF开启，启动redis时会加载aof文件，这些文件能够提供更好的保证。 
appendonly yes
# 只增文件的文件名称。（默认是appendonly.aof）  
# appendfilename appendonly.aof 
#redis支持三种不同的写入方式：  
#  
# no:不调用，之等待操作系统来清空缓冲区当操作系统要输出数据时。很快。  
# always: 每次更新数据都写入仅增日志文件。慢，但是最安全。
# everysec: 每秒调用一次。折中。
appendfsync everysec  
# 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入.官方文档建议如果你有特殊的情况可以配置为'yes'。但是配置为'no'是最为安全的选择。
no-appendfsync-on-rewrite no  
# 自动重写只增文件。  
# redis可以自动盲从的调用‘BGREWRITEAOF’来重写日志文件，如果日志文件增长了指定的百分比。  
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100  
# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

服务器配置中有一项appendfsync，这个配置会影响服务器多久完成一次命令的记录：

• always：将缓存区的内容总是即时写到AOF文件中。
• everysec：将缓存区的内容每隔一秒写入AOF文件中。
• no ：写入AOF文件中的操作由操作系统决定，一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。

redis默认实用的是everysec。

在RDB和AOF备份文件都有的情况下，redis会优先载入AOF备份文件

Redis 在长期运行的过程中，aof 文件会越变越长。如果机器宕机重启，“重演”整个 aof 文件会非常耗时，导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动。Redis 提供了 AOF 重写机制，手动执行BGREWRITEAOF命令，开始重写 aof 文件

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

• 新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致；
• 新的 aof 文件会使用尽可能少的命令来记录数据库数据，因此新的 aof 文件的体积会小很多；
• AOF 重写期间，服务器不会被阻塞，它可以正常处理客户端发送的命令

优点

• 更好的保护数据不丢失，性能高，可做紧恢复

缺点

• 等量级的命令，AOF持久化文件要大于RDB持久化文件
• 恢复速度慢于RDB

总结

如果进行数据恢复时，既有 dump.rdb文件，又有 appendonly.aof 文件，您应该先通过 appendonly.aof 恢复数据，这能最大程度地保证数据的安全性。