Redis-AOF、RDB具详细讲解

港控/mmm° 2023-09-25 16:51 46阅读 0赞

**目录**

Redis 日志篇：无畏宕机快速恢复的杀手锏

1.Redis怎么进行数据持久化？

2.RDB 内存快照，让宕机快速恢复

2.1RDB的说明

2.2RDB给那些数据做快照？

2.3生成 RDB 策略

2.4快照的时候数据可以被修改

2.5写时复制

2.6每秒做一次RDB快照？

2.7RDB增量快照

3.AOF 写后日志，避免宕机数据丢失

3.1AOF说明

3.2写前与写后日志对比

3.3写后日志优点

3.4.写回策略

3.5同步函数

3.6AOF优缺点分析

3.7AOF 重写机制：bgrewriteaof指令

4Redis 4.0 混合日志模型（混合使用AOF和快照）

5.Redis主线程，子进程，后台线程

总结1：

总结2：

--------------------

## Redis 日志篇：无畏宕机快速恢复的杀手锏 ##

[Redis 日志篇：无畏宕机快速恢复的杀手锏][Redis]

Redis如果宕机可以从后端数据库里恢复数据，但是会出现的问题：1:数据是从慢速数据库里获取数据，速度比不上从Redis缓存中获取。2：频繁访问数据库会给数据库造成压力

处理宕机的方法就是，将数据持久化。Redis常用作缓存，提高读取相应性能。

![29243449fa043159abf2a0c0cc4936af.png][]

## 1.Redis怎么进行数据持久化？ ##

Redis持久化有两种方法：

*  **RDB 快照（snapshot）** \- 将存在于某一时刻的所有数据都写入到硬盘中。（内存快照，设定定时间内落盘）
 *  **只追加文件（append-only file，AOF日志** **）**\- 它会在执行写命令时，将被执行的写命令复制到硬盘中。写后日志的方式记录（先执行命令，然后将数据写入内存，然后记录日志）

*  宕机了，Redis 如何避免数据丢失？

AOF通过追加的方式记录命令，避免数据丢失。但是当数据需要恢复的时候，需要逐一的执行命令，如果数据量过大的话，执行的时间就会过长，Redis恢复数据的过程缓慢，就会影响到正常的使用。AOF记录的是命令不是真实的数据。

RDB记录的是某一个时刻的数据，在Redis恢复数据的时候只需要将数据写入内存，就能恢复数据了。

## 2.RDB 内存快照，让宕机快速恢复 ##

#### 2.1RDB的说明 ####

**RDB其实就是Redis DataBase的缩写，所谓内存快照就是Redis内存中某一个时刻的数据状态。**

Redis将某一刻的数据拍下来，以文件的形式写入磁盘中。就像是拍照，记录下某一时刻的瞬间画面完全记录下来。Redis在进行写操作的时候，内存数据是一直在变化的。

#### 2.2RDB给那些数据做快照？ ####

RDB给那些数据做快照？

Redis的数据都在内存中，**为了提供所有数据的可靠性保证，它执行的是全量快照**，也就是说，把内存中的所有数据都记录到磁盘中，这就类似于给100个人拍合影，把每一个人都拍进照片里。这样做的好处是，一次性记录了所有数据，一个都不少。

当你给一个人拍照时，只用协调一个人就够了，但是，拍100人的大合影，却需要协调100个人的位置、状态，等等，这当然会更费时费力。同样，给内存的全量数据做快照，把它们全部写入磁盘也会花费很多时间。而且，全量数据越多，RDB文件就越大,往磁盘上写数据的时间开销就越大。

Redis 当作缓存使用，所以即使 Redis 没有保存全部数据，还可以通过数据库获取，所以 Redis 不会保存所有的数据， Redis 的数据持久化使用了「RDB 数据快照」的方式来实现宕机快速恢复。

Redis通过定时RDB内存快照，不必每次都执行【写】指令写入磁盘，只需要在内存快照的时候写入磁盘，既保持了速度快，又对数据进行了持久化，宕机也能快速的恢复数据。

