4.宕机-AOF日志,过于清楚了吧,结尾有升华

715 阅读10分钟

Redis内存KV数据库,一旦服务器宕机,内存中的数据将全部丢失 !

mysql数据库解决方案,从后端数据库恢复这些数据,存在的问题

问题一:频繁访问数据库,会给数据库带来巨大的压力
问题二:这些数据是从慢速数据库中读取出来的,性能肯定比不上从 Redis 中读取,导致使用这些数据的应用程序响应变慢

Redis 的持久化主两大机制,

AOF(Append Only File)日志和 RDB 快照

AOF解决

Redis 的写后日志,把数据写入内存之后,在写日志,和传统数据库的Write Ahead Log,WALl不同的是,wal是先写日志,后写库

Redis AOF操作过程.jpg

AOF 为什么要先执行命令再记日志呢?

###原因一:传统的数据库日志,例如redo log.重做日志,记录的是修改后的数据,而 AOF 里记录的是 Redis 收到的每一条命令,这些命令是以文本形式保存的。 例如 SET TESTKEY TESTVALUE,AOF中记录的内容是
SET TESTKEY TESTVALUE ->redis ->AOF

*3;
$3; 
set;
$7;
testkey;
$9;
testvalue; 
  • "*3" 表示当前命令有三个部分,每部分都是由“$+数字”开头,后面紧跟着具体的命令、键或值。

  • “数字” 表示这部分中的命令、键或值一共有多少字节

  • “$3 set” 表示这部分有 3 个字节,也就是“set”命令。

为了避免额外的检查开销,Redis 在向 AOF 里面记录日志的时候,并不会先去对这些命令进行语法检查。所以,如果先记日志再执行命令的话,日志中就有可能记录了错误的命令,Redis 在使用日志恢复数据时,就可能会出错。

写后日志这种方式,就是先让系统执行命令,只有命令能执行成功,才会被记录到日志中,否则,系统就会直接向客户端报错。所以,Redis 使用写后日志这一方式的一大好处是,可以避免出现记录错误命令的情况。

原因二:redis是在命令执行后才记录日志,所以不会阻塞当前的写操作。

AOF两个风险

风险一

如果刚执行完一个命令,还没有来得及记日志就宕机了,那么这个命令和相应的数据就有丢失的风险

风险二

AOF 虽然避免了对当前命令的阻塞,但可能会给下一个操作带来阻塞风险。这是因为,AOF 日志也是在主线程中执行的,如果在把日志文件写入磁盘时,磁盘写压力大,就会导致写盘很慢,进而导致后续的操作也无法执行

风险三

AOF如果文件过于大,恢复起来会特别特别慢,因为需要一行行的执行命令

三种写回策略

AOF 机制给我们提供了三个选择,也就是 AOF 配置项 appendfsync 的三个可选值
Always,同步写回:每个写命令执行完,立马同步地将日志写回磁盘;
Everysec,每秒写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘;
No,操作系统控制的写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。

针对避免主线程阻塞和减少数据丢失问题,这三种写回策略都无法做到两全其美。

“Always同步写回”可以做到基本不丢数据,但是它在每一个写命令后都有一个慢速的落盘操作,不可避免地会影响主线程性能;
“Everysec每秒写回”采用一秒写回一次的频率,避免了“同步写回”的性能开销,虽然减少了对系统性能的影响,但是如果发生宕机,上一秒内未落盘的命令操作仍然会丢失。所以,这只能算是,在避免影响主线程性能和避免数据丢失两者间取了个折中。
“No操作系统控制的写回”在写完缓冲区后,就可以继续执行后续的命令,但是落盘的时机已经不在 Redis 手中了,只要 AOF 记录没有写回磁盘,一旦宕机对应的数据就丢失了;

三种策略的写回时机,以及优缺点汇总:

配置 写回时机 优点 缺点
Always 同步写回 可靠性高,数据基本不丢失 每个命令都要落盘,性能影响较大
Everysec 每秒写回 性能适中 宕机时丢失1秒内的数据
NO 操作系统控制的写回 性能好 宕机时丢失数据较多
想要获得高性能,就选择 No 策略;
如果想要得到高可靠性保证,就选择 Always 策略;
如果允许数据有一点丢失,又希望性能别受太大影响的话,那么就选择 Everysec 策略。
按照系统的性能需求选定了写回策略,AOF 是以文件的形式在记录接收到的所有写命令,随着接收的写命令越来越多,AOF 文件会越来越大。 AOF 文件过大会带来的性能问题。

日志文件太大了怎么办?-- AOF 重写机制

AOF 重写机制就是在重写时,Redis 根据数据库的现状,创建一个新的 AOF 文件也就是说,读取数据库中的所有键值对,然后对每一个键值对用一条命令记录它的写入。
比如说,当读取了键值对“testkey”: “testvalue”之后,重写机制会记录 set testkey testvalue 这条命令。这样,当需要恢复时,可以重新执行该命令,实现“testkey”: “testvalue”的写入。

