前语

假如有人问你：”你会把 Redis 用在什么业务场景下？”

我想你大概率会说：”我会把它当作缓存运用，由于它把后端数据库中的数据存储在内存中，然后直接从内存中读取数据，响应速度会十分快。”

没错，这确实是 Redis 的一个普遍运用场景，可是，这儿也有一个肯定不能疏忽的问题：一旦服务器宕机，内存中的数据将悉数丢掉。

目前，Redis 的持久化首要有两大机制，即 AOF（Append Only File）日志和 RDB（Redis DataBase） 快照。

AOF

日志是如何实现的

说到日志，咱们比较了解的是数据库的写前日志（Write Ahead Log, WAL），在实践写数据前，先把修正的数据记到日志文件中，以便毛病时进行康复。不过，AOF 日志正好相反，它是写后日志，”写后”的意思是 Redis 是先履行指令，把数据写入内存，然后才记载日志。

image.png

AOF 里记载的是 Redis 收到的每一条指令，这些指令是以文本方法保存的。

咱们以 Redis 收到“set testkey testvalue”指令后记载的日志为例，看看 AOF 日志的内容。其中，“*3”表明当时指令有三个部分，每部分都是由“$+数字”最初，后边紧跟着详细的指令、键或值。这儿，“数字”表明这部分中的指令、键或值一共有多少字节。例如，“$3 set”表明这部分有 3 个字节，也便是“set”指令。

image.png

写后日志的优势与危险

为了防止额外的检查开支，Redis 在向 AOF 里边记载日志的时候，并不会先去对这些指令进行语法检查。

假如先记日志再履行指令的话，日志中就有或许记载了过错的指令，Redis 在运用日志康复数据时，就或许会出错。而写后日志这种方法，便是先让体系履行指令，只有指令能履行成功，才会被记载到日志中，不然，体系就会直接向客户端报错。

所以，Redis 运用写后日志这一方法的一大优点是，能够防止呈现记载过错指令的情况。

除此之外，写后日志一个优点：它是在指令履行后才记载日志，不会堵塞当时的写操作。

AOF 也有两个潜在的危险：

  • 危险一：假如刚履行完一个指令，还没有来得及记日志就宕机了，那么这个指令和相应的数据就有丢掉的危险。
    • 假如此刻 Redis 是用作缓存，还能够从后端数据库从头读入数据进行康复。
    • 假如 Redis 是直接用作数据库的话，此刻，由于指令没有记入日志，所以就无法用日志进行康复了。
  • 危险二：AOF 尽管防止了对当时指令的堵塞，但或许会给下一个操作带来堵塞危险。
    • AOF 日志也是在主线程中履行(写回战略为 always 时)，假如在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，从而导致后续的操作也无法履行了。

这两个危险都是和 AOF 写回磁盘的机遇相关的。这也就意味着，假如咱们能够控制一个写指令履行完后 AOF 日志写回磁盘的机遇，这两个危险就解除了。

日志的写回战略

AOF 机制一共有三种写回战略，也便是 AOF 装备项 appendfsync 的三个可选值。

  • Always 同步写回：每个写指令履行完，立马同步地将日志写回磁盘；
  • Everysec 每秒写回：每个写指令履行完，仅仅先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
  • No 操作体系控制的写回：每个写指令履行完，仅仅先把日志写到 AOF 文件的内存缓冲区，由操作体系决议何时将缓冲区内容写回磁盘。

针对防止主线程堵塞和削减数据丢掉问题，这三种写回战略都无法做到两全其美。

image.png

咱们就能够依据体系对高功能和高可靠性的要求，来挑选运用哪种写回战略了。

  • 想要获得高功能，就挑选 No 战略；
  • 想要得到高可靠性确保，就挑选 Always 战略；
  • 答应数据有一点丢掉，又希望功能别受太大影响的话，那么就挑选 Everysec 战略。

日志的重写

重写的效果

AOF 是以文件的方法在记载接收到的一切写指令。随着接收的写指令越来越多，AOF 文件会越来越大。这也就意味着，咱们一定要小心 AOF 文件过大带来的功能问题，首要在于以下三个方面：

  • 一是，文件体系自身对文件大小有约束，无法保存过大的文件；
  • 二是，假如文件太大，之后再往里边追加指令记载的话，效率也会变低；
  • 三是，假如发生宕机，AOF 中记载的指令要一个个被从头履行，用于毛病康复，假如日志文件太大，整个康复进程就会十分缓慢，这就会影响到 Redis 的正常运用。

AOF 重写机制便是在重写时，Redis 依据数据库的现状创立一个新的 AOF 文件，也便是说，读取数据库中的一切键值对，然后对每一个键值对用一条指令记载它的写入。重写机制具有“多变一”功用。所谓的“多变一”，也便是说，旧日志文件中的多条指令，在重写后的新日志中变成了一条指令。