直接将RDB数据读入内存，进行数据恢复

![15223fbc6184bcc32db5f3c3012b21ba.png][]

内存快照

#### 2.3生成 RDB 策略 ####

对于Redis而言，它的单线程模型就决定了，我们要尽量避免所有会阻塞主线程的

不会阻塞说的是：可以正常的接收请求，跟正常处理写操作不是一回事。

Redis生成RDB两方式：

*  save:主线程执行，会被阻塞。
 *  bgsave:创建一个子进程，专门用于写入RDB文件，避免了主线程的阻塞，这也是Redis生成RDB的默认设置。调用glibc的函数fork产生一个子进程用于写入RDB文件，快照持久化完全交给子进程处理，父进程继续处理客户端请求，生产RDB默认配置文件。bgsave 子进程可以共享主线程的所有内存数据，读取主线程的数据并写入到 RDB 文件。

共同：当进行save或者bgsave创建一个新的RDB文件时，程序会对数据库进行检查，已经过期的键不会被写入RDB中

#### 2.4快照的时候数据可以被修改 ####

在进行快照的时候数据可以被修改吗？

Redis在进行RDB的时候，虽然主线程没有阻塞，为了保持数据的一致性，在进行RDB的时候只能进行读操作，不能进行写操作，不能修改正在执行快照的数据。

举个例子。我们在时刻t给内存做快照，假设内存数据量是4GB，磁盘的写入带宽是0.2GB/s，简单来说，至少需要20s (4/0.2=20）才能做完。如果在时刻t+5s时，一个还没有被写入磁盘的内存数据A，被修改成了A’，那么就会破坏快照的完整性，因为A’不是时刻t时的状态。因此，和拍照类似，我们在做快照时也不希望数据“动”，也就是不能被修改。

但是，如果快照执行期间数据不能被修改，是会有潜在问题的。对于刚刚的例子来说，在做快照的20s时间里，如果这4GB的数据都不能被修改，Redis就不能处理对这些数据的写操作，那无疑就会给业务服务造成巨大的影响。

**RDB 文件生成期间能处理写操作不是一回事**

你可能会想到，可以用bgsave避免阻塞啊。这里我就要说到一个常见的误区了，避免阻塞和正常处理写操作并不是一回事。此时，主线程的确没有阻塞，可以正常接收请求，但是，为了保证快照完整性，它只能处理读操作，因为不能修改正在执行快照的数据。

解决写问题

**Redis使用操作系统的多进程写时复制技术 （COW/ copy on write ）来实现快照持久化。**

*  子进程刚刚产生时，子进程跟父进程共享内存里的所有代码段和数据段。（这是Linux内存机制，为了节省内存资源，更快的共享起来，在进程分离一瞬间，内存增长基本没有变化。）
 *  在进行快照的时候，同时进行写操作
 *  简单来说，bgsave子进程是由主线程fork生成的，可以共享主线程的所有内存数据。bgsave子进程运行后,开始读取主线程的内存数据,并把它们写入RDB文件。

当主线程执行写指令修改数据的时候，这个数据就会复制一份副本， bgsave 子进程读取这个副本数据写到 RDB 文件，所以主线程就可以直接修改原来的数据。

这样保证了快照的完整性，也允许主线程同时进行写操作，避免对正常业务的影响。

![82dd03314b2b7ddda3d984f93368529f.png][]

到这里，我们就解决了对“哪些数据做快照”以及“做快照时数据能否修改”这两大问题:Redis会使用bgsave对、当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主线程同时可以修改数据。

#### 2.5写时复制 ####

Redis在使用RDB方式进行持久化时，会用到写时复制机制。写时复制的效果: bgsave子进程相当于复制了原始数据，而主线程仍然可以修改原来的数据。

对Redis来说，主线程fork出bgsave子进程后，bgsave子进程实际是复制了主线程的页表。这些页表中，就保存了在执行bgsave命令时，主线程的所有数据块在内存中的物理地址。这样一来，bgsave子进程生成RDB时，就可以根据页表读取这些数据，再写入磁盘中。如果此时，主线程接收到了新写或修改操作，那么，主线程会使用写时复制机制。具体来说，写时复制就是指，主线程在有写操作时，才会把这个新写或修改后的数据写入到一个新的物理地址中，并修改自己的页表映射。

2.5.1写时复制底层原理

bgsave子进程复制主线程的页表以后，假如主线程需要修改虚页7里的数据，那么，主线程就需要新分配一个物理页（假设是物理页53)，然后把修改后的虚页7里的数据写到物理页53上，而虚页7里原来的数据仍然保存在物理页33上。这个时候，虚页7到物理页33的映射关系，仍然保留在bgsave子进程中。所以，bgsave子进程可以无误地把虚页7的原始数据写入RDB文件。

