redis持久化

一、前言

redis持久化是高可用的重要的一个条件，它可以确保redis挂掉 重启后，数据可以还原。目前redis有三种持久化策略，分别为：RDB快照、AOF和混合持久化。不同的持久化策略有不同的有点和缺点。在项目开发中，需要根据它们的特性来决定使用哪种策略来进行持久化。

二、RDB快照（snapshot）

RDB快照是redis的默认持久化策略，默认情况下redis会将内存数据快照保存到dump.rdb二进制文件中。

快照生成规则

自动生成快照

快照何时生成，是可以通过修改配置文件中save的配置来修改的。
自动生成快照是执行bgsave命令，来异步生成的。具体看快照生成命令

save n秒 m次数 指的是n秒钟至少执行了m次修改操作时保存一次快照。可以设置多个规则，规则直接是或关系，只要满足其中一条即生成快照
redis 的默认配置规则如下

save 900 1
save 300 10
save 60 10000

解释：900秒内至少执行了一次修改操作 或者 300秒内至少执行了10次修改操作 或者 60秒内至少执行 10000次操作 就生成快照

手动生成快照

进入客户端执行save或者是bgsave可以手动生成dump.rdb二进制文件。每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有的rdb快照文件。

快照生成命令

save: 是同步命令，由于redis是单线程的，所以会阻塞客户端命令。因此执行该命令的时候需要慎重
bgsave:是异步命令，执行时会从redis的主进程中fork出一个子进程进行快照生成。该命令不会阻塞客户端命令。快照的自动生成就是使用该命令

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis	是	否
优点	不会消耗额外内存	不阻塞其它redis命令
缺点	阻塞其它redis命令	fork子进程会消耗额外内存

数据安全性

在一定程度上会丢失数据，丢失的多少和配置的规则有关。比如50秒内进行了9000次更新操作，然后redis挂了，这9000从更新操作没有持久化到磁盘中，重启后这9000次更新将丢失。
因此对于数据安全性比较高的应用，

关闭RDB快照功能

将save规则全部注释掉。

其它配置

# 如果bgsave失败后将停止写
stop-writes-on-bgsave-error yes

## 是否开启压缩弓
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

# 存储文件名
dbfilename dump.rdb

# 存储数据的目录
dir ./

三、AOF持久化（append only file）

由于RDB快照数据安全性方面有些欠缺，对于数据安全性比较高的应用，RDB快照的可能丢失数据影响比较大。因此Redis1.1版本开始提供了一种比较安全的持久化方式，AOF持久化：将修改的每条指令追加到appendOnly.aop文件末尾

开启AOF持久化

AOF持久化默认是关闭的，appendonly no。如果想要开启，修改配置为appendonly yes。
当AOF持久化开启后，每当redis执行一条更新指令后，会将该指令追加到aof文件末尾。当redis重启后，执行aof文件进行数据重建。
aof有三种持久化策略，不同策略会影响数据的安全性和效率。

AOF的持久化策略

appendfsync always

每次执行更新指令都会执行一次fsync命令，将该指令追加到aof文件末尾。效率非常慢，但不会出现数据丢失的情况

appendfsync everysec

每秒执行一次fsync，足够快（和RDB差不多），出现故障最多会丢失一秒的数据。 是默认持久化方式，兼顾了速度和安全性

appendfsync no

从不fsync，将数据交给操作系统处理，更快也更不安全。

AOF重写

AOF中可能会有大量重复的指令或者是没用的指令，AOF重写可以将这些指令重写合并或者删除。即可以缩小文件大小，也可以在恢复时减少指令的执行。提高了恢复的效率。所以AOF会定期根据内存中的最新数据重写AOF文件。
举例：

127.0.0.1:6379> incr count
(integer) 1
127.0.0.1:6379> incr count
(integer) 2
127.0.0.1:6379> incr count
(integer) 3
127.0.0.1:6379> incr count
(integer) 4
127.0.0.1:6379> incr count
(integer) 5
127.0.0.1:6379> incr count
(integer) 6
127.0.0.1:6379> incr count
(integer) 7

查看aop文件

*2
$6
SELECT
$1
0
*2
$4
incr
$5
count
*2
$4
incr
$5
count
*2
$4
incr
$5
count
*2
$4
incr
$5
count
*2
$4
incr
$5
count

手动重写aop文件

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

重写后的aop文件（5.0先关闭混合持久化模式5）

*2
$6
SELECT
$1
0
*3
$3
SET
$5
count
$1

重写策略配置

# 当自上次重写后文件大小增长100%则再次触发重写
auto-aof-rewrite-percentage 100
## 文件大小至少达到64M才会自动重写，文件太小恢复速度就很快，重写意义不大
auto-aof-rewrite-min-size 64mb

手动重写命令

bgrewriteaof

重写redis会fork出一个子进程去做，不会阻塞redis

四、RDB快照和AOF对比

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	容易丢失	根据策略决定

如果安全性要求比较高，优先选择AOF持久化。
如果redis中既有启用了RDB快照又启用了AOF持久化，重启时redis会优先使用AOF恢复数据，因为AOF数据更全一点。

五、混合持久化

混合持久化顾名思义，它就是将RDB快照的有点和AOF的优点结合起来。

原理

如果开启混合持久化，AOF在重写时，不在是单纯的将内存中的数据转换成写中RESP命令写入AOF文件中，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改指令都存入一起，都写入新的AOF文件中，当重写完成后新的AOF文件会替换旧的AOF文件。
因此在重启时，可以先加载RDB快照的二进制内容，然后再加载增量的AOF命令，利用到RDB快照的文件小和恢复速度快优点，使之重启速度大幅度的提升。

结构

[RDB文件]
[AOF尾]

开启混合持久化

aof-use-rdb-preamble yes

我使用的是5.0.12默认是yes，如果想要关闭改成no

举例说明

重新aof后文件变成如下内容（接着AOF小节的命令）

REDIS0009ú      redis-ver^F5.0.12ú
redis-bitsÀ@ú^EctimeÂ<82>é<97>`ú^Hused-memÂ(é^M^@ú^Laof-preambleÀ^Aþ^@û^A^@^@^EcountÀ^Eÿ^Lüe<8f>%^^^GY

再添加命令

127.0.0.1:6379> incr count
(integer) 6
127.0.0.1:6379> incr count
(integer) 7

再查看aop文件

REDIS0009ú      redis-ver^F5.0.12ú
redis-bitsÀ@ú^EctimeÂ<82>é<97>`ú^Hused-memÂ(é^M^@ú^Laof-preambleÀ^Aþ^@û^A^@^@^EcountÀ^Eÿ^Lüe<8f>%^^^GY*2^M
$6^M
SELECT^M
$1^M
0^M
*2^M
$4^M
incr^M
$5^M
count^M
*2^M
$4^M
incr^M
$5^M
count^M

再重写后查看aof文件

REDIS0009ú      redis-ver^F5.0.12ú
redis-bitsÀ@ú^EctimeÂTê<97>`ú^Hused-memÂxé^M^@ú^Laof-preambleÀ^Aþ^@û^A^@^@^EcountÀ^Gÿ^E<83>)°\ä_ì

总结

混合持久化其实就是在重写的时候将RDB快照的二进制文件写入AOF文件中，然后追加指令时，将指令追加到AOF末尾。极大的缩小了文件的大小，又保证了一定的数据安全性