image.png

重写的进程

AOF 日志由主线程写回不同，重写进程是由后台子进程 bgrewriteaof 来完成的，这也是为了防止堵塞主线程，导致数据库功能下降。

我把重写的进程总结为“一个仿制，两处日志”。

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

第一处日志，指的是由于主线程未堵塞，仍然能够处理新来的操作，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是完全的，能够用于康复。

第二处日志，便是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样，重写日志也不会丢掉最新的操作。等到仿制数据的一切操作记载重写完成后，重写日志记载的这些最新操作也会写入新的 AOF 文件，以确保数据库最新状况的记载。

此刻，咱们就能够用新的 AOF 文件替代旧文件了。

image.png

总结来说，每次 AOF 重写时，Redis 会先履行一个内存仿制，用于重写；然后，运用两个日志确保在重写进程中，新写入的数据不会丢掉。并且，由于 Redis 采用子进程进行日志重写，所以，这个进程并不会堵塞主线程。

正由于记载的是操作指令，而不是实践的数据，所以，用 AOF 办法进行毛病康复的时候，需要逐个把操作日志都履行一遍。假如操作日志十分多，Redis 就会康复得很缓慢，影响到正常运用。这当然不是理想的结果。那么，还有没有既能够确保可靠性，还能在宕机时实现快速康复的其他办法呢？

RDB

对 Redis 来说，它实现相似照片记载效果的方法，把某一时刻的状况以文件的方法写到磁盘上，也便是快照（RDB 文件）。这样一来，即使宕机，快照文件也不会丢掉，数据的可靠性也就得到了确保。

和 AOF 相比，RDB 记载的是某一时刻的数据，并不是操作，所以，在做数据康复时，咱们能够直接把 RDB 文件读入内存，很快地完成康复。

快照的原理

Redis 供给了两个指令来生成 RDB 文件，分别是 save 和 bgsave。

  • save：在主线程中履行，会导致堵塞；
  • bgsave：创立一个子进程，专门用于写入 RDB 文件，防止了主线程的堵塞，这也是 Redis RDB 文件生成的默许装备。

咱们能够经过 bgsave 指令来履行全量快照，这既供给了数据的可靠性确保，也防止了对 Redis 的功能影响。

在履行快照的同时，Redis 就会凭借操作体系供给的写时仿制技能（Copy-On-Write, COW），正常处理写操作。bgsave 子进程是由主线程 fork 生成的，能够共享主线程的一切内存数据。bgsave 子进程运转后，开端读取主线程的内存数据，并把它们写入 RDB 文件。

假如主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。可是，假如主线程要修正一块数据（例如图中的键值对 C），那么，这块数据就会被仿制一份，生成该数据的副本（键值对 C’）。然后，主线程在这个数据副本上进行修正。同时，bgsave 子进程能够持续把原来的数据（键值对 C）写入 RDB 文件。
image.png

这样既确保了快照的完整性，也答应主线程同时对数据进行修正，防止了对正常业务的影响。

混合 AOF/RDB

尽管 bgsave 履行时不堵塞主线程，可是，假如频频地履行全量快照，也会带来两方面的开支。

一方面，频频将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞赛有限的磁盘带宽，前一个快照还没有做完，后一个又开端做了，容易造成恶性循环（所以，在 Redis 中假如有一个 bgsave 在运转，就不会再发动第二个 bgsave 子进程）。

另一方面，bgsave 子进程需要经过 fork 操作从主线程创立出来。尽管，子进程在创立后不会再堵塞主线程，可是，fork 这个创立进程自身会堵塞主线程，并且主线程的内存越大，堵塞时刻越长。

Redis 4.0 中提出了一个混合运用 AOF 日志和内存快照的办法。简略来说，内存快照以一定的频率履行，在两次快照之间，运用 AOF 日志记载这期间的一切指令操作。这样一来，快照不必很频频地履行，这就防止了频频 fork 对主线程的影响。并且，AOF 日志也只用记载两次快照间的操作，也便是说，不需要记载一切操作了，因此，就不会呈现文件过大的情况了，也能够防止重写开支。

image.png

总结

最后，关于 AOF 和 RDB 的挑选问题，我想再给你提三点建议：

  • 数据不能丢掉时，内存快照和 AOF 的混合运用是一个很好的挑选；
  • 假如答应分钟等级的数据丢掉，能够只运用 RDB；
  • 假如只用 AOF，优先运用 everysec 的装备选项，由于它在可靠性和功能之间取了一个平衡。

参阅

摘自 极客时刻 – 蒋德钧老师的《Redis 核心技能与实战》 <- 极其推荐我们阅读~

《Redis 核心技能与实战》学习笔记 Day13