Redis持久化：RDB和AOF（版本redis 7.0）

什么是持久化？

学过计算机基础的都知道以一种磁盘，只要关机，那么磁盘的内容都会被清空，这种磁盘称为内存，而Redis则是一种内存数据库，redis中的数据也都存储在磁盘中，如果服务器中进程被关掉，或者是计算机不小心宕机了，那么数据库的内容也就消失了，而持久化则是预防这种情况的发生，它主要的功能则是保存数据。

RDB（Redis Database）

它的执行流程为在执行时间间隔内将内存中的数据通过快照的方式写进磁盘中，这种方法也可以成为Snapshot快照，恢复数据时会将文件（RDB文件）恢复到内存中。这种快照的工作机制为Redi数据库会创建一个fork子进程，这个子进程会将内存中得到数据写入到一个临时文件中，通过持久化完成后，临时文件会更替上次产生的RDB文件，在整个持久化过程中，是不会进行io操作的，这样就确保了极高的性能。在持久化过程中可能出现的问题就是在Redis数据库中的最后一次操作可以会丢失。

fork子进程

Fork 的作用是复制一个与当前进程一样的进程。

新进程的所有数据（变量，环境变量，程序计数器等）数值都和原进程一致。

这是一个全新的进程，并作为原进程的子进程。

RDB 保存的是 dump.rdb 文件：

关于快照文件，在redis.conf配置文件中各种配置

配置一：

1. save 3600 1
2. save 300 100
3. save 60 10000

这是RDB快照触发的机制：

• 1 分钟内改了 1 万次
• 5 分钟内改了 10 次
• 15 分钟内改了 1 次

如果想禁用 RDB 持久化的策略，只要不设置任何 save 指令，或者给 save 传入一个空字符串参数也可以。

若要修改完毕需要立马生效，可以手动使用 save 命令，立马生效 。

stop-writes-on-bgsave-error

如果配置为 no，表示你不在乎数据不一致或者有其他的手段发现和控制，默认为 yes。

rbdcompression

对于存储到磁盘中的快照，可以设置是否进行压缩存储。

如果是的话，redis 会采用 LZF 算法进行压缩，如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能。

rdbchecksum

在存储快照后，还可以让 redis 使用 CRC64 算法来进行数据校验。

但是这样做会增加大约 10% 的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

默认为 yes。

RDB文件生成时的触发文件

1：按照配置文件执行，上面的触发机制

2：收到保存

        save：只管保存，其他不管，全部阻塞。

        bgsave：Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。

        lastsave：获取最后一次成功执行快照的时间。

3：执行flushall命令会触发RDB文件的生成机制

4：退出的时候也会产生RDB文件

如何恢复上次的数据呢？

将备份文件 dump.rdb 移动到 redis 安装目录并启动服务即可。

查看本地数据库目录：

 只需要将RDB文件放在redis文件夹下，那么开启服务的时候，redis会自动检查RDB文件，然后恢复其数据

 优点：

1：适合大规模的数据恢复

2：对数据的完整性和一致性不高时适用

缺点：

1：在一点的间隔时间进行一次备份，如果redis意外的宕机，会丢失最后一次快照后的所有数据

2：fork子进程，内存中的数据会被克隆一份，大概有2倍膨胀性需要进行考虑

AOF（Append Only File）

工作方法：通过日志方式来记录每个关于写的操作，将所有的redis指令全都记录下来（读记录则不会记录在日志文件中。

AOF文件只允许在文件的基础上追加内容，不允许进行改写文件，文件会在开启redis服务时，重新恢复数据。恢复工作则是将日志的文件全都执行一遍

注意：在redis默认的环境下则是不开启的，需要在配置文件进行配置开启服务。

关于AOF在配置文件中的配置

# 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种方式在许多应用中已经足够用了
appendonly no 
# appendfilename AOF 文件名称
appendfilename "appendonly.aof" 
# appendfsync aof持久化策略的配置：
#     no：不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
#     always：每次写入都执行fsync，以保证数据同步到磁盘。
#     everysec：每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec 
# 重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性
No-appendfsync-on-rewrite 
# 设置重写的基准值
Auto-aof-rewrite-min-size 
# 设置重写的基准值
Auto-aof-rewrite-percentage

开启AOF服务

开启AOF服务命令

127.0.0.1:6379> config set appendonly yes

ok

关闭RDB服务

127.0.0.1:6379> CONFIG set save ""    
OK

 创建三个key值

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK

重启服务

看看创建的键值是否还在

说明AOF成功 

 AOF配置

注意：在redis 7之后，AOF日志文件由一个aof文件变成一个文档，文档为appendonlydir文件
 
仅追加文件名是由Redis按照特定的模式创建的。 
文件名前缀是基于'appendfilename'配置的 
参数，后面是关于序列和类型的附加信息。

例如，如果appendfilename设置为appendonly。 Aof，下面的文件 
names可以被派生: 
appendonly.aof.1.base。 RDB作为基本文件。 
appendonly.aof.1.incr。 aof appendonly.aof.2.incr。 作为增量文件的Aof。 
将appendonly.aof.manifest作为一个manifest文件。在默认使用的持久化的优先级中，AOF的优先级比RDB高

为了aof文件出现一个问题，redis中有一个工具可以修复aof文档

如果你的配置都没有问题，但是就是连接不上redis数据库，就有可能就是aof日志文件有问题可以通过这个工具修复一下aof文件

 redis-cheak-aof --fix /usr/local/redis/appendonlydir/appendonly.aof.1.incr.aof 

 redis-cheak-aof就是那个工具，只要安装redis服务，就有这个工具

appendonly.aof.1.incr.aof 则是放在日志信息的文件在appendonlydir文件中修复它就可以进行正常的连接了