大家好，我是飓风。
大家都知道，redis相比其他cache而言，它是支持持久化的，这样就多了一份保障，在down机之后，可以从持久化文件中进行恢复，防止从后端数据库重新加载，而给数据库造成压力。
redis 支持两种持久化的方式：
一种是 AOF ，一种是RDB。
今天主要来聊聊AOF持久化的方式。
写入日志时机
redis 在写AOF日志的时候，是先执行redis命令，执行redis 命令之后，才会写入AOF日志。这样做的好处，是防止错误的命令写入AOF日志，同时还会省去redis 命令语法检查的开销，同时这样不会阻塞redis线程进行写操作。
流程如下：
日志内容
大家看了上图，其实就知道AOF日志文件存的是什么，其实就是存储的文本格式的命令，以set hi redis 为例，*3 表示由三部分( set hi redis )组成，$3表示 这个部分由三个字节组成，也就是set ,其他 hi redis 都是一个道理这里就不多做解析，如果有疑问欢迎大家留言提问。
日志的写到磁盘的策略
我们知道reids 的aof 日志，最后肯定是要落盘的，写入磁盘肯定就会受到磁盘io的影响，如果磁盘io很忙，那么势必会影响我们写入磁盘的速度，而且写入磁盘和写入内存的速度肯定不是一级别的，会不会影响redis 线程进行返回结果呢,因为我上篇文章介绍了 redis单线程模型 ，也就是阻塞了redis 的主线程呢，这样就增加了延迟,后续的操作就会排队或者超时。
其实redis 为我们提供三种写磁盘的策略，分别为Always、EverySecond、No，下面分别介绍这三种策略原理和优缺点。
Aways
所谓的always 就是执行redis 写命令之后，立即执行写回磁盘，写入磁盘之后，才会返回结果，这两部是同步进行，势必会增加redis 的响应延迟，如果此时磁盘io很繁忙，那么写如磁盘就会慢，那么redis 就会增加延迟时间。
看下图：
1-3 步骤是顺序执行，且同步执行的。
现在可以思考下，这种模式会不会丢失数据呢？ 看下图:
图中黑色圆表示断电了，拔出电线。
在执行第二步之前，断电了。
答案 是会的，如果写入内存成功后，然后同步执行写回磁盘操作，这两个步骤中，在执行写磁盘的之前，断电了，那么此时这条命令的数据是没有写入磁盘，也就是没有持久化成功，redis 再启动恢复的时候，aof日志中是没有这条记录的。
EverySecond
所谓EverySecond 这个词很好理解，就是每秒写入磁盘一次。
说下具体的流程吧，其实就是redis 写入内存成功后，并不是同步写入磁盘了，而是会写入aof日志的缓冲区，也就是一块内存，那么写入的速度会很快。然后redis 后台会有一个线程专门读取aof日志缓冲区的命令，再写入磁盘。
看图说话：
现在思考下，这种模式，会不会丢失数据呢？
看图说话：
图中黑色圆表示断电了，拔出电线。
答案是肯定的啊，因为reids 写入内存之后，会把命令写入缓冲区，缓冲区说白了 ，也是内存，后台线程每秒读取一次，写入磁盘，那么如果发生断电呢，那么缓冲区内的数据，也就是上一秒的数据，还没来得及写入磁盘就丢失了。
No
和EverySecond 类似，redis 写入内存成功之后，redis 的写命令也是会写入到aof 缓冲区，只是此时不会由redis 后台线程去执行写入磁盘的操作了，而是有操作系统来决定，何时刷新到磁盘。
看图说话：
丢不丢数据，就很好看出来了，丢多少，也由操作系统来决定了，这里不多做说明了
三种策略的对比
| 策略 | 何时写盘 | 优点 | 缺点 |
|---|---|---|---|
| Aways | 同步写入 | 基本不丢失，增加延迟 | io 忙的情况下，会增加线程返回结果的延迟时间，断电的时候会丢失还来的急写入的命令 |
| EverySecond | 每秒写入 | 性能好，不会增加太大延迟 | 断电会丢失一秒的数据 |
| No | 操作系统写入 | 性能好，不会增加太大延迟 | 丢失数据多少，由操作系统写磁盘频率决定 |
至于怎么选择这三种策略，看自己的实际需求，数据要求的敏感度，允不允许丢失，来做一个性能和需求的取舍。
AOF日志文件的重写
随着redis 命令的增多，那么aof日志文件，肯定是约来越大的，那么大文件在进行文件写入的时候，速度就会变慢，而且操作系统会对大文件的保存会做限制，无法保存文件。redis 再进行重启数据恢复的时候，是逐一执行aof日志的命令，如果文件很大，那么数据恢复的过程就会很慢，造成的影响可想而知。
那么此时就会进行aof日志文件的重写操作，那么重写过程中都干了什么呢？是在原有的aof日志文件内的命令进行重写吗？aof 重写过程中哪些操作会阻塞redis 线程的读写操作的延迟呢？
怎么就变大了？
变大的原因，其实也是很简答了，命令约来越多，当然就变大了，其次对一个key 的多次操作，就会造成一个aof文件日志存储了一个key 的多次操作，如果操作很频繁的话，那么日志文件增大的速度可想而知了。其实redis 在重写的过程中，就是把一个key 的多次操作命令进行压缩，压缩为一条写入命令，这样aof 文件就变小了，小的aof文件无论再写入和恢复数据的时候都会很快的。
看图说话：
一开始对set 集合 login_user 进行了多次操作，但是在重写之后就压缩为了一条命令。
重写过程
aof 的重写，并不会是redis 主线程来完成的，redis会fork出一个子进程进行 aof 日志的重写，这个子进程交bgrewriteaof。
redis 在进行aof 重写的过程中，并不是对原有的aof文件进行分析重写，而是会copy一份redis当前的内存页表给子进程，这也是fork子进程的过程，如果redis的内存很大，那么内存页表就会很大，那么copy的过程就会变慢，记住这个copy的过程是会阻塞redis 的主线程的。
copy完成之后，此时redis 主线程和 fork子进程就会指向相同的内存地址，那么子进程就可以开始读取内存地址的数据，来生成新的aof日志了。
那么此时可能还会有的新的请求过来，新的请求redis 必须要处理的，不能受到aof重写的影响，此时会用到linux 的copyonwrite技术，也叫写时复制，也就是说当修改一个已经存在的key的时候，此时会复制这个key所在的内存页到新的地址，复制完成后，再进行修改key的操作,如果页很大，这个过程就会阻塞redis 主线程，延迟就会增加,这是需要注意的地方。对于新进来的请求，redis 会把新命令存储aof日志重新缓冲区，当子进程重写完成之后，就会读取aof日志重新缓冲区的内容追加到新的aof日志中，此时aof重写完成，旧的aof日志就会被替换。
注意在aof重写的过程中，新的写请求过来，还是会往原来的aof日志中写入的，主要是为了防止aof重写失败，而不会影响旧aof日志数据的丢失。
继续看图说话：
总结
今天聊了aof日志持久化的方式，文件内容是什么，以及写入磁盘的三种策略，每种策略的对redis的性能和数据可靠性都有影响，Aways、EverySecond、No 性能逐次提高，可靠性逐渐降低，具体使用要看自己对数据的实际需求。
还有就是aof 重写，fork子进程是会阻塞redis 操作线程的，copyonwrite 如果遇到大页 也会增加阻塞redis 操作线程的时间。
aof 重写触发时机：
手动发送“bgrewriteaof”指令，通过子进程生成更小体积的aof，然后替换掉旧的、大体量的aof文件。
配置文件配置自动触发：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
在aof文件体量超过64mb，且比上次重写后的体量增加了100%时自动触发重写。
根据自己的需求来修改配置即可。
今天的分享就到这里了，码字画图不易，期待你的点赞、关注、转发，谢谢。
你的点赞、关注 是飓风创作的最大动力。
如有问题 欢迎人才请留言，一起讨论和勘误。
欢迎关注 github
微信添加: zookeeper0
