Redis实例（10）——持久化

一、Redis 持久化机制

1) RDB 持久化

该机制是指在指定的时间间隔内，例如 900、300、60秒，将内存中的数据集快照写入磁盘。

2) AOF 持久化

该机制将以日志的形式，记录服务器所处理的每一个写操作，

在Redis服务器启动之初，会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。

3) 无持久化

我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached，宕机或断电后，内存的数据都丢失了，没法恢复。

4) 同时应用 AOF 和 RDB 两种持久化方式，安全可靠，但效率降低

二、RDB 持久化的优势和劣势

RDB 优势

1) 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件 dump.rdb (默认路径：/var/lib/redis/dump.rdb)，这对于文件备份而言是非常完美的。

配置文件：vim /etc/redis.conf

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
#dir ./
dir /var/lib/redis/

比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2) 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3) 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4) 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB数据文件名和内容格式，如下：

$ tail /var/lib/redis/dump.rdb

$ tail /var/lib/redis/dump.rdb

445}:mimvp:open:sort:protocol_status:189.126.78.105_53704mvp:open:sort:protocol_status:162.144.67.170_64157mvp:open:sort:country_ch:66.70.188.148_3128美国1mimvp:open:sort:check_dtime:96.9.67.84_808020190529060110-+i++-_-_-|y:--e+:_-_+:i-:181.115.168.69_49076181.115.168.693+i++-_-_-|y:--e+:_-_+:-i+g_+i+e:185.159.87.102_6660.502026;+i++-_-_-|y:--e+:_-_+:a+-+y+-+___+a++_:116.193.223.217_80806+i++-_-_-|y:--e+:_-_+:+_a+_fe__+i+e:85.232.158.10_80803.125052+i++-_-_-|y:--e+:_-_+:c-+++_y_ch:210.5.10.87_53281中国3+i++-_-_-|y:--e+:_-_+:i_-__+a++_:201.47.91.245_8080

RDB 劣势

1) 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2) 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。因为 fork 子进程是需要耗时的操作。

RDB 机制原理

RDB 在指定的时间间隔内，将内存中的数据，以快照的形式保存到磁盘

RDB 持久化过程

1）客户端执行bgsave命令，redis主进程收到指令并判断此时是否在执行bgrewriteaof，如果此时正好在执行则bgsave直接返回，不fork子进程，如果没有执行

2）bgrewriteaof 重写AOF文件，则进入下一个阶段；

3）主进程调用fork方法创建子进程，在创建过程中redis主进程阻塞，所以不能响应客户端请求，Redis量少则耗时很短；

4）子进程创建完成以后，bgsave命令返回“Background saving started”，此时标志着redis主进程可以响应客户端请求了；

5）子进程根据主进程的内存副本创建临时快照文件，当快照文件完成以后，对原快照文件进行替换；

6）子进程发送信号给redis主进程完成快照操作，主进程更新统计信息（info Persistence可查看），子进程退出；

触发RDB的时机：

在配置文件中配置触发的条件

15min 内有1个key变化
5min 内有10个key变化
1min 内有10000个key变化

具体的时间以及次数可以在配置文件中修改，修改save 秒钟写操作次数

save 900 1
save 300 10
save 60 10000

RDB相关配置

save m n
#配置快照(rdb)促发规则，格式：save <seconds> <changes>
#save 900 1  900秒内至少有1个key被改变则做一次快照
#save 300 10  300秒内至少有300个key被改变则做一次快照
#save 60 10000  60秒内至少有10000个key被改变则做一次快照
#关闭该规则使用svae “” 

dbfilename  dump.rdb
#rdb持久化存储数据库文件名，默认为dump.rdb

stop-write-on-bgsave-error yes 
#yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。

rdbchecksum yes
#在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。

dir "/etc/redis"
#数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限

rdbcompression yes
#是否开启RDB文件压缩，该功能可以节约磁盘空间、

停止备份：

在配置文件中就设置 save "" ，或在命令行中 config set save ""

2 使用命令

save：会立即生成dump.rdb，但是会阻塞往redis内存中写入数据

