09-Redis的持久化机制

一种是RDB快照（RedisDataBase），一种是AOF（AppendOnlyFile）

01、RDB

RDB是Redis默认的持久化方案。当满足一定条件的时候，会把当前内存中的数据写入磁盘，生成一个快照文件dump.rdb。Redis重启会通过加载dump.rdb文件恢复数据。

【1】、自动触发

配置redis.conf规则触发。

如果不需要RDB方案，注释save或者配置成空字符串""。

注意上面的配置是不冲突的，只要满足任意一个都会触发

【2】、RDB文件位置和目录

参数	说明
dir	rdb文件默认在启动目录下（相对路径） config get dir获取
dbfilename	文件名称
rdbcompression	开启压缩可以节省存储空间，但是会消耗一些CPU的计算时间，默认开启
rdbchecksum	使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

 

【3】、为什么停止Redis服务的时候没有save，重启数据还在？

RDB还有两种触发方式：

• shutdown触发，保证服务器正常关闭。
• flushall，RDB文件是空的，没什么意义（删掉dump.rdb演示一下）。

 【4】、手动触发

如果我们需要重启服务或者迁移数据，这个时候就需要手动触RDB快照保存。

1、save

save在生成快照的时候会阻塞当前Redis服务器，Redis不能处理其他命令。如果内存中的数据比较多，会造成Redis长时间的阻塞。生产环境不建议使用这个命令。

2、bgsave

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

具体操作是Redis进程执行fork操作创建子进程（copy-on-write），RDB持久化过程由子进程负责，完成后自动结束。它不会记录fork之后后续的命令。阻塞只发生在fork阶段，一般时间很短。

用lastsave命令可以查看最近一次成功生成快照的时间。

【5】、RDB文件的优势和劣势

优势

1. RDB是一个非常紧凑(compact)的文件，它保存了redis在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3. RDB在恢复大数据集时的速度比AOF的恢复速度要快。

劣势

1. RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，频繁执行成本过高。
2. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。

如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化。

02、AOF

Append Only File

AOF：Redis默认不开启。AOF采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改Redis数据的命令时，就会把命令写入到AOF文件中。

【1】、AOF配置

配置文件redis.conf

参数	说明
appendonly	Redis默认只开启RDB持久化，开启AOF需要修改为yes
appendfilename "appendonly.aof"	路径也是通过dir参数配置config get dir

 【2】、数据都是实时持久化到磁盘吗？

AOF数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。

什么时候把缓冲区的内容写入到AOF文件？

参数	说明
appendfsync everysec	AOF持久化策略（硬盘缓存到磁盘），默认everysec no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全； always表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低； everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择everysec，兼顾安全性和效率。

 【3】、文件越来越大，怎么办？

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

可以使用命令bgrewriteaof来重写。

AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

【4】、重写触发机制

参数	说明
auto-aof-rewrite-percentage	默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size	默认64M。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

 【5】、重写过程中，AOF文件被更改了怎么办？

 03、AOF优势与劣势

优点

AOF持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis最多也就丢失1秒的数据而已。

缺点

1. 对于具有相同数据的的Redis，AOF文件通常会比RDF文件体积更大（RDB存的是数据快照）。
2. 虽然AOF提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB比AOF具好更好的性能保证。

04、两种方案比较

那么对于AOF和RDB两种持久化方式，我们应该如何选择呢？ 

一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。