十五、Redis之AOF

偏执的太偏执、 2022-05-16 02:12 148阅读 0赞

\#                                    Redis之AOF

Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File)

\#\#\#1、RDB缺点  
![这里写图片描述][70]  
![这里写图片描述][70 1]

\#\#\#2、AOF原理

![这里写图片描述][70 2]

![这里写图片描述][70 3]  
  
  
\#\#\#3、AOF之always策略恢复

![这里写图片描述][70 4]

\#\#\#4、AOF之everysec策略恢复

![这里写图片描述][70 5]

\#\#\#5、AOF之no策略恢复

![这里写图片描述][70 6]

\#\#\#6、AOF策略比较 !\[这里写图片描述\](https://img-blog.csdn.net/20180814144305250?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25ld2JpZV85MDc0ODY4NTI=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70)  
\#\#\#7、AOF重写作用

![这里写图片描述][70 7]

![这里写图片描述][70 8]

![这里写图片描述][70 9]

![这里写图片描述][70 10]

AOF文件增长率：达到这个增长率我们就进行重写  
下图是增长率计算方式。  
![这里写图片描述][70 11]

![这里写图片描述][70 12]

############################## APPEND ONLY MODE ###############################
    #默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
    appendonly no
    
    #aof文件名
    appendfilename "appendonly.aof"
    
    #aof持久化策略的配置
    #no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
    #always表示每次写入都执行fsync，以保证数据同步到磁盘。
    #everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
    appendfsync everysec
    
    # 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。
    #fsync策略：always、everysec、no
    #这个配置，就是在重写的过程中是否需要继续fsync策略的append操作，yes表示不进行append，no表示进行append（消耗io）
    #重写过程消耗大量io，这是否是否任然选择往重写文件中append，append则不丢失数据，不append，则丢失数据
    no-appendfsync-on-rewrite no
    
    #aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
    auto-aof-rewrite-percentage 100
    #设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
    auto-aof-rewrite-min-size 64mb
    
    #aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
    aof-load-truncated yes

\`\`\` \#这个配置，就是在重写的过程中是否需要继续fsync策略的append操作，yes表示不进行append，no表示进行append（消耗io） \#重写过程消耗大量io，这是否是否任然选择往重写文件中append，append则不丢失数据，不append，则丢失数据 \#重写完成后 ，子进程会将新的命令append，当重写失败，这时候子进程无法append no-appendfsync-on-rewrite no \`\`\` ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25ld2JpZV85MDc0ODY4NTI_size_16_color_FFFFFF_t_70_pic_center][]

[70]: /images/20220516/67f0d2c2f6f3452c9651a088c191efa3.png
[70 1]: /images/20220516/db093a23b3e248109d2cace15b977568.png
[70 2]: /images/20220516/0ef5de035d404951ab6ba7fde075d357.png
[70 3]: /images/20220516/a57700295e2e4b9eb4358ae10ea86101.png
[70 4]: /images/20220516/4ae651d9268445ce83bc960b915b5d8c.png
[70 5]: /images/20220516/700df3406a854ada8219340015e5f1a6.png
[70 6]: /images/20220516/92a64184e79b446987b5295f5cdf60c6.png
[70 7]: /images/20220516/1aa0418433564cc8ab98580c8f45a9cf.png
[70 8]: /images/20220516/88529ded6da7414ba1bdc0a4f03e8028.png
[70 9]: /images/20220516/e35afb070d9a411c9b26eec834d1fed8.png
[70 10]: /images/20220516/0e29b7fe74514c54b5049daaf18cc475.png
[70 11]: /images/20220516/fc761914c2fa414eb964f46b020b3ad5.png
[70 12]: /images/20220516/5c10425de36942f1ac74bfb9d390d67e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25ld2JpZV85MDc0ODY4NTI_size_16_color_FFFFFF_t_70_pic_center]: /images/20220516/45551576cb1c4b158acf7a9de37aa90b.png