redis作为目前的最主流的缓存解决方案。但是有一个问题，我想大家一定都有过思考：如果服务器突发状况宕机，内存中的数据丢失了，我们该如何恢复数据？

首先我们想到的肯定是从数据库中恢复数据，但是这种方案存在两个问题：

第一，如果数据量比较大，从数据库恢复会给数据库带来很大的压力；第二，从数据库恢复数据，性能肯定比不上从redis中直接读取。因此实现数据的持久化，对于redis宕机恢复是至关重要的。

目前redis支持的持久化方式主要有两种：AOF(Append Only File)操作日志和RDB内存快照。

AOF

说道日志，我们比较熟悉的是数据库的写前日志（WRITE AHEAD LOG，WAL），也就是在实际的数据写入之前，先将需要修改的数据记录到日志文件中去，便于发生故障时，进行数据恢复。但是redis的AOF日志恰好相反，属于写后日志。具体的意思是，当redis的命令执行成功后，才将操作命令作为日志记录下来。如下图

redis为什么采用这种方式？是因为redis的日志文件里面记录的是redis执行的每一条命令。为了避免AOF文件中记录到错误的命令，同时减少命令正确性检查的开销，redis会先执行这些命令，执行成功了才向日志文件中写入命令，保证了记录的每条命令都是可以正确执行的；还有一个重要的原因是在执行命令后再记录日志，不会阻塞当前的写操作。

AOF也有两个潜在的风险：

1. 如果刚执行完一条命令，还未来得及记录日志，就宕机了，会存在数据丢失的风险。
2. AOF虽然不会阻塞当前操作，但可能会阻塞下一条命令操作，这是因为AOF也是在主线程中进行的。

针对上面的两个问题，redis提供了三种日志写回策略，也就是AOF的配置项appendfsync的三个可选值；

• always——同步写回，命令执行完成后，立即将日志写入磁盘
• everysec——每秒写回，命令执行完成后，只是先把命令写入AOF的缓冲区，每隔一秒钟，从缓冲区中将日志写入磁盘，redis默认的配置
• no——操作系统控制写回，命令执行完成后，只是先把命令写入AOF的缓冲区，具体什么时候写入磁盘由操作系统来决定

针对三种写回策略的优缺点总结如下：

可能有很多同学会有疑问，AOF文件记录的是操作命令，随着时间的推移，AOF文件肯定会越来越大，宕机恢复数据时，如果加载很大的文件，效率也是很低的？

针对这一问题，redis提供了AOF文件重写机制，具体的过程是：Redis 根据数据库的现状创建一个新的 AOF 文件。也就是读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。比如说，当读取了键值对“str:k”: “str:v”之后，重写机制会记录 set str:k str:v 这条命令。这样，当需要恢复时，可以重新执行该命令，实现“str:k”: “str:v”的写入。

与AOF日志由主线程写回不同的是，AOF重写是由后台子进程bgrewriteaof，避免了主线程的阻塞，导致性能下降。

RDB

与AOF记录操作命令不同的是，RDB（内存快照）记录的是某一时间点内存中的数据，是真实的数据。因此，通常来说RDB文件的大小肯定是小于AOF文件的。在进行数据恢复的时候我们可以直接把RDB文件读入内存，很快地完成数据的恢复。但是内存快照就一定是最优解吗？答案是不一定。因为我们还需要考虑一个问题：多久做记录快照？

当然，肯定是时间间隔越小越好，因为这样降低了数据丢失的风险。虽然说redis在做快照时执行bgsave不会阻塞主线程，但是如果频繁地执行快照，也会带来两方面的开销：

一方面是，频繁地写入磁盘数据，会给磁盘带来很大的压力，多个快照记录竞争有限的磁盘带宽，前一个还没有做完，后一个又开始了，容易造成恶性循环。

另一方面，虽然bgsave不会阻塞主线程，但是bgsave子进程需要fork操作从主线程创建出来，在fork的过程中会阻塞主线程，同时，主线程的内存越大，fork的过程就越耗时，阻塞时间越长。

总结

持久化是保证redis数据可靠性的有效手段，因此，在redis使用的过程中，做好数据的持久化，是很必要的。在redis4.0 中提出了一个同时使用AOF和RDB的方法。具体的做法是：内存快照以一定的频率执行，在两次快照之间，使用AOF记录这期间的操作命令。这样的话，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。