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 的单线程设计,这些命令操作只能一条一条按顺序执行,这个“重放”的过程就会很慢了