Redis 持久化

在Redis宕机之后，可以从后端数据库中恢复缓存数据，但这种方式存在明显的问题，一是需要频繁访问数据库，给数据库造成巨大压力；二是从数据库中读取，性能明显慢于从Redis中读取，导致使用这些数据的应用程序变慢。所以，对Redis来说，实现数据的持久化，避免宕机后从后端数据库中恢复，是至关重要的，这是Redis高可用中的尽量保持数据完整性。
目前Redis的持久化主要有两种方式，AOF（Append Only File）日志和RDB(Redis DataBase)快照。

AOF命令日志

与MySQL的WAl写前日志不同，Redis中是写后日志，先在内存之中更新数据，然后再记录日志（收到的命令，如 set testKey testValue）。写后日志的好处：

一是不会阻塞当前更新操作，命令执行后直接返回。
二是避免了对这些命令进行语法检查的开销，因为能够执行，那肯定没得问题。

当然这种方式，也存在缺陷：

一是写AOF日志是在主线程中进行的，将日志文件写到磁盘中时，磁盘IO较慢，可能阻塞后续的请求（通过写回策略可做调整）。AOF配置项appendfsync存在三个可选值:
二是随着时间的推移，AOF日志会越来越大，在宕机后恢复需要很多时间，影响使用。（通过日志重写可减小文件大小）。
aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写, 100即当前AOF文件为上一次AOF文件的两倍。auto-aof-rewrite-percentage 100
设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。 auto-aof-rewrite-min-size 64mb

AOF重写

AOF重写不在主线程中进行，而是在后台子进程bgrewriteaof中进行，步骤为：

fork主线程内存拷贝一份bgrewriteaof子进程（内存过大时可能造成阻塞），这部分内存便包括了数据库最新数据。
如果这时有新的写操作，对应的日志会被存储在AOF缓冲区和AOF重写缓冲区，重写会执行重写缓冲区中的日志。
重写完成后，替换旧的AOF文件，再将重写期间的AOF日志写入新的AOF文件。

RDB内存快照

将某一刻的Redis内存数据以二进制压缩文件的形式存储到磁盘中，也就是快照文件，为Redis 5.0之前的默认持久化策略。在宕机重启后，加载快照文件就能很快完成数据恢复。Redis提供两个命令来生成RDB文件：

save：在主线程中生成，会导致阻塞
bgsave：创建一个子进程，专门用于RDB文件的写入，可避免主线程的阻塞，为默认配置。

Redis默认的生成RDB频率为：
900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
save 900 1
save 300 10
save 60 10000

写入快照时进行数据修改

在以gbsave方式生成RDB文件过程中，Redis同样需要处理写操作。利用LInux的COW（Copy On Write）写时复制技术
，bgsave进程在生成快照的同时会同步主线程的更改。这样既保证了快照的完整性也允许主线程可以同时更改数据。

RDB快照频率

在两次快照之间，Redis如果发生宕机，这期间的数据会被丢失。为了避免这种情况，将快照频率提高可以解决这种问题，但是频繁生成RDB会有巨大开销：

一是，fork子进程bgsave这个过程就会阻塞主线程，内存越大，阻塞时间越长。
二是，执行RDB对磁盘压力很大。

AOF + RDB

在Redis 4.0中增加了一种混合使用AOF加RDB的方法，RDB以一定的频率执行，而在两次执行的间隙期间，使用AOF记录更新。在做第二次全量全照时，便可以将AOF日志文件清空。在宕机后恢复过程中，先加载RDB文件进行恢复，再执行AOF文件。这种方式兼顾了性能、数据完整性，在Redis 5.0之后已经成为了默认的持久化方式，配置为aof-use-rdb-preamble yes。