Redis持久化方式AOF技术原理？一文带你从底层彻底吃透，mysql数据库优化面试

最新推荐文章于 2023-06-16 15:37:36 发布

m0_64205676

最新推荐文章于 2023-06-16 15:37:36 发布

阅读量165

点赞数

分类专栏：程序员文章标签：面试 java 后端

本文链接：https://blog.csdn.net/m0_64205676/article/details/121313438

版权

程序员专栏收录该内容

51 篇文章 1 订阅

订阅专栏

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

打开文件，找到 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

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

浏览器打开：qq.cn.hn/FTf 开源分享

持久化的应用都无法容忍这样的损失，这就需要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大小为依据。

注意，执行AOF重写请求时，父进程依然响应命令，Redis使用"AOF重写缓冲区"保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。

CSS

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

解释含义：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了， 这里的“一倍”和“64M” 可以通过配置文件修改。

AOF与RDB二者选择的标准（结合上一篇文章）

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

权衡的标准是对数据的一致性要求和性能之间的平衡。看系统是愿意牺牲一些性能，换取更高的缓存一致性（AOF），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（RDB）。

AOF的执行流程

========

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。

AOF的工作流程操作有：

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

命令写入（append）
文件同步（sync）
文件重写（rewrite）
重启加载（load）

AOF流程如下：

========

所有的写入命令会追加到aof_buf（缓冲区）中。
AOF缓冲区根据对应的策略向硬盘做同步操作。
随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
当Redis服务重启时，可以加载AOF文件进行数据恢复。

AOF重启加载

=======

**AOF和RDB文件都可以用于服务器重启时的数据恢复。**AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件城后，Redis启动成功；AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

根据AOF文件恢复数据

===========

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复。从下面的操作演示中体会。

若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，

留一后手。AOF出问题了，还有RDB。

AOF 的优缺点

========

AOF 优点

======