美文网首页Redis
三、Redis避免数据丢失之AOF(Append Only Fi

三、Redis避免数据丢失之AOF(Append Only Fi

作者: 龚志丹 | 来源:发表于2020-11-02 13:56 被阅读0次

    AOF日志是如何实现的?

    注意点:AOF是写后(Redis 是先执行命令,把数据写入内存,然后才记录日志)日志,避免出现记录错误命令的情况。

    Redis AOF操作过程

    AOF日志都记录了什么?

    AOF日志内容

    如上图,redis执行set testkey testvalue为例,“*”表示当前命令有三个部分,每部分都是由“$+数字”开头,后面紧跟着具体的命令、键或值。“数字”表示这部分中的命令、键或值一共有多少字节。
    *3:执行的命令有3部分
    $3:命令有3个字节
    $7:键有7个字节
    $9:值有9个字节

    潜在风险?

    因为AOF采用写后方式,存在以下场景:

      1. 如果命令执行后,还没写日志,Redis宕机了怎么办?
        导致数据丢失。
      1. 如果磁盘IO性能很慢,是不是就影响了后续操作?
        导致主线程阻塞,影响后续操作无法执行。

    以上问题Redis提供了三种写回策略,便于根据实际场景选择。

    AOF三种写回策略

    • Always,同步写回(每个写命令执行完,立马同步地将日志写回磁盘)
    • No,操作系统控制的写回(每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘)
    • Everysec,每秒写回(每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘)

    围绕两方面思考点出发,1.避免主线程阻塞 2.减少数据丢失,那这三种都无法做到两全其美。

    • Always,同步写回。基本可以做到不丢失数据,但是它在每一个写命令后都有一个慢速的落盘操作,不可避免地会影响主线程性能;
    • No,操作系统控制写回。落盘的时机在于操作系统,如果操作系统没执行写回就会导致数据全盘丢失。
    • Everysec,每秒写回。相比Always减少性能开销,不需要每一个命令都去写入磁盘。相比No,如果发生Redis宕机也只会丢失1秒数据,等于两者做了个折中处理。


      写回策略优缺点对比

    场景选择建议

    • 获得高性能,选择No策略;
    • 获得高可靠性保证,选择Always策略;
    • 允许数据有一点丢失,性能不受太大影响,选择Everysec策略。

    日志文件大了会有哪些影响?

    需要注意的是如果随着时间和数据量的推移,日志文件会越来越过大,这会影响一些额外性能问题。

    • 操作系统无法保存大日志文件
    • 文件过大带随之写入的性能降低
    • 恢复数据时,AOF 中记录的命令要一个个被重新执行,用于故障恢复,如果过大,Redis恢复时较慢

    AOF重写机制

    重写机制就是“多变一”(旧日志文件中的多条命令,在重写后的新日志中变成了一条命令)。如图:


    AOF重写机制

    重写会产生:一个拷贝两处日志(原日志和重写过程中的日志)

    重写过程扩展阅读,这里需要慢慢消化了

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

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

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

    相关文章

      网友评论

        本文标题:三、Redis避免数据丢失之AOF(Append Only Fi

        本文链接:https://www.haomeiwen.com/subject/wgapvktx.html