谈谈Redis持久化

前言

RDB

AOF

总结

前言

我们都知道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

总结

RDB持久化	AOF持久化
全量备份，一次保存整个数据库。	增量备份，一次只保存一个修改数据库的命令。
每次执行持久化操作的间隔时间较长。	保存的间隔默认为一秒钟（Everysec）
数据保存为二进制格式，其还原速度快。	使用文本格式还原数据，所以数据还原速度一般。
执行 SAVE 命令时会阻塞服务器，但手动或者自动触发的 BGSAVE 不会阻塞服务器	AOF持久化无论何时都不会阻塞服务器。

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