Redis持久化方式AOF技术原理？一文带你从底层彻底吃透，Java开发面试基础

本文链接：https://blog.csdn.net/m0_65321095/article/details/122170137

Redis的AOF（Append Only File）持久化策略确保数据安全，通过appendfsync参数控制同步策略。默认每秒同步一次，兼顾性能和数据安全。AOF重写通过fork子进程生成新文件，减少文件体积，当文件大小超过一定比例或达到最小尺寸时触发。Redis在启动时优先加载AOF文件恢复数据，提供高一致性的数据保障。

摘要由CSDN通过智能技术生成

AOF配置

=====

在redis的redis.conf配置文件中：

=======================

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】完整内容开源分享

打开文件，找到 APPEND ONLY MODE 对应内容，默认情况下Redis没有开启AOF（append only file）方式的持久化，通过appendonly参数开启：

AOF文件的保存位置和RDB文件的位置相同

都是通过dir参数设置的

dir /path

redis 默认关闭，开启需要手动把no改为yes

appendonly yes

指定本地数据库文件名，默认值为 appendonly.aof

Bash

appendfilename “appendonly.aof”

Redis支持三种不同的刷写模式，Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制：每次有数据修改发生时都写入AOF文件中每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用appendfsync always **在一般的STAT硬盘上，Redis只能支持大约几百TPS写入，这是最安全也是最慢的方式，显然跟Redis高性能特性背道而驰，不建议配置。**每秒中同步一次，将过去一秒内发生的数据修改写入AOF文件中每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。appendfsync everysec **是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性，理论上只有在系统突然宕机的情况下丢失1s的数据。（严格来说最多丢失1s数据是不准确）**不主动同步，高效但是数据不持久化,由操作系统来决定完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。appendfsync no 由于操作系统每次同步AOF文件的周期，（即每30秒一次），而且会极大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证。

Redis服务的AOF文件同步策略：always (最安全但是最慢) ：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）everysec (默认的同步策略)：出厂默认推荐，每秒异步记录一次（默认值）no (最快但是不安全)：不同步
当进程中BGSAVE或BGREWRITEAOF命令正在执行时不阻止主进程中的fsync()调用（默认为no，当存在延迟问题时需调整为yes）.

no-appendfsync-on-rewrite no

虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正地写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来讲启用AOF持久化的应用都无法容忍这样的损失，这就需要Redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。

AOF重写机制

=======

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。

AOF重写原理

=======

重写后的AOF文件为什么可以变小？有如下原因：

进程内已经超时的数据不再写文件。
旧的AOF文件含有无效命令，如del key1、set a 111、set a 222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
多条写命令可以合并为一个，如lpush list a、lpush list b、 lpush list c 可以转化为：lpush list a b c。

为了防止合并的数据过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型，以64个元素为界拆分为多条。

AOF重写原理

=======

AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件。最后替换旧的aof文件。

需要压缩重写的案例：

==========

AOF带来了另一个问题，持久化文件会变得越来越大。比如，我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。
为了合并重写AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后，Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的合并重写（会将重写过程中接收的的新的指令和生成新的重写后AOF文件中的指令进行合并）。

注意:由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件

AOF重写目的

=======

AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。

AOF重写过程可以手动触发和自动触发：

===================

配置重写rewrite触发机制
手动触发：直接调用bgrewriteaof命令
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
auto-aof-rewrite-min-size: 限制了允许重写的最小AOF文件,通常在AOF文件很小的时候即使其中有些冗余命令也可是可以忽略的。
auto-aof-rewrite-percentage: 当前的AOF文件大小超过上一次重写的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF大小为依据。