AOF是Redis持久化机制之一，采用写后日志的方式来保存日志，通过Always、Everysec、No三种写回策略来减少数据丢失的风险，通过重写机制提高写入效率和实现快速恢复数据。
一. 写后日志
名称 | 概念 | 优势 | 风险 |
写前日志 | 先将数据记录到日志，再写入内存 | 便于故障时恢复数据 | |
写后日志 | 先执行命令将数据写入内存，再记录日志 | 确保了只会记录正确的命令；不会阻塞当前的写操作 | 宕机可能丢失数据；可能会阻塞下一个操作 |
- AOF为什么采用写后日志？
- AOF存的是命令，不是数据！故先执行命令，可保证存入到AOF日志的命令都是正确的！
- 写后日志有哪些风险？
执行完命令到将命令存入AOF日志是有时间差的，哪怕是0.0…001ms都是时间差！在此期间，机器宕机了，这期间的数据是不是就丢失了！！！
执行命令和存入AOF日志都是通过主线程来操作的，当写入磁盘很慢时，造成当前操作阻塞，那么后续的操作也就会面临阻塞风险！！！ - 如何规避写后日志带来的风险？
写回策略+重写机制
二. 写回策略
写回策略 | 概念 | 优 | 缺 |
Always | 同步写回：命令执行成功，便即刻写入磁盘 | 数据丢失的可能性极底 | 性能差 |
Everysec | 每秒写回：命令执行成功，先写到内存缓冲区，再间隔一秒写到磁盘一次 | 性能适中 | 可能丢失 |
No | 操作系统控制的写回：命令执行成功，先写到内存缓冲区，由操作系统决定写到磁盘的时间 | 性能好 | 数据丢失的可能性大 |
写回策略解决了什么问题？
- 志在避免数据丢失和写入磁盘影响性能之间做取舍的策略。
三. 重写机制
- 重写机制解决了什么问题？
a. 随着写入AOF日志的命令越来越多，日志文件越来越大，导致写入效率变低！
b. 日志文件太大，不利于数据恢复！
ps：电脑打开一个有几十万数据的excel，是不是很卡？这就是文件太大了，严重影响了机器的性能！ - 重写机制是怎么解决问题的？
终极答案：将大文件变成小文件a. 解决思路🤔明确一点：再提醒一次，AOF日志存的是命令！不是数据！类比一哈：执行了10万次增/删/改/查的SQL语句，数据库的数据条数必然小于等于10万条,Redis的命令也是一样的，执行了10万条命令，也许数据库就只有5万条命令！一夫一妻：一夫多妻或一妻多夫在中国都是不合法的！所以尼，通过数据库当前的状态去生成新的命令，不就变成了一对一了吗？重写后的AOF日志对比当前的AOF日志不就变小了吗？
b. 疑问🤔️
- AOF重写会不会阻塞？
不会阻塞哦！每次重写时，主线程会fork出后台的bgrewriteaof子进程，子进程会拷贝父进程的页表，将页表的数据变成命令，并记录到新的AOF日志中。 - AOF重写时，新来的命令怎么办？
父进程会将新来的命令写到两个缓冲区，一个是当前日志对应的缓冲区，另一个是重写AOF日志对应的缓冲区
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
