Redis的AOF持久化机制

本是古典何须时尚 2022-08-28 13:50 127阅读 0赞

### 文章目录 ###

*  1、AOF是什么？
 *  2、AOF持久化流程
 *  2、AOF配置文件的说明
 *   *  2.1 AOF默认是不开启的
     *  2.2 AOF启动/修复/恢复
     *  2.3 AOF同步频率设置
     *  2.4 Rewrite压缩
     *   *  2.4.1 重写原理，如何实现重写
         *  2.4.2 重写流程
 *  3、AOF持久化实战
 *   *  3.1 启动redis服务并用客户端连接
     *  3.2 设置几个键值对
     *  3.3 模仿断电，我们直接shutdown关闭redis服务器
     *  3.4 再次打开redis服务器并用客户端连接
     *  3.5 测试持久化是否成功(查看断电之前的数据还在不在)
     *  3.6 修复appendonly.aof文件

Redis提供了两种持久化的方式，分别是AOF(Append Only File，只追加文件)和RDB(Redis DataBase,基于Redis数据库)。

# 1、AOF是什么？ #

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

# 2、AOF持久化流程 #

（1）客户端的请求写命令会被append追加到AOF缓冲区内；  
（2）AOF缓冲区根据AOF持久化策略\[always,everysec,no\]将操作sync同步到磁盘的AOF文件中；  
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；  
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；  
![在这里插入图片描述][5c90bb114245477a88ec89f6e92196e9.png_pic_center]

# 2、AOF配置文件的说明 #

## 2.1 AOF默认是不开启的 ##

可以在redis.conf配置文件里修改appendonly参数来开启。  
也可以设置配置文件名称，默认为appendonly.aof。  
AOF文件的保存路径，同RDB的路径一致。  
![在这里插入图片描述][d7569b1104204065aa757f55bcef2528.png]

## 2.2 AOF启动/修复/恢复 ##

*  AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

**正常恢复**

*  修改默认的appendonly no，改为yes
 *  将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
 *  恢复：重启redis然后重新加载

**异常恢复**

*  修改默认的appendonly no，改为yes
 *  如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
 *  备份被写坏的AOF文件
 *  恢复：重启redis，然后重新加载

## 2.3 AOF同步频率设置 ##

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

## 2.4 Rewrite压缩 ##

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令`bgrewriteaof`

### 2.4.1 重写原理，如何实现重写 ###

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。  
  可以通过如下三个参数来定义重写时的策略。  
  **no-appendfsync-on-rewrite：** 如果 `no-appendfsync-on-rewrite=yes` ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）如果 `no-appendfsync-on-rewrite=no`, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）  
  **auto-aof-rewrite-percentage：** 设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）  
  **auto-aof-rewrite-min-size：** 设置重写的基准值，最小文件64MB。达到这个值开始重写。

### 2.4.2 重写流程 ###

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。  
（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。  
（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof\_buf缓冲区和aof\_rewrite\_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。  
（4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof\_rewrite\_buf中的数据写入到新的AOF文件。  
（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_9_color_FFFFFF_t_70_g_se_x_16_pic_center]

# 3、AOF持久化实战 #

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_17_color_FFFFFF_t_70_g_se_x_16]

## 3.1 启动redis服务并用客户端连接 ##

redis-server redis.conf
     redis-cli

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_20_color_FFFFFF_t_70_g_se_x_16]

## 3.2 设置几个键值对 ##

![在这里插入图片描述][afc83dfff69844f794aa59a00a3378d7.png]  
查看appendonly.aof  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_18_color_FFFFFF_t_70_g_se_x_16]

## 3.3 模仿断电，我们直接shutdown关闭redis服务器 ##

![在这里插入图片描述][ed8bc2ec3491430fabbfc7cfa66058b6.png]

## 3.4 再次打开redis服务器并用客户端连接 ##

![在这里插入图片描述][5c27393f055346ac9940def100244ad3.png]

## 3.5 测试持久化是否成功(查看断电之前的数据还在不在) ##

![在这里插入图片描述][c3d9bfbd37964e7a8c327592b9df9287.png]  
  可以看到，持久化机制已经生效，每秒会同步持久化文件，是因为我们配置文件中的持久化策略为 `appendfsync everysec`  
![在这里插入图片描述][e9503cbd2ad343ef94c0269a01ae1f5a.png]

## 3.6 修复appendonly.aof文件 ##

如果appendonly.aof文件损坏怎么办呢？

redis-check-aof --fix appendonly.aof

![在这里插入图片描述][9ce2b4f954e8413a9b3d8abfb3ffc45c.png]

[5c90bb114245477a88ec89f6e92196e9.png_pic_center]: /images/20220828/56a7643587194342be48efb675b9c544.png
[d7569b1104204065aa757f55bcef2528.png]: /images/20220828/37024ca0c0ae4e7291cd4b3cac4ba2e2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_9_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220828/9427f987dee84946825405b685947505.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_17_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/6eec9be963e8455b947640efa243e745.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/d5c1b27c13a54ec380d881214bdd6918.png
[afc83dfff69844f794aa59a00a3378d7.png]: /images/20220828/3e2b94b16f0d49588ddb168af90f6caf.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Yir5Zui562Jc2h55ZOl5Y-R6IKy_size_18_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/a61214daa74c4746958d5520043755f6.png
[ed8bc2ec3491430fabbfc7cfa66058b6.png]: /images/20220828/a2e099744ba740d8b8e243ad50cef61f.png
[5c27393f055346ac9940def100244ad3.png]: /images/20220828/42e3a0fa6eab4375b1ef69a1939dfe6a.png
[c3d9bfbd37964e7a8c327592b9df9287.png]: /images/20220828/a0a29a0cc716483c9e65f4519392200f.png
[e9503cbd2ad343ef94c0269a01ae1f5a.png]: /images/20220828/6e6b2069cb77418b8e1633968cfd38c7.png
[9ce2b4f954e8413a9b3d8abfb3ffc45c.png]: /images/20220828/e8f415e46d8641a186f57ed984244201.png