高薪Offer收割机之Redis的数据持久化

Redis的数据持久化有两种方式：RDB和AOF

先来看第一种方式RDB持久化：

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照，简单的说就是把内存中所有的数据都记录到磁盘中，当Redis服务器重启以后，从磁盘中读取文件恢复内存中的数据。

有两个命令可以完成RDB持久化：

save:表示由主进程来执行数据备份命令，在主进程执行备份期间会阻塞所有其它命令,因此效率较低。

bgsave：会开启一个子进程来执行数据备份，在进行数据备份的同时还能执行其它命令。

除了可以使用这两个命令进行主动的数据备份以外在Redis的配置文件redis.conf中还可以配置触发RDB数据备份的机制，格式如下：

第一行配置save 900 1表示 900秒内，如果至少有一个key的值被修改则执行bgsave

第二行配置save 300 10表示300秒内，如果至少有10个key的值被修改则执行bgsave

第三行配置save 60 10000表示60秒内，如果至少有10000个key的值被修改则执行bgsae

第二种持久化的方式:AOF

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件， Redis服务器重启以后只需要将AOF文件中的指令全部重新执行一遍就可以恢复内存中的数据。

AOF默认是关闭的，需要在配置文件redis.conf中开启：

# 是否开启AOF功能，默认是no

appendonly yes

# AOF文件的名称

appendfilename "appendonly.aof"

AOF命令记录的频率也可以在redis.conf中配置：

# 表示每执行一次写命令，立即记录到AOF文件

appendfsync always

# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案

appendfsynceverysec

# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

appendfsync no

appendfsync always ：表示每执行一次写命令就写入AOF文件中，在这种配置下可靠性是最高的，几乎不会丢数据，但是因为需要频繁的写入对性能影响很大，一般不采用。

appendfsynceverysec：表示写命令执行完先放入缓冲区，每隔一秒钟将缓冲区中的命令写入AOF文件中，这种是默认方案，这种方案会丢失一秒钟的数据，性能适中。

appendfsync no：表示写命令执行完先放入缓冲区，操作系统决定何时将缓冲区中的数据写入AOF文件，此种方案可能丢失大量数据但是性能最好。

因为RDB记录的是二进制的文件而AOF记录的是命令，所以AOF文件比RDB文件大很多，而且对一个key的多次写操作AOF文件也会记录，但实际上只有最后一次写操作才是有意义的。

比如执行：

setnum 123

set name jack

setnum 666

这里对num进行了两次写操作，其最终结果应该为666，因此将set num 123记录到AOF文件中就属多余。

我们可以执行执行bgrewriteaof命令，让AOF文件执行重写功能，重写以后会只保留对一个key的最后一次写操作，该命令还可以将多条命令合并，用最少的命令达到相同的效果。

也可以在redis.conf文件中配置通过阈值触发AOF文件重写。

# AOF文件比上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb

RDB和AOF对比：

通过RDB和AOF两种持久化方式的对比，我们发现这两种方式各有优缺点。在生产环境中一般是同时使用这两种持久化的方式。

192