AOF日志：Redis如何避免数据丢失

AOF日志&＃xff1a;Redis如何避免数据丢失

问题聚焦&＃xff1a;

• 一旦服务器宕机&＃xff0c;Redis如何避免数据丢失

我们很容易想到的一个解决方案是&＃xff0c;从后端数据库恢复这些数据&＃xff0c;但这种方式存在两个问题&＃xff1a;

• 1.需要频繁访问数据库&＃xff0c;会给数据库带来巨大的压力&＃xff1b;
• 2.这些数据是从慢速数据库中读取出来的&＃xff0c;性能肯定比不上从Redis中读取&＃xff0c;导致使用这些数据的应用程序响应变慢。

所以&＃xff0c;对Redis来说&＃xff0c;实现数据的持久化&＃xff0c;避免从后端数据库中进行恢复&＃xff0c;是至关重要的。

Redis的持久化主要有两大机制&＃xff0c;即AOF日志和RDB快照&＃xff0c;本文主要对这两种机制进行分析。

AOF日志是如何实现的&＃xff1f;

对于数据库我们比较熟悉的是写前日志&＃xff08;Write Ahead Log, WAL&＃xff09;&＃xff0c;也就是说&＃xff0c;在实际写数据前&＃xff0c;先把修改的数据记到日志文件中&＃xff0c;以便故障时进行恢复。不过&＃xff0c;AOF日志正好相反&＃xff0c;它是写后日志&＃xff0c;即Redis是先执行命令&＃xff0c;把数据写入内存&＃xff0c;然后才记录日志。

那AOF为什么要先执行命令再记日志呢&＃xff1f;

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

我们以Redis收到“set testkey testvalue”命令后记录的日志为例。AOF日志的内容&＃xff0c;其中&＃xff0c;“*3”表示当前命令有三个部分&＃xff0c;每部分都是由“$&＃43;数字”开头&＃xff0c;后面紧跟着具体的命令、键或值。这里“数字”表示这部分中的命令、键或值一共有多少字节。例如&＃xff0c;“$3 set”表示这部分有3个字节&＃xff0c;也就是“set”命令。

为了避免额外的检查开销&＃xff0c;Redis在向AOF里面记录日志的时候&＃xff0c;并不会先去对这些命令进行语法检查。所以&＃xff0c;如果先记日志再执行命令的话&＃xff0c;日志中就有可能记录了错误的命令&＃xff0c;Redis在使用日志恢复数据时&＃xff0c;就可能会出错

而写后日志这种方式&＃xff0c;就是先让系统执行命令&＃xff0c;只有命令能执行成功&＃xff0c;才会被记录到日志中&＃xff0c;否则&＃xff0c;系统就会直接向客户端报错。

所以&＃xff0c;Redis使用写后日志的好处&＃xff1a;

• 1.可以避免出现记录错误命令的情况。
• 2.在命令执行后才记录日志&＃xff0c;所以不会阻塞当前的写操作。

不过&＃xff0c;AOF也有两个潜在的风险&＃xff1a;

• 1.命令和数据丢失的风险。刚执行完一个命令&＃xff0c;还没有来得及记日志就宕机了&＃xff0c;那么这个命令和相应的数据就有丢失的风险。
• 2.可能会给下一个操作带来阻塞的风险。AOF日志也是在主线程中执行的&＃xff0c;如果在把日志文件写入磁盘时&＃xff0c;磁盘写压力大&＃xff0c;就会导致写盘很慢&＃xff0c;进而导致后续的操作也无法执行了。

这两个风险都是和AOF写回磁盘的时机相关的。这也就意味着&＃xff0c;如果我们能够控制一个写命令执行完后AOF日志写回磁盘的时机&＃xff0c;这两个风险就解除了。

三种写回策略

其实&＃xff0c;对于这个问题&＃xff0c;AOF机制给我们提供了三个选择&＃xff0c;也就是AOF配置项appendfsync的三个可选值。

• Always&＃xff0c;同步写回&＃xff1a;每个写命令执行完&＃xff0c;立马同步地将日志写回磁盘&＃xff1b;

• Everysec&＃xff0c;每秒写回&＃xff1a;每个写命令执行完&＃xff0c;只是先把日志写到AOF文件的内存缓冲区&＃xff0c;每隔一秒把缓冲区中的内容写入磁盘&＃xff1b;

• No&＃xff0c;操作系统控制的写回&＃xff1a;每个写命令执行完&＃xff0c;只是先把日志写到AOF文件的内存缓冲区&＃xff0c;由操作系统决定何时将缓冲区内容写回磁盘。

针对避免主线程阻塞和减少数据丢失问题&＃xff0c;这三种写回策略都无法做到两全其美。我们来分析下其中的原因。

• “同步写回”可以做到基本不丢数据&＃xff0c;但是它在每个写命令后都有一个慢速的落盘操作&＃xff0c;不可避免地会 影响主线程性能&＃xff1b;

• 虽然“操作系统控制的写回”在写完缓冲区后&＃xff0c;就可以继续执行后续的命令&＃xff0c;但是落盘的时机已经不在 Redis手中了&＃xff0c;只要AOF记录没有写回磁盘&＃xff0c;一旦宕机对应的数据就丢失了&＃xff1b;

