Redis数据持久化

redis一共提供了两种数据持久化的方式RDB和AOF。

RDB

RDB全称为Redis Database Backup file（数据备份文件），也被叫做Redis数据快照。简单来说就是将内存中的全部数据都记录到磁盘中，当redis发生宕机或是一些故障导致实例故障重启，此时就会从磁盘中读取快照文件，恢复数据。

快照持久化是 Redis 默认采用的持久化方式，在 redis.conf 配置文件中默认有此下配置：

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发bgsave命令创建快照。
save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发bgsave命令创建快照。
save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发bgsave命令创建快照。

RDB的执行原理

bgsave会fork主进程得到子进程（主要复制的是主线程中的页表：记录着虚拟地址与物理地址的映射关系）子进程共享主进程的内存数据，完成fork后读取内存数据并写入RDB文件。

其中fork采用的是copy on write技术：

当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据进行写操作。

AOF

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

aof默认是关闭的，需要更改redis.conf文件来进行配置。

aof记录频率也可以通过redis.conf进行配置。

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

因为aof是记录命令。aop文件要比rdb大的多，而且aof会对记录中的一个key进行多测更改操作，但是只有最后一次的更改才有意义。可以通过bgrewriteaof命令对aof文件进行重写，使其用最少的命令达到最优的效果。

Redis也可以在redis.conf中进行自动配置，当aop中的据在某段时间达到某个阈值就会自动进行重写。

RDB和AOf对比

他们在实际应用中各有其优缺点，在Redis6.0之后两个配合使用。

	RDB	AOF
持久化方式	定时对整个内存进行快照	记录每一次的执行命令
数据完整性	不完整，在定时快照期间数据会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件相对较小	记录命令所以文件很大
宕机恢复速度	快	慢
数据恢复优先级	低，因为完整度不比AOF	高，完整度高
系统资源占用	高，其中fork等操作对内存和CPU会有一定的消耗	低，主要是硬盘的io操作，进行命令重写时会占用CPU资源
使用场景	可以容忍数分钟的数据丢失情况（偏向于高可用性）	对数据安全性要求较高的情况（对数据一致性要求高）

总结

RDB和AOF两种数据持久化操作的区别有哪些？

rdb时一个快照文件，它是将redis的数据都存储在硬盘中，当redis故障宕机后，方便从快照文件中恢复数据。

aof时一个追加文件（类似于一个日志文件），他是用来记录对数据的写命令操作，当redis宕机时，会重修执行一遍这个文件，从而恢复数据。

这两种持久化操作哪个的恢复速度比较快呢？

引文RDB是一个二进制文件，在保存的时候体积比较小，所以他若是用它进行数据恢复，数据恢复速度很快，但是他数据的完整性不高，在快照期间会数据丢失。AOF虽然恢复的速度相较于RDB慢，但是由于它可以配置刷盘策略，从而他的数据完整性较高。