背景

Redis一般被当作缓存类型使用，一旦服务器宕机，内存中的数据将全部丢失。如果从Redis出现问题时就需要频繁访问数据库，会给数据库带来巨大的压力;这些数据是从慢速数据库中读取出来的，性能肯定比不上从 Redis 中读取，导致使用这些数据的应用程序响应变慢。

Redis持久化方式

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

AOF:

类似于数据库中的BinLog存放的是逻辑日志（Redo是记录的为物理日志，对某个页的具体操作），即Redis接受到的命令按照文本类型保存。数据库大多数都是日志先行即WAL（Write Ahead Log），但Redis的AOF日志正好相反，先执行命令再写后日志。
Redis 在向 AOF里面记录日志的时候，并不会先去对命令进行语法检查。如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时就可能会出错。
而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功才会被记录到日志中，否则系统就会直接向客户端报错。所以Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。并且它是在命令执行后才记录日志，所以不会阻塞当前的写操作。

AOF潜在的风险

如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。
AOF虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。因为AOF日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。
这两个风险都是和 AOF 写回磁盘的时机相关的。这也就意味着，如果我们能够控制一个写命令执行完后 AOF日志写回磁盘的时机，这两个风险就解除了。

AOF刷盘策略

策略配置.png

Always，同步写回:每个写命令执行完，立马同步地将日志写回磁盘;
Everysec，每秒写回:每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘;
No，操作系统控制的写回:每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

AOF重写机制

AOF是以文件的形式在记录接收到的所有写命令。随着接收的写命令越来越多，AOF 文件会越来越大。这也就意味着，我们一定要小心 AOF 文件过大带来的性能问题。
一：文件系统本身对文件大小有限制，无法保存过大的文件;
二：如果文件太大，之后再往里面追加命令记录的话，效率也会变低
三：如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用。
重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。
重写过程是由后台线程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。

RDB:

SAVE:在主线程中执行，会导致阻塞;
BGSAVE:创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是Redis RDB 文件生成的默认配置。
注意：避免阻塞和正常处理写操作并不是一回事。BGSAVE时，主线程的确没有阻塞，可以正常接收请求，但是为了保证快照完整性，它只能处理读操作因为不能修改正在执行快照的数据,为了快照而暂停写操作，肯定是不能接受的。所以这个时候，Redis 就会借助操作系统提供的写时复制技术(Copy-On-Write, COW)，在执行快照的同时正常处理写操作也允许主线程同时对数据进行修改，避免了对正常业务的影
响。（如果写的请求过多会导致内存增长）

写时复制机制.png

BGSAVE频繁备份的问题：
一、频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。
二、bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大阻塞时间越长。如果频繁 fork出bgsave 子进程，这就会频繁阻塞主线程了。