![969a1622021a9ae8797de241181304d1.png][]

#### 2.6每秒做一次RDB快照？ ####

快照时间越短，即使某一刻发生了宕机，上一刻的数据做了快照，损失的数据也不会太多。但是快照的间隔时间就很关键了。

在T0时刻做了一次快照，在T0+t的时刻发生了宕机，进行数据恢复成T0那么5和9的数据就无法进行恢复了

![36244663ffa4faa1507dd66163761cdb.png][]

是不是可以每秒做一次快照?毕竟，每次快照都是由bgsave子进程在后台执行，也不会阻塞主线程。

**解释：**

这种想法其实是错误的。虽然bgsave执行时不阻塞主线程，但是，如果频繁地执行全量快照，也会带来两方面的开销。

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

另一方面，bgsave子进程需要通过fork操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁fork出bgsave子进程，这就会频繁阻塞主线程了。那么，有什么其他好方法吗?

优缺点

RDB快照快速恢复数据，但是生成RDB文件频率设置的低的话就可能会出现，丢失数据过多，生成RDB文件过快的话，又会增加额外的开销。

频繁写入开销问题

1.  频繁生成RDB文件写入磁盘，会造成磁盘压力过大，会出现上一个RDB还没有处理完，下一个RDB文件写入就已经开始了，造成死循环。
2.  bgsave会调用glibc中，fork函数生成子进程，子进程会阻塞主线程，主线程内存越大，阻塞时间越长。子线程的创建本身是对主线程有阻塞的

#### 2.7RDB增量快照 ####

增量快照，所谓增量快照说的就是，做完一次快照之后，后续的快照只对修改的数据进行快照，这样可以避免每次全量快照的开销。

比如对一万条数据进行了修改，你只需要记录这一万条修改数据的信息，就需要有1万条额外的记录，进入额外的空间开销比较大。

![0e47de9630e8f9b65f53d35bb36ad6ff.png][]

## 3.AOF 写后日志，避免宕机数据丢失 ##

#### 3.1AOF说明 ####

*  AOF日志存储的是Redis服务器的顺序指令序列
 *  只记录对内存进行修改的指令
 *  append-only file（AOF）
 *  AOF主要是主线程在执行，将日志写入磁盘的过程中，如果磁盘压力太大，写入速度过慢，就会影响后续的操作。
 *  比较熟悉的是数据库写前日志，在执行操作前先把修改的数据记入日志，若发生错误了，直接恢复。但是AOF写后日志：先执行命令，写入内存，然后才记录日志。
 *  ![b4708a57d8bc12003baa8142c52f2c5a.png][]

#### 3.2写前与写后日志对比 ####

**写前日志（Write Ahead Log, WAL）：** 在实际写数据之前，将修改的数据写到日志文件中，故障恢复得以保证。（先记日志，在执行命令，不会对指令进行语法检查，所以有可能见错误的命令记录，Redis要使用日志恢复数据的话也可能会导致错误）

比如 MySQL Innodb 存储引擎 中的 redo log（重做日志）便是记录修改的数据日志，在实际修改数据前先记录修改日志在执行修改数据。

**写后日志：** 先执行「写」指令请求，将数据写入内存，再记录日志。Redis记录的每一条命令都是以文本的形式保存的。

![d8d9e2ab7fba5021b8e3a7e4a0b6e3e9.png][]

