1.AOF日志如何实现
- 一旦服务器宕机，内存中的数据全部丢失
- 解决办法
+ 从后端数据库恢复数据
- 对数据压力巨大（缓存雪崩）
- 导致请求延时增加- redis持久化方案\
+ AOF（Append Only File）日志
+ RDB快照- 数据的写前日志（Write Ahead Log, WAL），先写日志，数据库崩溃后可以根据日志进行恢复
+ redo log重做日志，记录修改后的数据（直接保存数据）- AOF日志刚好相反，是写后日志，把数据写入内存后才记录日志（因为避免检查开销，redis向AOF写日志时避免指令检查）（命令执行成功后写）（不会阻塞当前操作！！！）
+ 记录的是redis的命令，以文本的形式保存
+ set testkey testvalue
+ \*3”表示当前命令有三个部分\
+ 每部分都是由“$+数字”开头，后面紧跟着具体的命令、键或值- 潜在的风险
+ 执行完命令后宕机，命令和数据有丢失风险\
- 如果不能通过数据库恢复，就无法恢复了
+ 执行完命令后，写磁盘导致的阻塞
+ 调优方向：redis同步到磁盘的操作
2.三种写回策略
- Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘\
+ 数据基本不丢失
+ 落盘操作影响主线程- Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘\
+ 其他两种的折中方案
+ 数据量控制在1s以内
+ 主线程性能和避免数据丢失取了一个折中- No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘\
+ 落盘时机由操作系统掌控，数据丢失不太清楚
3.日志文件太大怎么办
- 随着AOF文件越来越大，存在AOF的性能问题
+ 文件系统对文件大小的控制，无法保存过大文件
+ 文件太大，之后追加命令效率会变低
+ 文件太大导致回放慢- AOF重写机制
+ 根据现状创建一个新的AOF文件
+ 重写机制具有多变一的功能，旧日志的多条记录合并成一条命令- 即使重写后的日志也很大，会导致主线程的阻塞吗？
4.AOF重写会阻塞吗
- 重写过程是由后台子进程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降\
- 重写的过程总结为“一个拷贝，两处日志”\
- “一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。\
5.总结
- 所有的设计都是配套的（写后日志+回放+聚合操作）
- 它提供了 AOF 日志的三种写回策略，分别是 Always、Everysec 和 No\
- 为了避免日志文件过大，Redis 还提供了 AOF 重写机制，直接根据数据库里数据的最新状态，生成这些数据的插入命令\
- 三种写回策略体现了系统设计中的一个重要原则 ，即 trade-off，或者称为“取舍”，指的就是在性能和可靠性保证之间做取舍\
- Redis 的单线程设计，这些命令操作只能一条一条按顺序执行，这个“重放”的过程就会很慢了
本文转载自: 掘金