Redis持久化之AOF

1.什么是redis的AOF

AOF (Append Only File) 是 Redis 使用的一种持久化方式，它以日志的形式记录了所有对Redis服务器进行写操作的命令。AOF 文件是一个只进行追加写入的文件，其中包含了一系列写命令，这些命令以 Redis 协议格式进行存储。

2.redis的AOF能干吗

使用 AOF 机制的 Redis 服务器在执行命令的同时，会将这些执行的写操作命令追加写入到 AOF 文件中。Redis 在重启的时候会通过加载 AOF 文件中的命令来重新构建数据集，因此 AOF 文件可以用来在服务器重启时恢复数据。

3.redis的AOF触发机制

修改redis的配置文件，找到appendonly关键字 将对应的值设置为yes，开启redis的aof持久化，重启redis服务。

需要注意的是，这里的aof文件保存位置是 dir + appenddirname

通过该配置，决定了我的aof文件保存路径是：/SDXL/wjz/redis/redis_rdb/appendonlydir/

这里还需要关注的一个点

当你开启redis的aof持久化功能，并重启redis服务的时候
redis就自动生成了appendonlydir文件夹
appendonlydir文件夹里面的文件有三个
分别是
appendonly.aof.1.base.rdb文件：实际上是基于快照的 AOF 文件的初始 RDB 文件。这个文件包含了 Redis 数据库在重新启动时的初始快照信息，被用于加速数据库的启动过程。
appendonly.aof.1.incr.aof文件：记录redis客户端所有的写操作
appendonly.aof.manifest文件：记录 AOF 文件的元数据信息的。这些元数据信息包括 AOF 文件的相关属性、版本信息、创建时间等。这样，当 Redis 重新加载 AOF 文件时，它可以快速地检索这些元数据并进行相关的处理。
如果你手动把这个文件夹删掉，redis不会再生成appendonlydir文件夹了，这就意味着你执行写入操作的时候，不会有对应的aof文件生成

接下来开始验证aof

连接redis客户端，执行set k1 v1
我们发现，appendonly.aof.1.incr.aof文件大小由0增加到了52

接着再执行set k2 v2
再看一下appendonly.aof.1.incr.aof文件大小，又增大了

接着再执行get k1操作，我们发现appendonly.aof.1.incr.aof文件大小不变
因此我们可以得出结论：appendonly.aof.1.incr.aof文件只记录redis客户端的写操作
此时我们使用kill -9命名模拟服务器宕机，然后重启redis服务器，发现之前的k1 k2数据依旧保存在redis内存中

4.AOF的工作流程与写回策略

1.客户端执行读写操作（再次强调，AOF文件只会记录写操作）
2.redis服务端将写操作记录到AOF缓冲区
3.根据配置的写回策略，将AOF缓冲区的写指令记录到AOF文件中
4.当AOF文件达到了配置文件中重写的条件时，会进行AOF文件的重写

所谓的写回策略，其实就是从AOF缓冲区写入AOF文件的三种形式

1.always ：每一次写操作，都立刻写入到AOF文件中
2.everysec：每秒执行一次从AOF缓冲区写入到AOF文件的操作
3.no：所有的写操作都记录到AOF缓冲区，但是何时从AOF缓冲区写入到AOF文件，由操作系统决定
这里的always 和 everysec 有点像mysql的批量插入
always 就是一条一条的插入，100条数据，执行插入操作100次。
everysec是批量插入，100条数据，执行1次插入操作
这里有一点需要注意
将AOF缓冲区的数据写入到AOF文件的操作不是redis的主进程执行的操作，是redis服务fork的子进程来操作的，这种方式可以避免阻塞主线程，提高了Redis的性能和稳定性。

5.AOF文件的重写机制

这里为什么要有AOF文件的重写机制呢?
AOF文件记录了所有的写操作指令，可以用来恢复数据。但是随着时间的推移，AOF文件会不断增大，造成存储空间的浪费和读写性能的下降
为了解决这些问题，Redis引入了AOF的重写机制。
通过AOF重写可以将AOF文件重新生成，去除冗余的指令，同时优化文件结构，减少碎片化，提升文件的读写性能。重写过程中还可以对指令进行合并和优化，进一步减小AOF文件的大小，降低存储成本。

比如说我们在某个时刻，对键k1 set了100次，那么，AOF文件是不是只记录最后一次对k1 set的值就可以了呢？这样将100次写入请求合并到1次，就可以减少AOF文件的大小了。

在redis的配置文件中配置当AOF文件达到多大时触发AOF重写机制
默认是64MB，这里我为了方便验证，将大小修改为1kb