重写机制具有“多变一”功能,就是说,旧日志文件中的多条命令,在重写后的新日志中变成了一条命令。AOF 文件是以追加的方式,逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时,AOF 文件会记录相应的多条命令。 在重写的时候,是根据这个键值对当前的最新状态,为它生成对应的写入命令 图例:

AOF重写减少日志大小.jpg

AOF 重写会阻塞吗?

`AOF 日志由主线程`写回不同,重写过程是由后台子进程 bgrewriteaof 来完成的,这也是为了避免阻塞主线程,导致数据库性能下降。

重写的过程总结为“一个拷贝,两处日志”。

“一个拷贝”就是指:

每次执行重写时,主线程 fork 出后台的 bgrewriteaof 子进程。此时,fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程,这里面就包含了数据库的最新数据。然后,bgrewriteaof 子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,记入重写日志。

两处日志”就是指:

第一处:第一处日志就是指正在使用的 AOF 日志,Redis 会把这个操作写到它的缓冲区。这样一来,即使宕机了,这个 AOF 日志的操作仍然是齐全的,可以用于恢复。
第二处:日志,就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样,重写日志也不会丢失最新的操作,等到拷贝数据的所有操作记录重写完成后,重写日志记录的这些最新操作也会写入新的 AOF 文件,以保证数据库最新状态的记录。此时,我们就可以用新的 AOF 文件替代旧文件了。
总结:每次 AOF 重写时,Redis 会先执行一个内存拷贝,用于重写;然后,使用两个日志保证在重写过程中,新写入的数据不会丢失。而且,因为 Redis 采用额外的线程进行数据重写,所以,这个过程并不会阻塞主线程。

图示 :

AOF非阻塞的重写过程.jpg

什么时候会触发AOF 重写呢?有两个配置项在控制AOF重写的触发时机:

1. auto-aof-rewrite-min-size: 表示运行AOF重写时文件的最小大小,默认为64MB
2. auto-aof-rewrite-percentage: 这个值的计算方法是:当前AOF文件大小和上一次重写后AOF文件大小的差值,再除以上一次重写后AOF文件大小。也就是当前AOF文件比上一次重写后AOF文件的增量大小,和上一次重写后AOF文件大小的比值。

Redis采用fork子进程重写AOF文件时,潜在的阻塞风险包括:fork子进程 和 AOF重写过程中父进程产生写入的场景

a、fork子进程,fork这个瞬间一定是会阻塞主线程的(注意,fork时并不会一次性拷贝所有内存数据给子进程),fork采用操作系统提供的写实复制(Copy On Write)机制,
    就是为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题,但fork子进程需要拷贝进程必要的数据结构,其中有一项就是拷贝内存页表(虚拟内存和物理内存的映射索引表),这个拷贝过程会消耗大量CPU资源,
    拷贝完成之前整个进程是会阻塞的,阻塞时间取决于整个实例的内存大小,实例越大,内存页表越大,fork阻塞时间越久。拷贝内存页表完成后,子进程与父进程指向相同的内存地址空间,也就是说此时虽然产生了子进程,
    但是并没有申请与父进程相同的内存大小。那什么时候父子进程才会真正内存分离呢?“写实复制”顾名思义,就是在写发生时,才真正拷贝内存真正的数据,这个过程中,父进程也可能会产生阻塞的风险,就是下面介绍的场景。
b、fork出的子进程指向与父进程相同的内存地址空间,此时子进程就可以执行AOF重写,把内存中的所有数据写入到AOF文件中。但是此时父进程依旧是会有流量写入的,如果父进程操作的是一个已经存在的key,
    那么这个时候父进程就会真正拷贝这个key对应的内存数据,申请新的内存空间,这样逐渐地,父子进程内存数据开始分离,父子进程逐渐拥有各自独立的内存空间。因为内存分配是以页为单位进行分配的,
    默认4k,如果父进程此时操作的是一个bigkey,重新申请大块内存耗时会变长,可能会产阻塞风险。另外,如果操作系统开启了内存大页机制(Huge Page,页面大小2M),那么父进程申请内存时阻塞的概率将会大大提高,所以在Redis机器上需要关闭Huge Page机制。Redis每次fork生成RDB或AOF重写完成后,都可以在Redis log中看到父进程重新申请了多大的内存空间。

Huge page在实际使用Redis时是建议关掉。

Huge page对提升TLB命中率比较友好,因为在相同的内存容量下,使用huge page可以减少页表项,TLB就可以缓存更多的页表项,能减少TLB miss的开销。
但是,这个机制对于Redis这种喜欢用fork的系统来说,的确不太友好,尤其是在Redis的写入请求比较多的情况下。因为fork后,父进程修改数据采用写时复制,复制的粒度为一个内存页。
如果只是修改一个256B的数据,父进程需要读原来的内存页,然后再映射到新的物理地址写入。一读一写会造成读写放大。如果内存页越大(例如2MB的大页),那么读写放大也就越严重,对Redis性能造成影响。