AOF 对日志的要求

Redis接收 \[set key MygeByte\]命令将数据写到内存后，Redis会按照相关格式写入到AOF文件：

*  「\*3」：表示当前指令分为三个部分，每个部分都是 「$ + 数字」开头，紧跟后面是该部分具体的「指令、键、值」。
 *  「数字」：表示这部分的命令、键、值多占用的字节大小。比如 「$3」表示这部分包含 3 个字节，也就是 「set」指令。

![dcd58e8ca63e011b20a63e10921dd03d.png][]

#### 3.3写后日志优点 ####

为什么 Redis 使用写后日志这种方式呢？

*  写后日志避免了额外的检查开销，**不需要对执行的命令进行语法检查**。如果使用写前日志的话，就需要先检查语法是否有误，否则日志记录了错误的命令，在使用日志恢复的时候就会出错。避免可能记录错误命令导致系统客户端出错的情况
 *  另外，写后才记录日志，**不会阻塞当前的「写」指令执行。**
 *  **如果刚执行完一个命令就宕机了，还没来得及记录日志，就可能会造成数据丢失的风险。如果Redis作为缓存，还可以从后端数据库里重新读入数据进行恢复，如果Redis作为数据库那么此时又没有写入日志，那么久无法进行恢复了。**
 *  **但是如果还没有记录这个写操作，宕机了，就会失去这次操作的数据,AOP避免了当前操作阻塞，但是有可能回引起下一次操作阻塞。**AOP主要是主线程在执行，将日志写入磁盘的过程中，如果磁盘压力太大，写入速度过慢，就会影响后续的操作（还没记入宕机，数据丢失，影响下一次操作。磁盘写入，数据过多压力太大，速度缓慢。）

仔细分析的话，你就会发现，这两个风险都是和AOF写回磁盘的时机相关的。这也就意味着，如果我们能够控制一个写命令执行完后AOF日志写回磁盘的时机，这两个风险就解除了。

写回机制就很有必要了。

#### 3.4.写回策略 ####

*  为了提高文件的写入效率，当用户调用 write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。
 *  若计算机出现一些失误或者异常，内存缓冲区里的写入数据会丢失。

![e078c61488e3d5c6b3914fc8994fc165.png][]

#### 3.5同步函数 ####

![193ed024cbedace2b530c87e1177edef.png][]

**可以根据系统对高性能和高可靠性的要求，来选择写回策略。**

**总结一下：想要获得高性能，就选择 No 策略；如果想要得到高可靠性保证，就选择 Always 策略；如果允许数据有一点丢失，又希望性能别受太大影响的话，那么就选择 Everysec 策略。**

![481122c892fce4aaca857b9fd2646204.png][]

#### 3.6AOF优缺点分析 ####

1：写后日志，避免了指令语法检查的开销，不会阻塞写前指令。

2：由于AOF记录的是一个个的指令，故障恢复时需要执行每一个指令，日志文件如果太大，就会影响写入的效率，而且缓慢。

但是，按照系统的性能需求选定了写回策略，并不是“高枕无忧”了。毕竟，**AOF是以文件的形式在记录接收到的所有写命令**。随着接收的写命令越来越多，AOF文件会越来越大。这也就意味着，我们一定要小心AOF文件过大带来的性能问题。

这里的“性能问题”，主要在于以下三个方面:一是，文件系统本身对文件大小有限制，无法保存过大的文件;二是，如果文件太大，之后再往里面追加命令记录的话，效率也会变低;三是，如果发生宕机，AOF中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到Redis的正常使用。

此时重写机制就很有必要了

#### 3.7AOF 重写机制：bgrewriteaof指令 ####

指令用于对 AOF 日志进行瘦身。

**重写机制：AOF重写其实就是，Redis根据数据库现状创建一个新的AOF文件，读取数据库里的所有键值对，每一个键值对用一个命令记入他的写入。比如，读取数据库键值对“testkey”:"testvalue".重写机制会记入set testkey testvalue这一条命令。当需要恢复数据的时候，执行这条命令，**

**其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。**

