解剖AOF日志【打卡学废Redis】

---

“我发明了一句话，我说人的收入，是跟自己的不可替代性成正比的，你越不可代替你的收入越高，你越可以被替代，你的收入越低”——白岩松

---

AOF是Redis持久化机制之一，采用写后日志的方式来保存日志，通过Always、Everysec、No三种写回策略来减少数据丢失的风险，通过重写机制提高写入效率和实现快速恢复数据。

---

一. 写后日志

名称	概念	优势	风险
写前日志	先将数据记录到日志，再写入内存	便于故障时恢复数据
写后日志	先执行命令将数据写入内存，再记录日志	确保了只会记录正确的命令；不会阻塞当前的写操作	宕机可能丢失数据；可能会阻塞下一个操作

1. AOF为什么采用写后日志？
   
   AOF存的是命令，不是数据！故先执行命令，可保证存入到AOF日志的命令都是正确的！

2. 写后日志有哪些风险？
   执行完命令到将命令存入AOF日志是有时间差的，哪怕是0.0…001ms都是时间差！在此期间，机器宕机了，这期间的数据是不是就丢失了！！！
   执行命令和存入AOF日志都是通过主线程来操作的，当写入磁盘很慢时，造成当前操作阻塞，那么后续的操作也就会面临阻塞风险！！！

3. 如何规避写后日志带来的风险？
   写回策略+重写机制

---

二. 写回策略

写回策略	概念	优	缺
Always	同步写回：命令执行成功，便即刻写入磁盘	数据丢失的可能性极底	性能差
Everysec	每秒写回：命令执行成功，先写到内存缓冲区，再间隔一秒写到磁盘一次	性能适中	可能丢失
No	操作系统控制的写回：命令执行成功，先写到内存缓冲区，由操作系统决定写到磁盘的时间	性能好	数据丢失的可能性大

写回策略解决了什么问题？

1. 志在避免数据丢失和写入磁盘影响性能之间做取舍的策略。

---

三. 重写机制

1. 重写机制解决了什么问题？
   a. 随着写入AOF日志的命令越来越多，日志文件越来越大，导致写入效率变低！
   b. 日志文件太大，不利于数据恢复！
   ps：电脑打开一个有几十万数据的excel，是不是很卡？这就是文件太大了，严重影响了机器的性能！

2. 重写机制是怎么解决问题的？
   终极答案：将大文件变成小文件
   a. 解决思路🤔
   

   明确一点：再提醒一次，AOF日志存的是命令！不是数据！
   类比一哈：执行了10万次增/删/改/查的SQL语句，数据库的数据条数必然小于等于10万条,Redis的命令也是一样的，执行了10万条命令，也许数据库就只有5万条命令！
   一夫一妻：一夫多妻或一妻多夫在中国都是不合法的！所以尼，通过数据库当前 的状态去生成新的命令，不就变成了一对一了吗？重写后的AOF日志对比当前的AOF日志不就变小了吗？

   b. 疑问🤔️

   • AOF重写会不会阻塞？
     不会阻塞哦！每次重写时，主线程会fork出后台的bgrewriteaof子进程，子进程会拷贝父进程的页表，将页表的数据变成命令，并记录到新的AOF日志中。
   • AOF重写时，新来的命令怎么办？
     父进程会将新来的命令写到两个缓冲区，一个是当前日志对应的缓冲区，另一个是重写AOF日志对应的缓冲区

参考：蒋德钧老师的《Redis核心技术与实战》