主要内容

Redis持久化的两种方式

Redis提供了两种类型的持久化方式，分别是快照方式(RDB)和只追加文件(AOF)的方式

RDB在指定的间隔内抓取内存中特定时间点的数据快照，然后保存到磁盘中
AOF把服务器所有写操作命令都记录到文件中去，下次服务器启动的时候，读取该文件中的命令进行回放，从而还原数据到内存中去。
当服务器同时开启RDB和AOF持久化的时候，优先使用AOF还原数据

RDB的优势

RDB是一个高压缩的文件，它的结构和Redis在内存的时候保持一致，因此恢复速度非常快，适合用于数据的备份
由于RDB是一个单文件，因此适合于在服务器间传输，例如用于灾难恢复。
当需要生成RDB文件的时候，Redis服务器会fork一个进程，专门处理RDB文件，父进程不参与RDB的生成过程。
相比起AOF，RDB运行服务器的快速重启

RDB的缺点

当Redis在RDB产生的两个时间点之间发生故障，那么这个时间段的数据会丢失
为了生成RDB数据文件，Redis可能需要频繁fork进程，当数据量非常大的时候，那是很耗时的，可能会造成Redis服务性能低下甚至拒绝服务，虽然AOF也会fork进程，但是我们可以调整AOF的fork频率

AOF的优势

我们可以根据实际需要调整AOF的同步策略，例如总是同步，或每秒同步等等
由于每一个操作都会被写入到AOF中，因此丢失数据的可能性比较少。
即使你运行了flushall命令，但只要AOF还没有被重写，我们依然可以从AOF中恢复数据。因为AOF文件是普通文本文件（类似mysql的binlog），只要删除AOF中最后的flushall命令，然后重启Redis即可。

AOF的缺点

由于所有的写命令都会被保存到AOF中，因此它的大小通常比RDB文件要大得多，虽然可以通过重写压缩
AOF还原的时候需要重复执行一次命令，因此还原数据所需的时间会比RDB慢

混合使用RDB和AOF确保数据安全

虽然AOF似乎可以满足数据安全，但是它可能存在一些潜在的bug，导致一些数据丢失，虽然这种情况很少遇到。即使真的遇到问题，如果使用RDB的话，还可以从RDB文件中恢复，因此应该混合使用RDB和AOF确保数据安全最大化。

配置RDB

Redis默认开启了RDB，且配置了三个保存周期，分别是

save 900 1

save 300 10

save 60 10000

这三个save的意思如下：

900秒内有1条更新，刷新rdb文件
300秒内有10条更新，刷新rdb文件
60秒内如果有10000条更新，刷新rdb文件

其他的相关配置如下：

#当保存rdb文件失败的时候不再接收写入操作

stop-writes-on-bgsave-error yes

#压缩rdb文件中的字符串对象

rdbcompression yes

#是否开启rdb文件的指纹检查

rdbchecksum yes

#rdb文件的保存路径

dir /var/lib/redis

#rdb文件的名称

dbfilename dump.rdb

配置AOF

Redis默认没有开启aof，需要手动打开。默认aof的文件保存目录和rdb文件目录一致，aof常用配置如下

# 开启aof，默认值是no

appendonly yes

#aof文件的名称

appendfilename "appendonly.aof"

# appendfsync always

appendfsync everysec #默认每秒更新一次aof文件

# appendfsync no

# 重写aof文件的时候不对后续的写操作追加到文件，而是保存到缓冲区，等aof文件重写完毕再把缓冲区的数据写入aof

no-appendfsync-on-rewrite no

# 当aof递增率达到100%时重写aof

auto-aof-rewrite-percentage 100

# 当aof文件达到64mb的时候才进行aof重写

auto-aof-rewrite-min-size 64mb

其中auto-aof-rewrite-min-size是对auto-aof-rewrite-percentage的补充，如果没有这个选项，前期Redis数据量小的时候很容易就造成100%递增率，例如开始数据是1条，当数据到第2条的时候就是一个100%递增，第4条就是第二个100%递增，以此类推，后果是aof的频繁更新，影响服务器性能。