为什么重写机制可以让日志变小呢？

重写机制有「多变一」功能，将旧日志中的多条指令，在重写后就变成了一条指令。

AOF是以追加的方式，一个键值对被多条命令修改就回生成多条命令。重写过程是将键值对最新的状态，生成命令，一个键值对只用一条命令就行了，在日志恢复的时候，执行这条命令，就能完成这条键值对的写入。

AOF 日志是主线程写回的，AOF 重写的过程实际上后台子进程 bgrewriteaof 完成，防止阻塞主线程。

![f8ed874c579c24ee368bb51f654c8a93.png][]

![0d838c41acdd42f93cd2b3879fe23a83.png][]

当我们对一个列表先后做了6次修改操作后，列表的最后状态是\[“D”“N”\]，此时，只用LPUSHu:list “N”，“C”，"D"这一条命令就能实现该数据的恢复，这就节省了五条命令的空间。对于被修改过成百上千次的键值对来说，重写能节省的空间当然就更大了。

不过，虽然AOF重写后，日志文件会缩小，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们就要继续关注另一个问题了:重写会不会阻塞主线程?

重写会不会阻塞主线程?

3.7.1重写过程，

AOF文件写入由主线程执行，重写过程由后台子进程bgrewriteaof完成：避免阻塞主线程，但是数据库性能会下降。

**一个拷贝，两出日志**

一共出现 **两个日志，一次拷内存数据拷贝，分别是旧的 AOF 日志和新的 AOF 重写日志和 Redis 数据拷贝**。

“一个拷贝”就是指，每次执行重写时，主线程fork出后台的bgrewriteaof子进程。此时，fork会把主线程的内存拷贝一份给bgrewriteaof子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

“两处日志”又是什么呢?

因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指正在使用的AOF日志，Redis会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个AOF日志的操作仍然是齐全的，可以用于恢复。

而第二处日志，就是指新的AOF重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的AOF文件，以保证数据库最新状态的记录。此时，我们就可以用新的AOF文件替代旧文件了。

![f501ee5b777725f9bfb5633c4f522795.png][]

重写过程中接收到的写指令操作，会同时同步到AOF缓存区和AOF重写缓冲区(重写日志也保持最新操作)，等到拷贝数据的所有操作记录重写完成后，重写缓冲区记录的最新操作也会写到新的 AOF 文件中。

每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于遍历数据生成重写记录；使用两个日志保证在重写过程中，新写入的数据不会丢失，并且保持数据一致性。

![91583644c47f8043aec865c75a4584db.png][]

AOF 重写也有一个重写日志，为什么它不共享使用 AOF 本身的日志呢？

1.  一个原因是父子进程写同一个文件必然会产生竞争问题，控制竞争就意味着会影响父进程的性能。
2.  如果 AOF 重写过程中失败了，那么原本的 AOF 文件相当于被污染了，无法做恢复使用。所以 Redis AOF 重写一个新文件，重写失败的话，直接删除这个文件就好了，不会对原先的 AOF 文件产生影响。等重写完成之后，直接替换旧文件即可。(重写后是那个是缩减之后的文件，原本的文件还存在)

AOF日志重写的时候，是由bgrewriteao子进程来完成的，不用主线程参与，我们今天说的非阻塞也是指子进程的执行不阻塞主线程。但是，你觉得，这个重写过程有没有其他潜在的阻塞风险呢?如果有的话，会在哪里阻塞?

*  例如：bgrewriteaof子进程会和主线程共享内存。当主线程收到新写或修改的操作时，主线程会申请新的如果操作的是bigkey，也就是数据量大的集合类型数据，那么，主内存空间，用来保存新写或修改的数据，线程会因为申请大空间而面临阻塞风险。因为操作系统在分配内存空间时，有查找和锁的开销，这就会导致阻塞。
 *  Redis主线程fork创建bgrewriteaof子进程时，内核需要创建用于管理子进程的相关数据结构，这简称为PCB)。内核要把主线程的些数据结构在操作系统中通常叫作进程控制块(Process Control Block)PCB内容拷贝给子进程。这个创建和拷贝过程由内核执行，是会阻塞主线程的。而且，在拷贝过程中，子进程要拷贝父进程的页表，这个过程的耗时和Redis实例的内存大小有如果Redis实例内存大，页表就会关。大，fork执行时间就会长，这就会给主线程带来阻塞风险

