Redis持久化之AOF与RDB

一、AOF

因为Redis是基于内存的，所以在服务器宕机后，内存中的数据会全部丢失。

那么，如何恢复服务器中的数据，成了一个问题。所以对Redis来说，实现数据的持久化，避免从数据库的恢复数据，是至关重要的，因为从数据库中恢复数据很慢，同时也会给数据库带来很大的压力。

Redis的持久化主要有两种机制，AOF日志和RDB快照。

AOF记录的是Redis收到的每一条写命令，是人写的命令，就有可能出错，所以，Redis AOF存日志时，是先执行命令，后将命令写入日志，这样就避免的错误日志记录到AOF文件中。先执行命令后记录日志还有一个好处，就是不会阻塞当前操作，假如记录日志时，磁盘IO阻塞或者其他问题出现，写操作就会被阻塞，影响性能。

AOF日志有两种潜在风险：

• 当执行命令后，还未来及记录日志，服务器就宕机了，那么就会导致数据丢失
• 在记录日志时，如果当前操作阻塞，会影响之后来的写操作，因为记录AOF日志也在主线程中执行。

所以出现了三种写回策略：

• Always：同步写回，每个写命令执行完，立马同步的将日志写回磁盘
• Everysec：每秒写回，每个写命令执行完，先把日志写到AOF文件的内存缓冲区，每隔一秒写入磁盘
• No：操作系统控制的写回。

三种写回策略，性能从低到高，可靠性从高到低，根据业务需求选择合适的写回策略。可以在配置文件redis.conf中配置

如果AOF文件过大，在恢复过程中，是非常缓慢的，Redis为了解决这个问题，使用了AOF重写机制

AOF重写机制，就是将原有的AOF日志中的操作，简化成最后结果的操作，例如set k1 v1 ,之后又对k1做了多次改动，最后一次是set k1 v10，那么新的AOF日志就会直接简化成set k1 v10，省掉了中间的修改步骤，简化了操作。同时，AOF重写日志不太会影响主线程，在进行重写操作时，主线程会fork出后台的bgrewriteaof字进程，此时，fork会把主线程的内存拷贝一份给bgrewriteaof子进程。

二、RDB内存快照

AOF的缺点是如果AOF日志非常多，Redis的恢复就会很慢，影响到正常的使用。那么RDB内存快照就出来了，既保证可靠性，还能在宕机时实现快速恢复。

内存快照，通俗来讲，就是把某一时刻的数据以文件的形式写到磁盘上。

内存快照有全量快照，增量快照，在Redis4.0后采用了混合使用AOF日志和RDB内存快照的方法。

Redis提供了两个命令来生成RDB文件，分别是save和bgsave，bgsave是主线程fork出来的子进程，不影响redis线程的读写操作，但是fork是需要时间的，所以当数据量过大时，fork时间也会增加，所以如果进行频繁的全量快照，必然会影响redis的性能，同时还会增加磁盘的压力。这时，出现了增量快照，增量快照是在做完全量快照后，增量快照只记录新的写操作后的值，然后把被修改的数据写入快照文件就行了。但是如果每个键值对的修改都做记录，当修改的数量过大时，额外的空间开销就会很大，对redis这种内存资源宝贵的nosql来说，有点得不偿失。

所以这时候提出了混合使用AOF日志和内存快照的办法。这种方法是在两次全量快照之间采用AOF日志来记录，当下一次全量快照完成后清空AOF日志。

最后对于AOF和RDB的选择：

数据不能丢失时，RDB和AOF混合使用是一个很好地选择

允许数据分钟级别丢失时，可以单独使用RDB

只使用AOF时，everysec是一个很好地选择，其在性能和可靠性上做出了平衡。