Redis持久化总结（RDB+AOF)

Redis的持久化

Redis有两种持久化的方式：快照（RDB文件）和追加文件（AOF文件）：

• RDB方式会在一个特定的间隔保存当时的数据快照；
• AOF则会记录每一个服务器收到的写命令，当服务器启动时，这些记录会逐条执行来重建出原来的数据；
• Redis的持久化可以被禁用，即可以让Redis的数据的生命周期只存在于服务器的运行时间里；
• 两种持久化方式可以同时使用，但是当Redis 重启时AOF 文件会被优先用于重建数据；

RDB

工作原理
Redis会调用 fork() 创建一个子进程，子进程把数据写入到一个临时的RDB文件，当子进程写完新的RDB文件后就会把旧的RDB文件替换掉。
优点

• RDB文件保存了某个时间点的数据，很适合用于做备份；
• 比起AOF的方式，在数据量比较大的情况下RDB 的启动速度会更快；

缺点

• RDB 比起 AOF 更容易造成数据丢失。假设每5分钟保存一次快照，如果最近一次保存快照是在19:00，但是在19:04系统出现问题，那么这四分钟内的数据将会丢失；
• RDB 使用 fork() 创建子进程进行数据持久化，如果数据比较大的话可能会花费一些时间，可能会造成 Redis 停止服务几毫秒，如果数据量很大并且 CPU 性能不是很好的时候，停止服务的时间甚至会达到1秒；

文件路径及名称
默认Redis 会把快照数据存储在当前目录下一个名为 dump.rdb 的文件中。要修改文件的存储路径和名称，可以通过修改配置文件 redis.conf 实现：

#RDB文件名，默认为 dump.rdb
dbfilename dump.rdb
#文件存放的目录，AOF文件同样存放在此目录下，默认为当前工作目录
dir ./

保存点设置（RDB的启用和禁用）
可以配置保存点来使 Redis 在每N秒后数据乳沟发生了M次改变就保存快照文件。保存点可以设置多个：

#格式为：save <seconds> <changes>，可以设置多个
save 900 1 #900秒内至少有1个key发生变动
save 900 10 #900秒内至少有10个key发生变动
save 60 100 #60秒内至少有100个key发生变动

如果想要禁用快照的功能，可以将所有save配置都注释掉或者将最后一条save配置为如下配置：

save ""

数据压缩
默认Redis会采用 LZF 算法对数据进行压缩，如果想要节省CPU 性能，那么可以把压缩功能禁用，但是这样数据文件就会比没压缩的时候大。

使用命令手动生成快照
Redis提供了两个命令用于手动生成快照：SAVE、BGSAVE。配置文件中禁用了快照生成功能不会影响SAVE和BASAVE命令的效果。

SAVE
SAVE命令会使用同步的方式生成 RDB 快照文件，这种方式会在生成快照过程中阻塞所有其他客户端的请求。

BGSAVE
BGSAVE命令使用创建子进程来生成快照的方式，调用此命令后会立刻返回 OK。Redis会创建一个子进程进行处理并立刻恢复对客户端的服务，但是如果间隔时间过长，创建子进程过程的时间可能会较长，在创建子进程的过程会阻塞服务，所以Redis的数据量越大，BGSAVE 命令导致的停顿时间越长。

AOF

工作原理
AOF方式会将每条Reids 接收到的写命令追加到 AOF 文件中，当重启Redis时，AOF文件中的命令会被重新执行一次，重建数据。
优点

• 比RDB 可靠，可以制定不同的持久化策略：不进行（让操作系统决定同步时机）、每秒进行一次同步、每个写命令都进行同步。默认是每秒同步一次，这样最多只会丢失一秒的数据；
• AOF日志文件是一个纯追加的文件，就算遇到突然停电这种意外情况也不会出现日志的定位或者损坏问题。如果因为某些原因（如磁盘满了）导致命令只写了一半到日志文件中，我们也可以使用 redis-check-aof 这个工具进行修复；
• 当AOF 文件太大时Redis 会自动在后台进行重写。

缺点
相同的数据集 AOF 文件一般会比 RDB 文件大。

启动AOF
将配置项 appendonly 设为 yes：

appendonly yes

文件路径及名称

# 文件存放目录，与RDB共用。默认为当前工作目录。
dir ./

# 默认文件名为appendonly.aof
appendfilename "appendonly.aof"

执行频率设置

# appendfsync always
appendfsync everysec
# appendfsync no