先看一下AOF增量文件的初始大小，为0kb
同时注意一下，前两个文件的名称，分别是appendonly.aof.1.base.rdb和appendonly.aof.1.incr.aof
接着我们连接redis客户端，执行set操作
set k1 1111111111111111111111111111111111111111111111111111111111111
多执行几遍，注意观察appendonly.aof.1.incr.aof文件的大小，直到超过了我设置的1kb
神奇的事情发生了

当aof文件超过了1kb之后，进行了aof文件的重写，重写过的aof文件变成了appendonly.aof.2.base.rdb同时又新生成了一个appendonly.aof.2.incr.aof文件记录增量的写操作。

6.AOF文件的重写原理

AOF重写机制的原理是根据当前内存中的数据库状态，生成一个新的AOF文件，新的AOF文件包含了恢复当前数据库状态所需的最少命令操作，因此新生成的AOF文件会比旧的AOF文件更小。生成过程完全在后台执行，不会影响Redis的正常运行。
AOF文件的重写依赖于以下两个条件：
Redis会记录一个起始的偏移量,之后每次有写操作都会记录到重写缓存中;
后台进程会根据起始偏移量来重新生成AOF文件，该重写的过程与文件大小有关。
AOF重写机制的好处是可以减小AOF文件的体积，提高了性能和文件的可读性。
重写缓存指的并不是AOF缓冲区。AOF重写是一个独立的过程，它使用后台进程通过扫描数据库的方式来创建新的AOF文件。在重写期间，Redis会继续将写命令追加到AOF缓冲区，并将这些写命令保存到AOF重写缓冲区中。
AOF重写缓冲区是一个用于暂时存储写命令的缓冲区，它会在AOF重写完成后将数据写入到新的AOF文件中。通过这个机制，Redis可以避免在AOF重写期间丢失任何写命令。
所以，重写缓存并不是指 AOF 缓冲区，而是指 AOF 重写过程中使用的临时缓存区域。

7.AOF持久化的优点

数据安全性更高：AOF文件记录了每个写操作（追加方式），因此即使Redis服务器意外宕机，也能通过重新执行AOF文件中的命令来恢复数据，极大地降低数据丢失的概率。
更好的数据一致性：AOF文件记录了写操作，因此在数据恢复时可以更好地保持数据一致性，使得恢复后的数据库状态更接近宕机前的状态。
更适合在意外宕机后的数据恢复：AOF文件记录的是增量数据，因此在发生意外宕机后，Redis可以更快速地从AOF文件中恢复出一个较新的数据库状态，而不需要像RDB那样执行完整的加载和解析快照文件。
可读性更高：AOF文件是一个文本文件，记录了Redis的写命令，因此更容易理解和查看数据库操作历史。
总的来说，AOF持久化的优点体现在数据安全性更高、恢复速度更快、数据一致性更好、且对于故障恢复更友好。这些优点使得AOF持久化成为许多Redis用户默认的持久化方式。

8.AOF持久化的缺点

文件体积较大：AOF文件记录了每个写操作，因此在一定时间内，AOF文件可能会变得非常大。这可能会对磁盘空间产生一定的压力，尤其是在高写入负载的情况下。
恢复速度相对较慢：由于AOF文件记录了每个写操作，因此在恢复数据库时需要重新执行AOF文件中的所有写入操作。在AOF文件较大时，这可能会导致数据恢复的速度相对较慢。
对磁盘的频繁写入：AOF持久化通常会导致对磁盘的频繁写入，这可能会减少磁盘的使用寿命。

9.隐藏彩蛋之aof文件里面的内容长这样

使用vim命令我们打开appendonly.aof.1.incr.aof文件，我们可以看到里面的内容。
使用的0号库（select 0）
执行的写入操作是为键k1设置值9999999999999999999999999
文件里面的* $这是基于redis协议生成的内容，无需关注

10.我在生产环境执行了flushdb操作，我该怎么办？？？？？

如果你在生产环境执行了flushdb或者flushall操作，碰巧你使用的redis开启了aof缓存，碰巧你执行完flush命名之后没触发aof文件的重写，那么，恭喜你还有救，否则的话，请去自首。
flushdb和flushall也是写入操作，所以aof文件会记录
我们先连接redis客户端，执行命令
set k1 v1
set k2 v2
flushdb
然后我们vim appendonly.aof.1.incr.aof文件

我们可以看到aof文件中记录了flushdb命令
此时因为我们已经执行了flushdb命令，所以redis内存中的数据已经不存在了
接下来，顶级操作
我们把appendonly.aof.1.incr.aof文件中的记录的flushdb命令删除掉，然后保存
重启redis
奇迹出现了，我们的k1 k2恢复了。