Redis(四)

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

当redis作为缓存或者后端数据库时，有一个绝对不能忽视的问题：“宕机了，如何避免Redis中的数据丢失？”
最简单粗暴的方法–一、从后端数据库恢复这些数据，这个方式会存在两个问题：需要频繁访问数据库，会给数据库带来巨大压力；二、将这些数据从慢速数据库中读取出来，性能比不上Redis，导致使用这些数据的应用程序响应变慢。所以对Redis来说，实现数据持久化，避免从后端数据库中进行恢复，是至关重要的。

目前，Redis中主要有两大机制：AOF日志和RDB快照。

AOF是如何实现的？

类比数据库的写前日志（write ahead log ,WAL），也就是在实际写入数据前，先把修改的数据记到日志文件中，以遍故障时进行恢复。不过，AOF日志正好相反，他是写后日志，“写后”的意思是Redis现执行命令，把数据写入内存中，然后才记录日志，如下图所示：

为什么要先执行命令再记录日志？

在探讨这个问题前，我们先了解AOF里记录了什么内容。
传统的数据库的日中，例如 redo log(重做日志)，记录的是修改后的数据，而AOF里记录的是Redis收到的每一条指令，这些命令是以文本形式保存的。例如Redis收到“set testkey testvalue”的命令后记录的日志为例，看看AOF日志的内容，其中“*3”表示当前命令有三个部分，每部分都是由“$+ 数字开头”，后面紧跟着据日的命令、键或值。这里，“数字”表示这部分中的命令、键或值一共有多少字节。例如，“$3 set”表示这部分有3个字节，也就是“set”命令。
但是，为了避免额外的检查开销，Redis在向AOF里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志在执行命令的话，日志中就有可能记录了错误的命令，Redis在使用日志恢复数据时，就有可能会出错。而后写日志这种方式，就是先让系统执行命令，只有命令执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错，所有，Redis使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。除此之外，AOF还有一个特别的好处：他是在命令执行后才记录日志，所有不会阻塞当前的写操作。

不过，AOF也有两个潜在的风险。

首先，如果刚执行完一个命令，还没来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。如果此时Redis使用作缓存，还可以从后端数据库重新读入数据进行恢复，但是，如果Redis是直接用作数据库的话，此时因为命令没有记入日志，所以就无法用日志进行恢复。
其次，AOF虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞的风险。这是因为，AOF日志也是在主线程中执行的，如果把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。
两个风险都与AOF写回磁盘的时机相关。如果能控制命令执行后AOF日志写回磁盘的时机，这两个风险就解除了。

三种写回策略

总结一下：想要获得高性能，就选择No策略；如果想要得到高可靠性保证，就选这always策略，如果允许数据有一点丢失，有希望性能别受到太大影响的话，那么就选择Everysec策略。
但是，按照系统的性能需求选定了写回策略，并不是高枕无忧了，毕竟 AOF是以文件的形式记录在收到的所有写命令。随着接受的写命令越来越多，AOF文件就会越来越大。这也就意味着，我们一定要小心AOF文件过大带来的性能问题。
这里的性能问题主要在以下三个方面：
一、文件系统本身对文件大小有限制，，无法保存过大的文件。
二、如果文件太大，之后再往里追加命令记录的话，效率也会变低。
三、如果发生宕机，AOF中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就影响到Redis的正常使用。

解决办法

AOF重写机制应运而生。AOF重写时，Redis根据数据库的现状创建一个新的AOF文件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录他的写入。如，当读取了键值对“testkey”:“testvalue”，重写机制就会记录set testkey testvalue这条命令。这样，当需要恢复时，可以重新执行该条命令，实现"test":"testvalue"的写入。
为什么重写机制可以把日志文件变小呢？实际上，重写机制具有“多变一”的功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成一条命令。实际上就是将写入的旧的命令取消，只保留最新的命令。

AOF重写会阻塞吗？

和AOF日志由主线程写回不同，重写过程是由后台子进程bgrewriteaof来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。
总结为“一个拷贝，两处日志”。
一个拷贝就是指，每次执行重写时，主线程fork出后台的bgrewriteaof子进程。此时，fork会把主线程的内存拷贝一份给bgrewriteaof子进程，这里面就包含了数据库的最新数据。然后bgrewriteaof子进程就可以在不影响主进程的情况下，逐一把拷贝的数据写成操作，记入重写的日志。
“两处日志” 指AOF重写日志，这个操作也会被
写到重写日志的缓存区。这样，重写日志也不会丢失最新的操作，等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会导致新的AOF文件，以保证数据库的最新状态的记录。此时，我们就可以用最新的AOF文件替代就文件了。