Redis AOF

Redis AOF持久化详解

转载：https://blog.csdn.net/qq_42183409/article/details/90215479

redis中aof备份策略中的配置参数

转载：https://blog.csdn.net/zdyueguanyun/article/details/54376815

Redis的AOF配置

转载：https://blog.csdn.net/m0_38086372/article/details/107432480

AOF 重写
　　由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof 来重写。

　　也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。

 　　AOF 文件重写触发机制：通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage：默认值为100，以及auto-aof-rewrite-min-size：64mb 配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

　　这里再提一下，我们知道 Redis 是单线程工作，如果 重写 AOF 需要比较长的时间，那么在重写 AOF 期间，Redis将长时间无法处理其他的命令，这显然是不能忍受的。Redis为了克服这个问题，解决办法是将 AOF 重写程序放到子程序中进行，这样有两个好处：

　　①、子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其他命令。

　　②、子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

　　使用子进程解决了上面的问题，但是新问题也产生了：因为子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的 AOF 文件状态不一致。

　　为了解决这个数据状态不一致的问题，Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。

　　这样将 AOF 重写对服务器造成的影响降到了最低。
 

redis中aof备份策略中的配置参数

在使用redis时，都会配置相应的存储策略，以保证redis并不会由于意外挂掉，在短时间内重启时数据不会消失。在当前的版本中,redis提供了bgsave和aof两种策略，本文主要描述了aof中的相关参数以及为什么这样是可以足够安全的。本文的描述主要参考redis的conf文件以及各项网络

appendonly

开启aof特性，这个控制是否启用aof.

appendfilename

写入文件的文件名。开启aof之后，每条命令(除读之外的命令)，均会写入到文件中,这里即实际写入的文件.

appendfsync

写入策略，默认值everysec，每秒写一次(调用flush)。另外两个值，always | no,分别表示每次redis写命令之外就写文件，和由操作系统保证。always对硬盘压力大，everysec是一个平衡值,no对硬盘压力最小，但调度由系统控制，丢失数据风险最大.

no-appendfsync-on-rewrite

是否在后台写时同步单写，默认值no(表示需要同步).这里的后台写，表示后台正在重写文件(包括bgsave和bgrewriteaof.bgrewriteaof网上很多资料都没有涉及到。其实关掉bgsave之后，主要的即是aof重写文件了).no表示新的主进程的set操作会被阻塞掉，而yes表示新的主进程的set不会被阻塞，待整个后台写完成之后再将这部分set操作同步到aof文件中。但这可能会存在数据丢失的风险(机率很小)，如果对性能有要求，可以设置为yes，仅在后台写时会异步处理命令.

auto-aof-rewrite-percentage

aof文件增长比例，指当前aof文件比上次重写的增长比例大小。aof重写即在aof文件在一定大小之后，重新将整个内存写到aof文件当中，以反映最新的状态(相当于bgsave)。这样就避免了，aof文件过大而实际内存数据小的问题(频繁修改数据问题).

• 作用： 自动触发AOF重写

auto-aof-rewrite-percentage 100 # 触发重写百分比 （指定百分比为0，将禁用aof自动重写功能）
auto-aof-rewrite-min-size 64mb # 触发自动重写的最低文件体积（小于64mb不自动重写）

Redis能够在AOF文件大小增长了指定百分比时，自动隐式调用 BGREWRITEAOF 命令进行重写。

这里是它如何工作的说明：

（1）Redis记录上一次执行AOF重写后的文件大小作为基准。（如果启动后没有发生过重写，则使用启动时的AOF文件大小）。
（2）将该基准值与当前文件大小进行比较，如果当前体积超出基准值的指定百分比，将触发重写。
另外你还需要指定要重写的AOF文件的最小体积（auto-aof-rewrite-min-size），这可以避免在文件体积较小时多次重写。

如果指定百分比为0，将禁用AOF自动重写功能

auto-aof-rewrite-min-size

aof文件重写最小的文件大小，即最开始aof文件必须要达到这个文件时才触发，后面的每次重写就不会根据这个变量了(根据上一次重写完成之后的大小).此变量仅初始化启动redis有效.如果是redis恢复时，则lastSize等于初始aof文件大小.

aof-load-truncated

指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败.

Linux内核参数

另外，与aof重写相关的一个linux内核参数即是 overcommit_memory。即在进行重写时，如何分配子进程内存的问题。(重写是后台重写，会分配子进程).默认值为0,建立设置为1,以保证 子进程内存能够分配成功(即使用copyOnWrite内存分配策略，在没有set命令时会和主进程使用同一份内存)，并且不会判断当前内存是否够用.