AOF和RDB【Redis持久化篇】

1.什么是持久化？

Redis是跑在内存里的，当程序重启或者服务器崩溃，数据就会丢失，如果业务场景希望重启之后数据还在，就需要持久化，即把数据保存到可永久保存的存储设备中。

那要怎么存储呢？

Redis提供了两种方式：

• RDB（Redis Database Backup），记录Redis某个时刻的全部数据，这种方式本质就是数据快照，直接保存二进制数据到磁盘，后续通过加载RDB文件恢复数据。
• AOF（Append Only File），记录执行的能造成数据变化的写命令，重启之后通过重放命令来恢复数据，AOF本质是记录操作日志，后续通过日志重放恢复数据。

思考一下这几个问题？
1、Redis为什么需要持久化？
是为了在服务器重启或异常情况下，能够保留并恢复数据。
（ps：那怎么保存呢？）
Redis提供了RDB快照方式保存二进制数据到磁盘，以及AOF方式记录写命令，用来后续重放写命令恢复数据。
（ps：它俩有什么区别呢？）
RDB是通过快照生成的是二进制文件，AOF是记录写命令操作日志的文本文件。RDB的恢复数据的速度比AOF的快，但是RDB容易丢失较多的数据，而且RDB每次快照都是全量保存。
（ps：你会用哪个方式？）
如果业务场景能接受分钟级别的数据丢失，我会选择RDB，这也是推荐的一种方式。

2、同时开启AOF和RDB，启动时加载那个？

有AOF只会用AOF。

2.RDB

RDB本质是什么？

是二进制形式的快照。
（ps：RDB怎么触发？）
RDB可以通过配置定时触发，触发时用的是后台持久化方式。也可以用save命令、bgsave命令主动触发，save底层用的是阻塞式持久化，bgsave用的后台持久化。如果Redis正常关闭，会执行阻塞式持久化。
（ps：RDB执行过程？）
首先，Fork出一个子进程来做RDB持久化；然后，子进程写数据到临时的RDB文件；最后，用新RDB文件替换旧的RDB文件。

3.AOF

1、AOF重写解决什么问题？

重写是用于解决AOF不断膨胀问题，随着命令越来越多，AOF文件越来越大，但是很多数据不一定是由意义的。重写就是通过当前状态，重新生成最新的AOF操作命令记录的过程。重写之后无效的命令会减少，AOF重放时无意义的操作会减少，耗时更短。

2、AOF重写流程？
（一次拷贝，两处缓冲。）主进程在 AOF 重写期间 fork 出子进程，通过写时复制共享内存生成新的 AOF 文件，同时主进程将新的写入命令分别写入 AOF 缓冲（保证旧文件完整性）和 AOF 重写缓冲（同步子进程生成的新文件），以确保数据不丢失。

混合持久化

混合持久化其实是在AOF重写阶段，将当前状态保存为RDB二进制内容，写入新的AOF文件，再将重写缓冲区的内容追加到新的AOF文件，最后代替原有的AOF文件。（AOF文件就是二进制数据+日志数据的混合体）

混合持久化的出现与常规的AOF重写是一致的，更好的解决了AOF文件太大的问题，从文件恢复数据会快一点。

5.0之后，只要开启AOF配置，默认就是混合持久化。