Redis持久化方案 RDB，AOF

前言

Redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化，也是保证redis的稳定性，防止意外发生数据恢复问题。
参考文章

RDB（Redis DataBase）

RDB持久化是在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。在我们安装了Redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置。当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

优点

1. 压缩文件体积小
2. 加载RDB文件恢复快

缺点

1. 实时性不够，容易丢失数据，如果数据相对重要建议使用AOF
2. 通过bgsave进行备份时，需要fork一个子线程，频繁执行性能成本高

触发时机

我们可以通过redis.conf配置文件配置触发的条件，还可以通过指令主动触发持久化的过程。

配置文件中配置触发规则

save 900 1

save 300 10

save 60 10000

配置解释：

900秒内，如果超过1个key被修改，则发起快照保存

300秒内，如果超过10个key被修改，则发起快照保存

60秒内，如果1万个key被修改，则发起快照保存

---- 可以自己修改成合适的数值

除了通过配置文件配置触发规则，也可以通过命令主动触发。

1）save：sava指令会阻塞Redis的主线程，所以一定要谨慎使用

2）bgsave：bg其实就是 background，表示后台的，所以bgsave可以理解为后台进行持久化操作，不会阻塞Redis的主进程。当执行这个命令的时候，Redis会fork出一个子进程，子进程在后台默默运行，不会阻塞主进程，这也是Redis默认使用的方式。

3）执行flushall命令也会生成dump.rdb文件，但是里面是空的。

4）客户端执行shutdown关闭Redis时，也会触发快照。

AOF

全量备份总是耗时的，Redis为我们提供了一种更加高效的持久化方式，即AOF（appendonlyfile）。此方式工作机制很简单，Redis会将每一个收到的写命令都通过write函数追加到文件中。默认情况下Redis没有开启AOF方式的持久化。

开启AOF持久化后，每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。

AOF是写后日志，即redis执行完成才会写入AOF保证了AOF中命令的正确性

AOF 保存模式

Redis目前支持三种AOF保存模式，它们分别是：不保存、每秒钟保存一次、每执行一个命令保存一次。

可以修改以下配置项配置AOF的保存模式。

appendfsync always

appendfsync everyse

AOF_FSYNC_NO（不保存）：在这种模式下，每次调用ushAppendOnlyFile函数，WRITE都会被执行，但SAVE会被略过。在这种模式下，SAVE只会在以下情况中被执行：1.Redis被关闭；2.AOF功能被关闭；3.系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行）。这三种情况下的SAVE操作都会引起Redis主进程阻塞。

AOF_FSYNC_EVERYSEC（每一秒钟保存一次）：在这种模式中，SAVE原则上每隔一秒钟就会执行一次，因为SAVE操作是由后台子线程调用的，所以它不会引起服务器主进程阻塞。

AOF_FSYNC_ALWAYS（每执行一个命令保存一次（不推荐））：在这种模式下，每次执行完一个命令之后，WRITE和SAVE都会被执行。另外，因为SAVE是由Redis主进程执行的，所以在SAVE执行期间，主进程会被阻塞，不能接受命令请求。

AOF保存模式对性能和安全性的影响

对于三种AOF保存模式，它们对服务器主进程的阻塞情况如下：

AOF_FSYNC_NO：写入和保存都由主进程执行，两个操作都会阻塞主进程。

AOF_FSYNC_EVERYSEC：写入操作由主进程执行，阻塞主进程。保存操作由子线程执行，不直接阻塞主进程，但保存操作完成的快慢会影响写入操作的阻塞时长。

AOF_FSYNC_ALWAYS：和AOF_FSYNC_NO模式一样。

因为阻塞操作会让Redis主进程无法持续处理请求，所以一般说来，阻塞操作执行得越少，完成得越快，Redis的性能就越好。