redis持久化配置详解

REDIS的持久化主要分为两种模式，分别是RDB和AOF，Redis可以同时使用以上两种持久化。

1. RDB 持久化: 生成某个时间点的快照文件
2. AOF 持久化(append only file): 日志追加模式(Redis协议格式保存)

RDB

优点：

RDB 是一个非常紧凑（compact）的文件，体积小，因此在传输速度上比较快，因此适合灾难恢复。 

RDB 可以最大化Redis 的性能：父进程在保存RDB 文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O 操作。

RDB 在恢复大数据集时的速度比AOF 的恢复速度要快。

缺点：

RDB是一个快照过程，无法完整的保存所以数据，尤其在数据量比较大时候，一旦出现故障丢失的数据将更多。

当redis中数据集比较大时候，RDB由于RDB方式需要对数据进行完成拷贝并生成快照文件，fork的子进程会耗CPU，并且数据越大，RDB快照生成会越耗时。

RDB文件是特定的格式，阅读性差，由于格式固定，可能存在不兼容情况。

# 注释掉“save”这一行配置项就可以让保存数据库功能失效
# 设置sedis进行数据库镜像的频率。
# 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化） 
# 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化） 
# 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
save 900 1
save 300 10
save 60 10000

#当RDB持久化出现错误后，是否依然进行继续进行工作，yes：不能进行工作，no：可以继续进行工作，可以通过info中的rdb_last_bgsave_status了解RDB持久化是否有错误
stop-writes-on-bgsave-error yes

#使用压缩rdb文件，rdb文件压缩使用LZF压缩算法，yes：压缩，但是需要一些cpu的消耗。no：不压缩，需要更多的磁盘空间
rdbcompression yes

#是否校验rdb文件。从rdb格式的第五个版本开始，在rdb文件的末尾会带上CRC64的校验和 这更有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗，所以如果追求高性能，可以关闭该配置。
rdbchecksum yes

#rdb文件的名称
dbfilename dump.rdb

#数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dir "/home/redisdb"

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

    手动触发分别对应save和bgsave命令：

    save命令：阻塞当前Redis服务器，知道RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，先上环境不建议使用。运行save命令对应Redis日志如下：

DB saved on disk

   bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一段时间很短。运行bgsave名字对应的Redis日志如下：

Background saving started by pid 23423
DB saved on disk
RDB: 0MB of memory userd by copy-on-write
Background saving terminated with success

bgsave命令是针对save阻塞问题做的优化。因此Redis内部所有涉及到RDB操作都采用bgsave的方式，而save命令可以废弃。

    Redis内部还存在自动触发RDB的持久化机制，例如一下场景:

    1) 使用save相关配置，如‘save m n’表示m秒之内数据集存在n次修改时，自动触发bgsave。

    2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。

    3）执行debug reload命令重新加载Redis时，也会自动触发save操作。

    4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave

 

AOF追加模式

优点：

数据更完整，秒级数据丢失(取决于设置fsync策略)。

兼容性较高，由于是基于redis通讯协议而形成的命令追加方式，无论何种版本的redis都兼容，再者aof文件是明文的，可阅读性较好。

缺点：

数据文件体积较大,即使有重写机制，但是在相同的数据集情况下，AOF文件通常比RDB文件大。

相对RDB方式，AOF速度慢于RDB，并且在数据量大时候，恢复速度AOF速度也是慢于RDB。

由于频繁地将命令同步到文件中，AOF持久化对性能的影响相对RDB较大，但是一般来说是可以接受的。

#默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendonly yes

#aof文件名, 保存目录由 dir 参数决定
appendfilename "appendonly.aof"

#aof持久化策略的配置
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
#always表示每次写入都执行fsync，以保证数据同步到磁盘。
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec

# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。
no-appendfsync-on-rewrite no

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

#aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
aof-load-truncated yes

AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。

    AOF重写过程可以手动触发和自动触发：

• 手动触发：直接调用bgrewriteaof命令

• 自动触发：更具auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

  • auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB

  • auto-aof-rewrite-percentage:代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值

    自动触发时机=aof_current_size>auto-aof-rewrite-min-size && (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

    其中aof_current_size和aof_base_size可以再info Persistence统计信息中查看。

 

 

混合持久化

优点：

混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。

缺点：

兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差

混合持久化也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，如下图：

aof-use-rdb-preamble yes

192.168.223.132:6379> set 123  222
OK
192.168.223.132:6379> set 222  222
OK
192.168.223.132:6379> bgrewriteaof
Background append only file rewriting started
192.168.223.132:6379> set 1234 11
OK
192.168.223.132:6379>

 

此时的aof文件已经和只开启AOF持久化文件不一样了，上半部分是RDB持久化的数据，下半部分是AOF格式数据。

[root@localhost redisdb]# 
[root@localhost redisdb]# cat appendonly.aof 
REDIS0009�	redis-ver5.0.7�
�edis-bits�@�ctime°{h`used-mem�p
 aof-preamble�����������
m�� *2
$6
SELECT
$1
0
*3
$3
set
$1
4
$1
4
*3
$3
set
$1
5
$1
5
[root@localhost redisdb]#