Redis学习笔记（04 | AOF日志：宕机了，Redis如何避免数据丢失？）

参考

https://time.geekbang.org/column/article/271754

引言

从后端数据库恢复这些数据，存在两个问题：
一是，需要频繁访问数据库，会给数据库带来巨大的压力；
二是，这些数据是从慢速数据库中读取出来的，性能肯定比不上从 Redis 中读取，导致使用这些数据的应用程序响应变慢。

Redis 的持久化主要有两大机制，即 AOF（Append Only File）日志和 RDB 快照。
04章节主要讲AOF日志

AOF 日志是如何实现的？

WAL日志与AOF日志

WAL，指数据库的写前日志（Write Ahead Log, WAL）：在实际写数据前，先把修改的数据记到日志文件中，以便故障时进行恢复。

不过，AOF 日志（Append Only File）正好相反，它是写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志，如下图所示：

AOF 先执行命令再记日志的优缺点

传统数据库的日志，例如 redo log（重做日志），记录的是修改后的数据。
而AOF 里记录的是 Redis 收到的每一条命令，这些命令是以文本形式保存的。

优点

• 写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。可以避免出现记录错误命令的情况。
• 它是在命令执行后才记录日志，所以不会阻塞当前的写操作。

存在两个风险

• 首先，如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。
• 其次，AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。

这两个风险都是和 AOF 写回磁盘的时机相关的

三种写回策略

AOF 机制给我们提供了三个选择，也就是 AOF 配置项 appendfsync 的三个可选值。

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

日志文件太大了怎么办？

随着接收的写命令越来越多，AOF 文件会越来越大。这也就意味着，我们一定要小心 AOF 文件过大带来的性能问题。
需要AOF 重写机制。

AOF 重写会阻塞吗?

这个过程通过后台线程完成，避免了对主线程的阻塞。