04 | AOF日志：宕机了，Redis如何避免数据丢失？

问题1，Redis采用fork子进程重写AOF文件时，潜在的阻塞风险包括：fork子进程 和 AOF重写过程中父进程产生写入的场景，下面依次介绍。 a、fork子进程，fork这个瞬间一定是会阻塞主线程的（注意，fork时并不会一次性拷贝所有内存数据给子进程，老师文章写的是拷贝所有内存数据给子进程，我个人认为是有歧义的），fork采用操作系统提供的写实复制(Copy On Write)机制，就是为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题，但fork子进程需要拷贝进程必要的数据结构，其中有一项就是拷贝内存页表（虚拟内存和物理内存的映射索引表），这个拷贝过程会消耗大量CPU资源，拷贝完成之前整个进程是会阻塞的，阻塞时间取决于整个实例的内存大小，实例越大，内存页表越大，fork阻塞时间越久。拷贝内存页表完成后，子进程与父进程指向相同的内存地址空间，也就是说此时虽然产生了子进程，但是并没有申请与父进程相同的内存大小。那什么时候父子进程才会真正内存分离呢？“写实复制”顾名思义，就是在写发生时，才真正拷贝内存真正的数据，这个过程中，父进程也可能会产生阻塞的风险，就是下面介绍的场景。 b、fork出的子进程指向与父进程相同的内存地址空间，此时子进程就可以执行AOF重写，把内存中的所有数据写入到AOF文件中。但是此时父进程依旧是会有流量写入的，如果父进程操作的是一个已经存在的key，那么这个时候父进程就会真正拷贝这个key对应的内存数据，申请新的内存空间，这样逐渐地，父子进程内存数据开始分离，父子进程逐渐拥有各自独立的内存空间。因为内存分配是以页为单位进行分配的，默认4k，如果父进程此时操作的是一个bigkey，重新申请大块内存耗时会变长，可能会产阻塞风险。另外，如果操作系统开启了内存大页机制(Huge Page，页面大小2M)，那么父进程申请内存时阻塞的概率将会大大提高，所以在Redis机器上需要关闭Huge Page机制。Redis每次fork生成RDB或AOF重写完成后，都可以在Redis log中看到父进程重新申请了多大的内存空间。 问题2，AOF重写不复用AOF本身的日志，一个原因是父子进程写同一个文件必然会产生竞争问题，控制竞争就意味着会影响父进程的性能。二是如果AOF重写过程中失败了，那么原本的AOF文件相当于被污染了，无法做恢复使用。所以Redis AOF重写一个新文件，重写失败的话，直接删除这个文件就好了，不会对原先的AOF文件产生影响。等重写完成之后，直接替换旧文件即可。

什么时候会触发AOF 重写呢？

AOF 是什么的缩写， 还是说就是这个名字？

图是不是画错了。为什么主线程和AOF重写缓冲连起来了呢？不是应该bgrewriteaof来写吗？

问个问题：redis同时开启RDB和AOF，redis重启基于哪个文件进行数据恢复

一口气看了好多节课，感谢老师的用心准备。老师的课从问题出发，从表面到原理，循序渐进，通俗易懂。对比其他有些课程，要么浮于表面，要么晦涩难懂。希望老师能够再出更多课程，谢谢。

1，作者讲了什么？ 本章讲了Redis两种持久化机制之一：AOF机制原理 aof日志记录了redis所有增删改的操作，保存在磁盘上，当redis宕机，需要恢复内存中的数据时，可以通过读取aop日志恢复数据，从而避免因redis异常导致的数据丢失 2，作者是怎么把这事给讲明白的？ （1）作者先讲述redis宕机会导致内存数据丢失，需要有一种机制在redis重启后恢复数据。 （2）介绍了AOF通过记录每一个对redis数据进行增删改的操作日志，可以实现这种功能 （2）介绍了AOF的运行机制，数据保存机制，以及由此带来的优点和缺点 3，为了讲明白，作者讲了哪些要点，有哪些亮点？ （1）亮点：记录操作的时机分为：“写前日志和写后日志”，这个是我之前所不知道的 （2）要点1：AOF是写后日志，这样带来的好处是，记录的所有操作命令都是正确的，不需要额外的语法检查，确保redis重启时能够正确的读取回复数据 （3）要点2：AOF日志写入磁盘是比较影响性能的，为了平衡性能与数据安全，开发了三种机制：①：立即写入②：按秒写入③：系统写入 （4）要点3：AOF日志会变得巨大，所以Redis提供了日志重整的机制，通过读取内存中的数据重新产生一份数据写入日志 4，对于作者所讲，我有哪些发散性的思考？ 作者说系统设计“取舍”二字非常重要，这是我之前未曾意识到的。作者讲了fork子进程机制，是Linux系统的一个能力，在刘超的课中讲过，这鼓舞了我继续学习的信心 5，将来有哪些场景，我可以应用上它？ 目前还没有机会直接操作生产的redis配置，但现在要学习，争取将来可以直接操作

为了减小aof文件的体量，可以手动发送“bgrewriteaof”指令，通过子进程生成更小体积的aof，然后替换掉旧的、大体量的aof文件。 也可以配置自动触发 　　1）auto-aof-rewrite-percentage 100 　　2）auto-aof-rewrite-min-size 64mb 　　这两个配置项的意思是，在aof文件体量超过64mb，且比上次重写后的体量增加了100%时自动触发重写。我们可以修改这些参数达到自己的实际要求

有几个问题想请教一下： 1、文中多处提到bgrewriteaof 子进程，这个有点迷糊，主线程fork出来的bgrewriteaof是子线程还是子进程？ 2、AOF重写会拷贝一份完整的内存数据，这个会导致内存占用直接翻倍吗？ 3、如果一个key设置了过期时间，在利用AOF文件恢复数据时，key已经过期了这个是如何处理的呢？

AOF工作原理： 1、Redis 执行 fork() ，现在同时拥有父进程和子进程。 2、子进程开始将新 AOF 文件的内容写入到临时文件。 3、对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。 4、当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。 5、搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。 试着讨论下留言童鞋的几个问题 一、其中老师在文中提到：“因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。” 这里面说到 “Redis 会把这个操作写到它的缓冲区，这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的”，其实对于有些人有理解起来可能不是那么好理解，因为写入缓冲区为什么还不都是数据； 我的理解其实这个就是写入缓冲区，只不过是由appendfsync策略决定的，所以说的不丢失数据指的是不会因为子进程额外丢失数据。 二、AOF重新只是回拷贝引用(指针)，不会拷贝数据本身，因此量其实不大，那写入的时候怎么办呢，写时复制，即新开辟空间保存修改的值，因此需要额外的内存，但绝对不是redis现在占有的2倍。 三、AOF对于过期key不会特殊处理，因为Redis keys过期有两种方式：被动和主动方式。 当一些客户端尝试访问它时，key会被发现并主动的过期。 当然，这样是不够的，因为有些过期的keys，永远不会访问他们。 无论如何，这些keys应该过期，所以定时随机测试设置keys的过期时间。所有这些过期的keys将会从删除。 具体就是Redis每秒10次做的事情： 测试随机的20个keys进行相关过期检测。 删除所有已经过期的keys。 如果有多于25%的keys过期，重复步奏1. 至于课后问题，看了 @与路同飞 童鞋的答案，没有更好的答案，就不回答了