Redis学习笔记-AOF日志&重写机制

Redis学习笔记-AOF日志&重写机制

Redis 使用最多的场景是 缓存，若出现服务器宕机的情况，内存中的数据将全部丢失，若恢复数据的时候从后端数据库读取就会给数据库造成很大的压力，并且数据恢复缓慢，所以对于 Redis 来说，实现数据的持久化是非常重要的，而 AOF日志 和 RDB快照是 Redis 实现持久化的两大机制，这篇文章学习一下 AOF 持久化日志。

1.笔记图

2.AOF 日志实现

• AOF 是一种写后日志，即先执行 Redis 命令，后记录日志。

3.写日志先后顺序的思考

• Redis 为了避免额外开销，写 AOF 日志的时候不会对些命令语法检查
• 如果先写日志再执行命令可能会记录错误的命令，恢复数据时，可能出错
• 只有能执行成功的命令，才会被记录到日志中
• 命令执行完后写日志不会阻塞当前的写操作

4.AOF 日志记录的内容举例说明

#举例
set testkey testvalue

日志记录内容如下：

*3
$3
set
$7
testkey
$9
testvalue

Tips：其中 *3 表示有 3 个部分，$3 表示后面紧跟的键/值有 3 字节。

5.由 AOF 日志记录引发的潜在风险思考

• 如果刚执行完，日志没写就宕机，数据就有丢失风险
• 在日志文件写入磁盘时，磁盘写压力大，会导致写盘慢，后续的操作也无法执行

6.潜在风险对应的三种写回策略

• Always：同步写回，每个写命令执行完，立马同步地将日志写回磁盘，可以做到基本不丢数据，但它在写命令后有一个慢速的落盘操作，不可避免会影响主线程性能
• Everysec：每秒写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘，避免了同步写回的性能开销，但是如果发生宕机，上一秒内未落盘的命令操作仍然会丢失
• No：操作系统控制的写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘，落盘的时机已经不在 Redis 手中了，只要 AOF 记录没有写回磁盘，一旦宕机对应的数据就丢失了

7.性能问题

• 文件系统本身对文件大小有限制，无法保存过大的文件
• 如果文件太大，之后再往里面追加命令记录的话，效率也会变低
• 如果发生宕机，AOF 中记录的命令要一个个被重新执行，恢复起来缓慢影响业务

8.AOF 重写机制

• AOF 重写机制就是在重写时根据数据库的现状创建一个新的 AOF 文件，然后对每一个键值对用一条命令记录它的写入
• AOF 文件是以追加的方式，逐一记录接收到的写命令的，AOF 文件会记录相应的多条命令
• 重写机制具有 多变一 功能，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令

Tips：举例：对一个列表先后做了 6 次修改操作后，列表的最后状态是[“D”, “C”, “N”]，此时，只用 LPUSH u:list “N”, “C”, "D"这一条命令就能实现该数据的恢复，这就节省了五条命令的空间。

9.AOF 重写机制引发的阻塞思考

• 重写过程是由后台子进程 bgrewriteaof 来完成的，不会阻塞主线程
• 一个拷贝：每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志
• 两处日志：如果有写操作，第一处日志就是指正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复第二处日志，就是指新的 AOF 重写日志，这个操作也会被写到重写日志的缓冲区，重写日志也不会丢失最新的操作

扫码关注