Redis 持久化技术 AOF 要点与详细解答
在竞争激烈的久化技术解答技术求职面试中，Redis作为高性能的详细键值对数据库，是久化技术解答众多面试官重点考察的知识领域，而其中的详细AOF（Append - Only File）机制更是高频考点。Redis AOF 功能为数据持久化提供了一种可靠且易于理解的久化技术解答方式，围绕它产生了一系列既能考查面试者对基础知识的详细掌握，又能检验其对复杂实际场景应对能力的久化技术解答面试题。
无论是详细初入职场渴望崭露头角的技术新人，还是久化技术解答经验丰富寻求新挑战的开发者，深入理解Redis AOF相关面试题都是详细成功通过面试的关键一步。这篇文章，久化技术解答将成为你攻克Redis AOF面试题的详细得力助手，我们将全方位、久化技术解答多角度地梳理常见面试题，详细不仅给出标准答案，久化技术解答更会深入剖析解题思路和背后的原理知识，助你在面试中自信应对，源码库脱颖而出。
一、详解AOF基础知识点
1. AOF技术简介AOF（Append-Only File）用于将Redis服务器收到的写操作追加到日志文件，通过该机制可以保证服务器重启后依然可以依靠日志文件恢复数据。 它的工作过程大抵分为以下几步：
收到客户端的写入命令(例如SET、DEL等)之后，它会将命令写入AOF缓冲区。redis服务器会定期或者在特定条件下，将AOF缓冲区的数据以追加的方式写到日志文件末尾，这种写入的操作可以是同步的，也可以是异步的，具体看我们配置的刷盘机制。若日志文件超过配置文件的大小(由配置参数 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 决定)，则会触发AOF重写(AOF Rewrite)，重写时会启动一个后台进程，分析日志中的指令并精简化写入新的AOF文件中。新的AOF文件和旧的AOF文件进行原子替换，IT技术网后续的写指令都会写到这个新的AOF文件中。
优势：
客户端操作的指令可能会出错，采用写后再日志的形式可以避免很多没必要的日志记录，节约磁盘空间写日志需要进行磁盘IO，可能会产生阻塞，所以采用先写入再日志，可以避免写时阻塞。劣势:
有可能在写操作之后，日志记录之前服务器出现宕机，可能会造成数据丢失当主线程磁盘压力过大，导致写入磁盘慢，进而造成后续操作阻塞。3. AOF核心配置参数(1) appendonly：若将该参数设置为yes，则开启aof持久化机制，此时redis持久化机制就以aof为主，而非rdb
复制# 设置为yes开启aof appendonly yes1.2.如下示例所示，我们将该参数配置为yes后重启redis服务端，使用客户端完成如下操作：
复制# 设置三个key 127.0.0.1:6379> set k1 v1 OK 127.0.0.1:6379> set k2 v2 OK 127.0.0.1:6379> set k3 v3 OK1.2.3.4.5.6.7.此时我们查看aof文件，大小增加了：
复制[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly.aof /usr/sbin/appendonly.aof [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly.aof /usr/sbin/appendonly.aof [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# ll appendonly.aof -rw-r--r-- 1 root root 110 Aug 26 00:09 appendonly.aof1.2.3.4.5.6.7.然后我们再次使用客户端写入文件，可以看到大小又增加了，由此得出我们AOF配置生效了。
复制# 再次查看aof文件大小，变为139，说明aof配置生效 [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# ll appendonly.aof -rw-r--r-- 1 root root 139 Aug 26 00:10 appendonly.aof [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]#1.2.3.4.appendfilename ，该参数决定aof持久化文件的名字，这个就不多赘述了。企商汇 如下所示，这条配置就意味着aof文件名是appendonly
复制appendfilename "appendonly.aof"1.(2) dir ：该参数决定aof文件持久化位置，默认为redis-server的位置。
复制dir ./1.(3) appendfsync(重点) : 在介绍appendfsync，我们必须介绍一下操作系统提供的两个函数
write：write操作会触发操作系统延迟写机制，这种机制下数据一写到缓存区就直接返回，至于什么时候进行刷盘由操作系统决定，要么缓存空间满了刷，要么就是定时任务时间到了。fsync:该调用会强制将缓存写入磁盘中，所以使用这个函数进行文件写入时，可能存在阻塞问题。了解了上述两个函数之后，我们再来聊聊这个参数值:
always:该选项会使得命令一旦写入aof_buf后，就会调用操作系统的fsync将指令写到aof物理文件中，完成操作后线程返回everysec:该选项会在命令写入aof_buf后调用操作系统的wirte，完成write后线程返回。fsync会由专门的线程每秒调用一次no:该选项会在命令写入aof_buf后调用操作系统的write，完成write后线程返回，不调用fsync，同步操作由操作系统执行，最长周期为30s。所以配置时，我们建议采用默认的写入策略everysec，他不会像always造成线程阻塞亦或者像no一样不可控。
复制appendfsync everysec1.(4) no-appendfsync-on-rewrite：redis为了保证持久化aof文件时调用fsync时不会出现长时间的卡顿，增加了该参数，若设置为yes，在redis调用fsync期间出现的写入指令不会将其放到页缓存(page cache)中，仅仅做个接收，保证不阻塞。
复制no-appendfsync-on-rewrite yes1.(5) auto-aof-rewrite-percentage和auto-aof-rewrite-min-size(重点)：这两个参数决定redis何时进行重写，如下所示，这两个参数分别为100和64mb，意味当本次aof文件超过64+64*100%就触发redis自动重写。
复制auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb1.2.(6) aof-load-truncated：若设置为yes时在redis加载aof文件出错后会发送日志通知用户，反之则不做任何处理也不会启动redis，用户可以使用redis-check-aof指令完成数据修复。 这个参数笔者会在后文演示。
复制aof-load-truncated yes1.(7) aof-rewrite-incremental-fsync：开启该参数后，子进程在进行aof重写时，每32m就会将数据写到的新的aof文件中，从而避免单刷造成的线程阻塞。
复制aof-rewrite-incremental-fsync yes1.(8) aof-use-rdb-preamble：redis 4.0之后支持同时开启rdb和aof，具体后文会详述
复制# rdb+aof两种机制结合使用 aof-use-rdb-preamble yes1.2. 4. AOF断电后恢复的过程是什么我们在之前的aof文件重命名，模拟断电后数据丢失，首先将aof文件备份，在重启redis，模拟断电后数据丢失
复制[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv appendonly.aof appendonly.aof.bak # 重启redis服务端，打开客户端查看数据都丢失了 [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli 127.0.0.1:6379> auth 123 OK 127.0.0.1:6379> keys * (empty array)1.2.3.4.5.6.7.8.9.然后将备份文件还原，重启redis。
复制# 将aof文件还原，并重启redis [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv appendonly.aof.bak appendonly.aof mv: overwrite ‘appendonly.aof’? y [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf1.2.3.4.可以看到，数据已经回来了。
复制# 再次使用redis查看，丢失的数据都回来了 [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli 127.0.0.1:6379> auth 123 OK 127.0.0.1:6379> keys * 1) "k4" 2) "k3" 3) "k2" 4) "k1" 127.0.0.1:6379>1.2.3.4.5.6.7.8.9.10.二、详解AOF持久化技术进阶知识点
1. AOF重写时是否会阻塞线程答案是会的，但阻塞大部分情况是发生在fork子进程那段时间，AOF重写时首先会fork一个子进程进行日志重写，在此期间新写入的数据都会被存到的AOF缓冲区中，直到子进程全部完成重写并原子覆盖aof日志文件后，才会将这些缓冲数据写到新的日志文件中：
需要补充的是，上面提到日志重写期间数据都会被写到AOF缓冲区中，在高并发场景下也可能导致内存被打满出现频繁内存置换等情况间接导致我们的redis进程阻塞，此时就可能出现读写性能下降的情况：
执行顺序为:
先看看有没有AOF，若有则先加载AOF，然后执行步骤2。查看是否有RDB文件，若有再加载RDB文件。
在日志写入期间要是服务器宕机了，那么这个日志文件可能就用不了了，而解决方案也很可能简单，redis给我提供一个命令进行fix。
例子如下，我们首先需要将一个日志文件损坏:
复制# 追加一个错误数据到aof文件末行并杀死redis 模拟服务器宕机 [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# vim appendonly.aof # 再次启动redis，操作数据时发现登录失败 [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected>1.2.3.4.5.6.7.8.9.然后使用日志文件进行修复：
复制# 使用 redis-check-aof --fix aof文件 修复文件 [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-check-aof --fix appendonly.aof 0x 8b: Expected prefix *, got: s AOF analyzed: size=151, ok_up_to=139, ok_up_to_line=34, diff=12 This will shrink the AOF from 151 bytes, with 12 bytes, to 139 bytes # 这里选择y Continue? [y/N]: y Successfully truncated AOF1.2.3.4.5.6.7.8.可以看到，经过fix修复后的日志文件部分数据已经恢复了：
复制# 重启redis，使用客户端连接发现启动成功且数据都还在 [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf [root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli 127.0.0.1:6379> keys * 1) "k4" 2) "k3" 3) "k2" 4) "k1"1.2.3.4.5.6.7.8.9. 4. AOF相较于RDB持久化的优势优势如下:
备份机制更稳健，丢失数据几率低。日志可读，可以处理误操作。而劣势也很明显:
比RDB更占磁盘空间,毕竟RDB存放的不是二进制文件。每次AOF都进行fsync的话，性能开销大。恢复和备份速度较慢。5. Redis混合持久化Redis4.0实现了RDB和AOF混合方式，相比于单RDB或者单AOF更安全，执行效率更高，它的执行过程大抵如下：
初始状态下，写入的指令都会以AOF格式写入aof文件中。当发生AOF重写时(bgrewriteaof )，redis会fork出一个子进程，进行aof重写。redis将重写的数据以rdb的数据写到新的aof文件中。随后再将aof缓冲区的增量命令（aof_rewrite_buf_blocks）写到新的aof文件中。完成上述操作后我们就会得到一个前半部分是RDB后半部分是AOF的aof日志文件。最后将新的aof文件替换掉旧的rdb和aof文件。
对应的重启后的加载流程也改为：
判断持久化格式，如果是rdb格式则按照rdb格式进行恢复，反之按照aof格式格式进行恢复进入步骤2。查看aof文件文件是否存在，若存在进入步骤3。查看文件前半部分是否是RDB如果是则先按照rdb格式恢复，然后再按照aof格式恢复。若没有rdb开头格式的内容，直接按照常规aof格式恢复。本文地址：http://www.bzuk.cn/html/223f8999687.html
版权声明
本文仅代表作者观点，不代表本站立场。
本文系作者授权发表，未经许可，不得转载。