Redis进阶（4）——结合redis.conf配置文件深入理解 Redis两种数据持久化方案：RDB和AOF

引出

1.Redis数据持久化的两种方式，RDB和AOF;
2.RDB采用二进制存储，速度快，但数据可能会丢失；
3.AOF命令追加，可读性强，数据准确，但文件较大，效率低；
4.结合redis.conf深入理解两种持久化方案；

持久化方案

RDB/AOF

RDB

以二进方式存储

存储信息到redis（内存），Fork 进程存储内存中的信息，何时触发存储的过程。

执行操作

COW（ copy-on-write）

AOF

使用文本方式存储写内容

RDB二进制的方式存储，AOF使用文本方式

默认情况：都启动

如果文件足够大？达到什么程度，如何处理？（rewrite)

Redis的持久化方案

redis4.0开始，配置上有些调整。

之前默认不打开AOF。

RDB

Redis Data base：内存快照

正常关闭，redis服务会存储最后一次修改

非正常关闭，redis会丢失未存储的数据。

开一个(fork)进程,后台执行存储。

docker run -it \
--name redis_6399 \
--privileged \
-p 6399:6379 \
--network pet_docker_net \
--ip 172.18.12.99 \
-v /etc/localtime:/etc/localtime \
-v /usr/local/software/redis/6399/conf/redis.conf:/usr/local/etc/redis/redis.conf \
-v /usr/local/software/redis/6399/data/:/data \
-v /usr/local/software/redis/6399/log/redis.log:/var/log/redis.log \
-d redis \
/usr/local/etc/redis/redis.conf

如果采用docker stop关闭

参数设置，30s内，写5次会触发

进入redis-cli，进行set操作，卡点30s

关闭6399

重新启动，发现数据都在

原因分析

如果采用强制关闭

[root@localhost ~]# ps au | grep redis-server
polkitd   14172  0.1  0.2  52812  9832 pts/7    Ssl+ 20:47   0:00 redis-server 0.0.0.0:6379
root      38838  0.0  0.0 112824   976 pts/15   S+   20:54   0:00 grep --color=auto redis-server
[root@localhost ~]# kill -9 14172
[root@localhost ~]#

出现数据丢失，以及原因分析

日志查看

AOF

日志方式存储非读命令.

参数设置

打开AOF

关于AOF的备份频率

参数解释

关于AOF的重写rewrite

达到64Mb的时候会rewrite，重写一下

混编方式的加载

数据加载顺序(混合方式)

读取aof
混编方式：在aof文件里面，既有aof，也有rdb；rdb在尾部，先被读出来；aof+rdb

1:M 09 Aug 2023 10:39:36.429 * Reading RDB preamble from AOF file...
1:M 09 Aug 2023 10:39:36.429 * Loading RDB produced by version 6.2.6
1:M 09 Aug 2023 10:39:36.429 * RDB age 6668 seconds
1:M 09 Aug 2023 10:39:36.429 * RDB memory usage when created 1.89 Mb
1:M 09 Aug 2023 10:39:36.429 * RDB has an AOF tail
1:M 09 Aug 2023 10:39:36.429 # Done loading RDB, keys loaded: 3, keys expired: 0.
1:M 09 Aug 2023 10:39:36.429 * Reading the remaining AOF tail...
1:M 09 Aug 2023 10:39:36.429 * DB loaded from append only file: 0.001 seconds
1:M 09 Aug 2023 10:39:36.429 * Ready to accept connections

appendonly yes

混编打开后，将AOF重写后文件大小变小

让aof进行重写

原本重写设置

后台命令让redis重写

查看日志

查看混编后的文件

两种持久化方案的优缺点

AOF优缺点

优点：数据准确	缺点：慢，文件大，效率低
默认是每秒fsync一次。这样最多丢失1秒数据	在相同的数据集下，AOF文件的大小一般会比RDB文件大。
AOF日志文件是一个纯追加的文件。就算服务器突然Crash，也不会出现日志的定位或者损坏问题	在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。
当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。
AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。

RDB优势和劣势

优势：快	劣势：数据可能有缺失
一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。	如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。	由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。