bgsave：后台异步备份，不会阻塞主进程对客户端的请求响应

如果是使用flushdb命令，会把之前的快照更新成当前的空状态，所以执行了flushdb后，更新的快照是没有数据的

恢复RDB文件

将dump.rdb文件移动到redis的工作目录下，重启redis服务

获取工作目录： confi get dir

优点：恢复大量文件时速度快

缺点：存在数据丢失的风险，fock的子线程占用内存

三、AOF 的优势和劣势

AOF 优势

1) 该机制可以带来更高的数据安全性，即数据持久性。

Redis中提供了3中同步策略，即每修改同步、每秒同步、不同步。

事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。

而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。

至于无同步，无需多言，我想大家都能正确的理解它，效率最高，啥也不做，数据丢了，也不管，渣男的行为。

2) 由于该机制对日志文件的写入操作采用的是append添加模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过 redis-check-aof 工具来帮助我们解决数据一致性的问题。

3) 如果日志过大，Redis可以自动启用rewrite机制，即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4) AOF包含一个格式清晰、易于理解的日志文件，用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF 日志文件的名称和内容格式，如下：

tail /var/lib/redis/appendonly.aof

# tail /var/lib/redis/appendonly.aof
*2
$4
INCR
$45
mimvp:report:stat:api_fetch_total_count
*2
$4
INCR
$55

如上文本内容，说明如下：

第一行 *2 是指参数的个数，如 2个参数

第二行 $4 表明第1个参数 "INCR" 的长度为4

第三行是第1个参数 "INCR"

第四行 $45 表明第2个参数 "mimvp:report:stat:api_fetch_total_count" 的长度为45

第五行是第2个参数 "mimvp:report:stat:api_fetch_total_count"

Redis AOF 文件结构分析

Redis 4.0之前的AOF文件没有文件头，而从Redis 4.0开始AOF文件带有一个文件头，文件头格式和RDB文件头相同。

Redis 4.0版本，如果开启aof-use-rdb-preamble（值为yes，5.0默认为yes，4.0默认为no），则AOF文件内容由三部分组成：

1) 文件头（和RDB文件头格式相同）

2) RDB格式的二进制数据段

3) AOF格式的文本数据段

AOF格式的文本数据段和之前版本的保持相同，如下图所示：

从 Redis 4.0 开始，AOF有文件头，目的是支持同时加载RDB格式和AOF格式数据。

AOF文件头和RDB文件头基本相同，但RDB文件头多了三个字段。

先看AOF和RDB通用部分的文件头内容：

1) 头5字节固定为REDIS

2) 第6~9共四字节为RDB版本号

3) 接下来为redis-ver和它的值，即redis版本

4) 接着redis-bits和它的值，即redis的位数，值为32或64

5) 接着为ctime和它的值，值为当前时间戳

6) 接着为used-mem和它的值

7) 最后是aof-preamble和它的值，值为0或1，1表示RDB有效。

RDB的文件头和AOF的文件基本相同，但RDB文件头在aof-preamble之前多了如下三项：

1) repl-stream-db

2) repl-id

3) repl-offset

如果配置项appendonly值为no，则不会加载AOF文件，而是直接加载RDB文件，因为RDB文件保存了复制信息，所以进程重启可增量复制。而如果置项appendonly值为yes，因为AOF文件头不包含复制信息，所以只能全量复制。

Redis 启动时调用顺序

main(server.c:4003)
-> loadDataFromDisk(server.c:3850)
-> loadAppendOnlyFile(aof.c:673，当配置appendonly值为yes时)
-> rdbLoadRio(rdb.c:1850)

AOF 劣势

1) 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。

2) 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

AOF 机制原理

一个日志文件，实时备份客户端对redis的写操作记录，只需添加，不许修改，因此AOF文件比较大

AOF可以与RDB共存，但是恢复时先加载AOF

开启方式：在配置文件中设置 appendonly yes / no

恢复方式：将aof文件放在redis的工作路径下

异常恢复：先使用 redis-check-aof --fix 来删除aof中有语法错误的操作记录