fork子进程，fork这个瞬间一定是会阻塞主线程的 (注意，fork时并不会一次性拷贝所有内存数据给子进程，老师文章写的是拷贝所有内存数据给子进程，我个人认为是有歧义的)，fork采用操作系统提供的写实复制(Copy On Write)机制，就是为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题，但fork子进程需要拷贝进程必要的数据结构，其中有一项就是拷贝内存页表(虚拟内存和物理内存的映射索引表)，这个拷贝过程会消耗大量CPU资源，拷贝完成之前整个进程是会阻塞的，阻塞时间取决于整个实例的内存大小，实例越大，内存页表越大，fork阻塞时间越久。拷贝内存页表完成后，子进程与父进程指向相同的内存地址空间，也就是说此时虽然产生了子进程，但是并没有申请与父进程相同的内存大小

总结来说，Redis每次执行AOF重写时，都是对内存先进行一个拷贝，用于重写；然后使用两个日志来保证在重写过的过程中，数据不会丢失。而且，因为Redis的重写操作是在额外的线程是进行的，所以不会对其主线程造成阻塞。

### 4Redis 4.0 混合日志模型（混合使用AOF和快照） ###

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

**混合持久化：将RDB文件和增量AOF文件放在一起，AOF不是全量日志，而是从持久化开始到持久化结束的发生的增量AOF日志，**在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。同时AOF 只需要记录两次快照之间发生的「写」指令，不需要记录所有的操作，避免出现文件过大的情况。

Redis 4.0中提出了一个混合使用AOF日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间,使用AOF日志记录这期间的所有命令操作。

快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。

如下图所示，T1和T2时刻的修改，用AOF日志记录，等到第二次做全量快照时，就可以清空AOF日志，因为此时的修改都已经记录到快照中了,恢复时就不再用日志了。

![7bfedd0bf83c5b4b66812e0c99e1b9f9.png][]

以较小的性能开销保证数据可靠性和性能。

### 5.Redis主线程，子进程，后台线程 ###

![8eefc2b565192d1dc9a8dae7cbebff0e.png][]

从操作系统的角度来看，进程一般是指资源分配单元，例如一个进程拥有自己的堆、栈、虚存空间(页表)、文件描述符等;而线程一般是指CPU进行调度和执行的实体。

从4.0版本开始，Redis也开始使用pthread create创建线程，这些线程在创建后，一般会自行执行一些任务，例如执行异步删除任务。相对于完成主要工作的主线程来说，我们一般可以称这些线程为后台线程。

### 总结1： ###

*  数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；
 *  如果允许分钟级别的数据丢失，可以只使用 RDB；
 *  如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。

Redis 设计了 bgsave 和写时复制，尽可能避免执行快照期间对读写指令的影响，频繁快照会给磁盘带来压力以及 fork 阻塞主线程。

Redis 设计了两大杀手锏实现了宕机快速恢复，数据不丢失。

避免日志过大，提供了 AOF 重写机制，根据数据库的数据最新状态，生成数据的写操作作为新日志，并且通过后台完成不阻塞主线程。

综合 AOF 和 RDB 在 Redis 4.0 提供了新的持久化策略，混合日志模型。在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

### 总结2： ###

本节介绍了Redis用于避免数据丢失的AOF方法，这个方法通过追加的方法逐一记录指令，在恢复时逐一执行命令来恢复数据。

根据高可靠、高性能的不同提供了三种写回策略，always，everysec,no.这三种策略从高可靠性上从高到低，从高性能上从低到高。

为了避免日志文件过大，Redis提供了AOF重写机制，直接根据数据库的最新状态，生成这些数据的插入命令，作为新日志。这个过程通过后台进程完成，避免了对主线程的阻塞。