• “每秒写回”采用一秒写回一次的频率&＃xff0c;避免了“同步写回”的性能开销&＃xff0c;虽然减少了对系统性能的影响&＃xff0c;但是如果发生宕机&＃xff0c;上一秒内未落盘的命令操作仍然会丢失。所以这只能算是&＃xff0c;在避免影响主线程性能和避免数据丢失两者间取了个折中。

由此&＃xff0c;我们可以根据系统对高性能和高可靠性的要求&＃xff0c;来选择使用哪种写回策略了&＃xff1a;

• 想要获得高性能&＃xff0c;就选择No策略&＃xff1b;
• 想要得到高可靠性保证&＃xff0c;就选择Always策略&＃xff1b;
• 如果允许数据有一点丢失&＃xff0c;又希望性能别受太大影响的话&＃xff0c;那么就选择Everysec策略。

在选定了写回策略之后&＃xff0c;还有一个重要问题&＃xff1a;随着接收的写命令越来越多&＃xff0c;AOF文件会越来越大。这也就意味着&＃xff0c;我们一定要小心AOF文件过大带来的性能问题&＃xff1a;

• 1.文件系统本身对文件大小有限制&＃xff0c;无法保存过大的文件&＃xff1b;
• 2.如果文件太大&＃xff0c;之后再往里面追加命令记录的话&＃xff0c;效率也会变低&＃xff1b;
• 3.如果发生宕机&＃xff0c;AOF中记录的命令要一个个被重新执行&＃xff0c;用于故障恢复&＃xff0c;如果日志文件太大&＃xff0c;整个恢复过程就会非常缓慢&＃xff0c;这就会影响到Redis的正常使用。

控制日志文件过大就要用到AOF重写机制。

AOF重写机制

AOF重写机制就是在重写时&＃xff0c;Redis根据数据库的现状创建一个新的AOF文件&＃xff0c;即读取数据库中的所有键值对&＃xff0c;然后对每一个键值对用一条命令记录它的写入。

为什么重写机制可以把日志文件变小呢?

• 实际上&＃xff0c;重写机制具有“多变一”功能。所谓的“多变一”&＃xff0c;也就是说&＃xff0c;旧日志文件中的多条命令&＃xff0c;在重写后的新日志中变成了一条命令。

• 当一个键值对被多条写命令反复修改时&＃xff0c;AOF文件会记录相应的多条命令。但是&＃xff0c;在重写的时候&＃xff0c;是根据这个键值对当前的最新状态&＃xff0c;为它生成对应的写入命令。这样一来&＃xff0c;一个键值对在重写日志中只用条命令就行了。

此外虽然AOF重写后&＃xff0c;日志文件会缩小&＃xff0c;但是&＃xff0c;要把整个数据库的最新数据的操作日志都写回磁盘&＃xff0c;仍然是一个非常耗时的过程。我们还要关注另一个问题&＃xff1a;重写会不会阻塞主线程&＃xff1f;

AOF重写会阻塞吗?

和AOF日志由主线程写回不同&＃xff0c;重写过程是由后台线程bgrewriteaof来完成的&＃xff0c;这也是为了避免阻塞主线程&＃xff0c;导致数据库性能下降。

重写的过程可以总结为“一个拷贝&＃xff0c;两处日志”

• “一个拷贝”就是指&＃xff0c;每次执行重写时&＃xff0c;主线程fork出后台的bgrewriteaof子进程。此时&＃xff0c;fork会把主线程的内存拷贝一份给bgrewriteaof子进程&＃xff0c;这里面就包含了数据库的最新数据。

• “两处日志”因为主线程未阻塞&＃xff0c;仍然可以处理新来的操作。此时&＃xff0c;如果有写操作&＃xff0c;第一处日志就是指正在使用的AOF日志&＃xff0c;Redis会把这个操作写到它的缓冲区。这样一来&＃xff0c;即使宕机了&＃xff0c;这个AOF日志的操作仍然是齐全的&＃xff0c;可以用于恢复。第二处日志&＃xff0c;就是指新的AOF重写日志。这个操作也会被写到重写日志的缓冲区。这样&＃xff0c;重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后&＃xff0c;重写日志记录的这些最新操作也会写入新的AOF文件&＃xff0c;以保证数据库最新状态的记录。此时&＃xff0c;我们就可以用新的AOF文件替代旧文件了。

总结来说&＃xff0c;每次AOF重写时&＃xff0c;Redis会先执行一个内存拷贝&＃xff0c;用于重写&＃xff1b;然后&＃xff0c;使用两个日志保证在重写过程中&＃xff0c;新写入的数据不会丢失。而且&＃xff0c;因为Redis采用额外的线程进行数据重写&＃xff0c;所以&＃xff0c;这个过程并不会阻塞主线程。

存拷贝&＃xff0c;用于重写&＃xff1b;然后&＃xff0c;使用两个日志保证在重写过程中&＃xff0c;新写入的数据不会丢失。而且&＃xff0c;因为Redis采用额外的线程进行数据重写&＃xff0c;所以&＃xff0c;这个过程并不会阻塞主线程。