AOF 运行过程：

redis的每一条命令以redis协议添加到缓存区aof_buf 中，然后根据同步策略一次性写入磁盘，这样可以节省磁盘IO次数

设置同步策略，appendfsysnc 保存操作记录的模式，共有三中模式：

1）always: 每次有数据修改时添加记录性能差

2）everysecond：每秒记录一次默认最多丢失1s的数据，即每秒把缓冲区的数据写入磁盘

3）no: 由OS决定何何时同步，linux通常是30s

Rewire：

当aof文件内容过多时，需要压缩原有的记录，优化原有的操作记录，执行的操作：

1 重复或者无效的操作记录不写入

2 过期的数据不再写入

3 多条命令合并

4 只保留可以恢复数据的最小指令集

触发机制：

当前aof文件的大小是上次rewrite后的两倍且大于64M，具体大小配置：

auto-aof-rewrite-min-size 64mb 生产环境下要配置的比较大

auto-aof-rewrite-percentage: 100 增长的百分比，也可使用命令bgwriteaof

AOF 持久化过程：

aof_rewrite_buf 代表重写缓冲区，aof_buf 代表写操作命令存放的缓冲区

1. 开始bgrewriteaof，判断当前有没有bgsave命令(RDB持久化)/bgrewriteaof在执行，倘若有，则这些命令执行完成以后在执行。

2. 主进程fork出子进程，在这一个短暂的时间内，redis是阻塞的。

3. 主进程fork完子进程继续接受客户端请求，所有写命令依然写入AOF文件缓冲区，并根据appendfsync策略同步到磁盘，保证原有AOF文件完整和正确。由于fork的子进程仅仅只共享主进程fork时的内存，因此Redis使用采用重写缓冲区(aof_rewrite_buf)机制保存fork之后的客户端的写请求，防止新AOF文件生成期间丢失这部分数据。此时，客户端的写请求不仅仅写入原来aof_buf缓冲，还写入重写缓冲区(aof_rewrite_buf)。也就是在进行rewrite时，主进程不仅把客户端的命令写入缓冲区，还会写入重写缓冲区，让子进程读取最新的命令记录。

4. 子进程通过内存快照，按照命令重写策略写入到新的AOF文件。

4.1 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。

4.2 主进程把AOF aof_rewrite_buf中的数据写入到新的AOF文件(避免写文件是数据丢失)。

5. 使用新的AOF文件覆盖旧的AOF文件，标志AOF重写完成。

AOF文件内容：

AOF实现本质是基于redis通讯协议，将命令以纯文本的方式写入到文件中。

redis协议：

首先，Redis是以行来划分，每行以\r\n行结束。每一行都有一个消息头，消息头共分为5种分别如下:

(+) 表示一个正确的状态信息，具体信息是当前行+后面的字符。

(-) 表示一个错误信息，具体信息是当前行－后面的字符。

(*) 表示消息体总共有多少行，不包括当前行，*后面是具体的行数。

