一、RDB方式

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。和AOF相比，它记录的是某一时刻的数据，并不是操作。

1.1、RDB手动

save：手动执行一次

save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

bgsave：手动启动后台保存操作，但不是立即执行。

bgsave工作原理：

bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

1.2、RDB自动

save second changes

满足限定时间范围内key的变化数量达到指定数量即进行持久化。

1.3、优缺点

优点：与AOF相比，恢复大数据集的时候会更快，它适合大规模的数据恢复场景，如备份，全量复制等。
缺点：没办法做到实时持久化/秒级持久化。

二、AOF方式

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的；与RDB相比可以简单描述为改记录数据为记录数据产生的过程AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

简单来说就是AOF就是采用日志的形式来记录每个写操作，追加到AOF文件的末尾。

2.1、AOF写数据三种策略

always(每次）：每次写入操作均同步到AOF文件中，数据零误差，性能较低。

everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高在系统突然宕机的情况下丢失1秒内的数据。

no（系统控制）：由操作系统控制每次同步到AOF文件的周期，整体过程不可控。

如果接受的命令越来越多，AOF文件也会越来越大，文件过大还是会带来性能问题。日志文件过大怎么办呢？那我们来看AOF重写机制。

2.2、AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写的作用：

降低磁盘占用量，提高磁盘利用率提高持久化效率，降低持久化写时间，提高IO性能降低数据恢复用时，提高数据恢复效率。

2.3、优缺点

优点：数据的一致性和完整性更高，秒级数据丢失。
缺点：相同的数据集，AOF文件体积大于RDB文件。数据恢复也比较慢。

三、AOF和RDB对比

|------------|-----------|-----------|
| 持久化方式 | RDB | AOF |
| 占用存储空间 | 小（数据级：压缩） | 大（指令级：重写） |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢失数据 | 依据策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |

总结：

如果数据不能丢失，RDB和AOF混用。

如果只作为缓存使用，可以承受几分钟的数据丢失的话，可以只使用RDB。

如果只使用AOF，优先使用everysec的写回策略。

Redis持久化机制

为什么Redis会有持久化机制：