一、前述

持久化概念：将数据从掉电易失的内存存放到能够永久存储的设备上。

Redis持久化方式

RDB（Redis DB） hdfs: fsimage

AOF（AppendOnlyFile） hdfs : edit logs 默认关闭的

二、RDB方式

在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中

在RDB方式下，有两种方式：

1、一种是手动执行持久化数据命令来让redis进行一次数据快照，而手动执行持久化命令，你依然有两种选择，那就是save命令和bgsave命令。

save:

客户端手动执行SAVE命令

redis > save

阻塞Redis服务，无法响应客户端请求

创建新的dump.rdb替代旧文件

bgsave:是一个异步命令

redis > bgsave

非阻塞，Redis服务正常接收处理客户端请求

Redis会fork()一个新的子进程来创建RDB文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕

父进程用新的dump.rdb替代旧文件

注意：

Fork发生时，父子进程内存共享，所以为了不影响子进程做数据快照，在这期间修改的数据，将会被复制一份，而不进共享内存。所以说，RDB所持久化的数据，是Fork发生时的数据。在这样的条件下进行持久化数据，如果因为某些情况宕机，则会丢失一段时间的数据。如果你的实际情况对数据丢失没那么敏感，丢失的也可以从传统数据库中获取或者说丢失部分也无所谓，那么你可以选择RDB持久化方式。

比较：

SAVE 和 BGSAVE 命令

SAVE不用创建新的进程，速度略快

BGSAVE需要创建子进程，消耗额外的内存

SAVE适合停机维护，服务低谷时段

BGSAVE适合线上执行

2、另一种则是根据你所配置的配置文件 的 策略，达到策略的某些条件时来自动持久化数据。和bgsave执行原理相同

这是配置文件默认的策略，他们之间的关系是或，每隔900秒，在这期间变化了至少一个键值，做快照。或者每三百秒，变化了十个键值做快照。或者每六十秒，变化了至少一万个键值，做快照。

三、AOF方式

ppend only file，采用追加的方式保存

默认文件appendonly.aof

记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库

调整AOF持久化策略，可以在服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于RDB损失小得多

1、AOF写入机制（但事实上，并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存，在接下来的策略中，配置多久来从硬盘缓存写入到硬盘文件。所以在一定程度一定条件下，还是会有数据丢失，不过你可以大大减少数据损失。）

AOF方式不能保证绝对不丢失数据

目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

2、写入磁盘的策略（这里是配置AOF持久化的策略。redis默认使用everysec，就是说每秒持久化一次，而always则是每次操作都会立即写入aof文件中。而no则是不主动进行同步操作，是默认30s一次。当然always一定是效率最低的，everysec就够用了，数据安全性能又高。）

appendfsync选项，这个选项的值可以是always、everysec或者no

Always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据

Everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据

No：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的

运行速度：always的速度慢，everysec和no都很快

3、AOF重写机制

AOF有序的记录了redis的命令操作。意外情况下数据丢失甚少。他不断地对aof文件添加操作日志记录，你可能会说，这样的文件得多么庞大呀。是的，的确会变得庞大，但redis会有优化的策略，比如你对一个key1键的操作，set key1 001 , set key1 002, set key1 003。那优化的结果就是将前两条去掉咯，那具体优化的配置在配置文件中对应的是

前者是指超过上一次aof重写aof文件大小的百分之多少，会再次优化，如果没有重写过，则以启动时为主。后者是限制了允许重写的最小aof文件大小。bgrewriteaof命令是手动重写命令，会fork子进程，在临时文件中重建数据库状态，对原aof无任何影响，当重建旧的状态后，也会把fork发生后的一段时间内的数据一并追加到临时文件，最后替换原有aof文件，新的命令继续向新的aof文件中追加。

AOF文件过大

合并重复的操作，AOF会使用尽可能少的命令来记录

重写过程

fork一个子进程负责重写AOF文件

子进程会创建一个临时文件写入AOF信息

父进程会开辟一个内存缓冲区接收新的写命令

子进程重写完成后，父进程会获得一个信号，将父进程接收到的新的写操作由子进程写入到临时文件中

新文件替代旧文件

注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

AOF重写触发

手动：客户端向服务器发送BGREWRITEAOF命令

自动：配置文件中的选项，自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size <size>，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写

auto-aof-rewrite-percentage <percent>，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写

AOF重写配置项举例

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

appendonly no / yes

当AOF文件大于64MB时候，可以考虑重写AOF文件

只有当AOF文件的增量大于起始size的100%时（就是文件大小翻了一倍），启动重写

默认关闭，请开启

四、Rdb和AOF比较

1、RDB：

优点：

完全备份，不同时间的数据集备份可以做到多版本恢复

紧凑的单一文件，方便网络传输，适合灾难恢复

恢复大数据集速度较AOF快

缺点：

会丢失最近写入、修改的而未能持久化的数据

fork过程非常耗时，会造成毫秒级不能响应客户端请求

2、AOF

优点

写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据

重写机制，优化AOF文件

如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态

缺点

相同数据集，AOF文件体积较RDB大了很多

恢复数据库速度较RDB慢（文本，命令重演）

喜欢的话，转发一下，点个关注吧！