(KaTeX parse error: Can't use function '\r' in math mode at position 21: …

一行数据长度，不包括换行符长度\̲r̲\n ，后面则是对应的长度的数据。

AOF 参数配置：

auto-aof-rewrite-min-size 64mb
#AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,4.0默认配置64mb。

auto-aof-rewrite-percentage  100
#当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。

appendfsync everysec
#no：不使用fsync方法同步，而是交给操作系统write函数去执行同步操作，在linux操作系统中大约每30秒刷一次缓冲。这种情况下，缓冲区数据同步不可控，并且在大量的写操作下，aof_buf缓冲区会堆积会越来越严重，一旦redis出现故障，数据
#always：表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。这种情况下由于每次写命令都写到了文件中, 虽然数据比较安全，但是因为每次写操作都会同步到AOF文件中，所以在性能上会有影响，同时由于频繁的IO操作，硬盘的使用寿命会降低。
#everysec：数据将使用调用操作系统write写入文件，并使用fsync每秒一次从内核刷新到磁盘。 这是折中的方案，兼顾性能和数据安全，所以redis默认推荐使用该配置。

aof-load-truncated yes
#当redis突然运行崩溃时，会出现aof文件被截断的情况，Redis可以在发生这种情况时退出并加载错误，以下选项控制此行为。
#如果aof-load-truncated设置为yes，则加载截断的AOF文件，Redis服务器启动发出日志以通知用户该事件。
#如果该选项设置为no，则服务将中止并显示错误并停止启动。当该选项设置为no时，用户需要在重启之前使用“redis-check-aof”实用程序修复AOF文件在进行启动。

appendonly no 
#yes开启AOF，no关闭AOF

appendfilename appendonly.aof
#指定AOF文件名，4.0无法通过config set 设置，只能通过修改配置文件设置。

dir /etc/redis
#RDB文件和AOF文件存放目录


优势：可以保证数据的一致性，因为它可以实时或者每秒记录客户端对redis的操作
缺点：aof文件比rdb文件大，恢复速度慢

四、RDB 和 AOF 比较

1. Snapshotting 快照持久化

缺省情况下，Redis会将数据集的快照dump到dump.rdb文件中。

此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，

打开 /etc/redis.conf 配置文件之后，搜索save，可以看到下面的配置信息：

存盘的命令格式：

save <seconds> <changes>

save 900 1 # 在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 # 在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 # 在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

查看配置文件

vim /etc/redis.conf

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 100000

2. RDB Dump快照的机制

1) Redis先fork子进程。

2) 子进程将快照数据，写入到临时RDB文件中。

3) 当子进程完成数据写入操作后，再用临时文件替换老的文件。

3. AOF文件

上面已经多次讲过，RDB的快照定时dump机制无法保证很好的数据持久性。

如果我们的应用确实非常关注此点，我们可以考虑使用Redis中的AOF机制。

对于Redis服务器而言，其缺省的机制是RDB，如果需要修改配置文件，开启使用AOF，则需要修改配置文件中的以下条目：将 appendonly no 改为 appendonly yes

从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。

在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。

4. AOF的配置在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always # 每次有数据修改发生时都会写入AOF文件。

appendfsync everysec # 每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no # 从不同步。高效但是数据不会被持久化。

查看配置文件

vim /etc/redis.conf

############################## APPEND ONLY MODE ###############################

# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

5. 如何修复坏损的AOF文件

1). 将现有已经坏损的AOF文件，额外拷贝出来一份。

2). 执行 "redis-check-aof --fix <filename>" 命令来修复坏损的AOF文件。

3). 用修复后的AOF文件，重新启动Redis服务器。

6. Redis 数据备份

在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。

# ll /var/lib/redis/
total 66520
-rw-r--r-- 1 root root   672208 Jan 21 15:56 appendonly.aof
-rw-r--r-- 1 root root 67214258 Jan  4  2019 dump_16481.rdb
-rw-r--r-- 1 root root   223288 Jan 21 16:06 dump.rdb

这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中，之后在利用rename函数，原子性的将临时文件改名为原有的数据文件名。

因此，我们可以说，在任意时刻copy数据文件都是安全的和一致的。

鉴于此，我们就可以通过创建cron job的方式定时备份Redis的数据文件，并将备份文件copy到安全的磁盘介质中。

五、同时开启 RDB 和 AOF

通常同时开启 RDB和AOF 两种持久化机制：

redis先加载AOF文件来恢复原始数据，因为AOF数据比rdb更完整，但是aof存在潜在的bug，如把错误的操作记录写入了aof，会导出数据恢复失败，所以可以把RDB作为后备数据

为了考虑性能，可以只在Slave上开启RDB，并且15min备份一次，如果为了避免AOF rewite的IO以及阻塞，可以在Redis集群中不开启AOF，靠集群的备份机制来保证可用性，在启动时选取较新的RDB文件，如果集群全部崩溃，会丢失15min前的数据

混合模式：

redis4.0开始支持该模式，为了解决的问题：

1）redis在重启时通常是加载AOF文件，但AOF文件体积大，加载速度慢

2）因为RDB数据不完整，所以加载AOF

开启方式： aof-use-rdb-preamble true