不过，你可能也注意到了，落盘时机和重写机制都是在“记日志”这一过程中发挥作用的。例如，落盘时机的选择可以避免记日志时阻塞主线程，重写可以避免日志文件过大。但是，在“用日志”的过程中，也就是使用AOF进行故障恢复时，我们仍然需要把所有的操作记录都运行一遍。再加上Redis的单线程设计，这些命令操作只能一条一条按顺序执行,这个“重放”的过程就会很慢了。

[Redis]: http://mp.weixin.qq.com/s?__biz=MzkzMDI1NjcyOQ==&mid=2247487758&idx=1&sn=beb5918bb61948b2920907f54510311f&chksm=c27c5338f50bda2ec2accd75156eb878e3150cf64d79e5d67ac38569e9dbba0f6814801aa3ab&scene=21#wechat_redirect
[29243449fa043159abf2a0c0cc4936af.png]: https://img-blog.csdnimg.cn/img_convert/29243449fa043159abf2a0c0cc4936af.png
[15223fbc6184bcc32db5f3c3012b21ba.png]: https://img-blog.csdnimg.cn/img_convert/15223fbc6184bcc32db5f3c3012b21ba.png
[82dd03314b2b7ddda3d984f93368529f.png]: https://img-blog.csdnimg.cn/img_convert/82dd03314b2b7ddda3d984f93368529f.png
[969a1622021a9ae8797de241181304d1.png]: https://img-blog.csdnimg.cn/img_convert/969a1622021a9ae8797de241181304d1.png
[36244663ffa4faa1507dd66163761cdb.png]: https://img-blog.csdnimg.cn/img_convert/36244663ffa4faa1507dd66163761cdb.png
[0e47de9630e8f9b65f53d35bb36ad6ff.png]: https://img-blog.csdnimg.cn/img_convert/0e47de9630e8f9b65f53d35bb36ad6ff.png
[b4708a57d8bc12003baa8142c52f2c5a.png]: https://img-blog.csdnimg.cn/img_convert/b4708a57d8bc12003baa8142c52f2c5a.png
[d8d9e2ab7fba5021b8e3a7e4a0b6e3e9.png]: https://img-blog.csdnimg.cn/img_convert/d8d9e2ab7fba5021b8e3a7e4a0b6e3e9.png
[dcd58e8ca63e011b20a63e10921dd03d.png]: https://img-blog.csdnimg.cn/img_convert/dcd58e8ca63e011b20a63e10921dd03d.png
[e078c61488e3d5c6b3914fc8994fc165.png]: https://img-blog.csdnimg.cn/img_convert/e078c61488e3d5c6b3914fc8994fc165.png
[193ed024cbedace2b530c87e1177edef.png]: https://img-blog.csdnimg.cn/img_convert/193ed024cbedace2b530c87e1177edef.png
[481122c892fce4aaca857b9fd2646204.png]: https://img-blog.csdnimg.cn/img_convert/481122c892fce4aaca857b9fd2646204.png
[f8ed874c579c24ee368bb51f654c8a93.png]: https://img-blog.csdnimg.cn/img_convert/f8ed874c579c24ee368bb51f654c8a93.png
[0d838c41acdd42f93cd2b3879fe23a83.png]: https://img-blog.csdnimg.cn/img_convert/0d838c41acdd42f93cd2b3879fe23a83.png
[f501ee5b777725f9bfb5633c4f522795.png]: https://img-blog.csdnimg.cn/img_convert/f501ee5b777725f9bfb5633c4f522795.png
[91583644c47f8043aec865c75a4584db.png]: https://img-blog.csdnimg.cn/img_convert/91583644c47f8043aec865c75a4584db.png
[7bfedd0bf83c5b4b66812e0c99e1b9f9.png]: https://img-blog.csdnimg.cn/img_convert/7bfedd0bf83c5b4b66812e0c99e1b9f9.png
[8eefc2b565192d1dc9a8dae7cbebff0e.png]: https://img-blog.csdnimg.cn/img_convert/8eefc2b565192d1dc9a8dae7cbebff0e.png