Redis宕机，如何避免数据丢失和快速恢复？
你会把Redis应用到什么业务场景上？你大概率会说：“会把它当缓存使用，直接从内存读取数据，响应速度快”。没错，这是Redis最普遍使用的业务场景，但是不可忽视一个问题：一旦服务器宕机，内存中的数据将全部丢失。
首先可能大家很容易想到的一个解决方案是：从后端数据库恢复这些数据。这个方案会带来2个问题：一是，需要频繁访问数据库，会给数据库带来巨大的压力；二是，这些数据是从慢速数据库中读取出来的，性能肯定比不上从 Redis 中读取，导致使用这些数据的应用程序响应变慢。Redis 为我们提供了2种持久化机制，即 AOF（Append Only File）日志和 RDB 快照。
AOF 日志是如何实现的？
AOF 日志实现：AOF 日志记录的是所执行的每一条操作指令，Redis 是先执行命令，把数据写入内存，然后才记录日志，如下图所示：
为什么要执行命令后再记录日志？
这样的好处：先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。可以避免出现记录错误命令的情况。还有一个好处是：它是在命令执行后才记录日志，所以不会阻塞当前的写操作。
AOF也有一定的风险
其一，刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。如果Redis直接作为数据库使用，日志没有记录到这条命令，就会造成这条数据丢失。
其二，避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。
三种写回策略
AOF 配置项 appendfsync 的三个可选值：
- Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
- Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
- No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
总结了一下这三种策略的优缺点，如图：
我们就可以根据系统对高性能和高可靠性的要求，来选择使用哪种写回策略了。总结一下就是：想要获得高性能，就选择 No 策略；如果想要得到高可靠性保证，就选择 Always 策略；如果允许数据有一点丢失，又希望性能别受太大影响的话，那么就选择 Everysec 策略。
AOF日志文件带来的问题
- 文件系统本身对文件大小有限制，无法保存过大的文件
- 如果文件太大，之后再往里面追加命令记录的话，效率也会变低
- 如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，影响Redis使用
解决文件过大问题：AOF 重写机制
为什么重写机制可以把日志文件变小呢? 实际上，重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。当一个键值对被多条写命令反复修改时，AOF 文件会记录相应的多条命令。但是，在重写的时候，是根据这个键值对当前的最新状态，一个键值对在重写日志中只用一条命令就行了。
AOF 重写会阻塞吗?
重写过程是由后台子进程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程。每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。
下期预告：RDB机制，敬请关注
