REDIS-持久化方案

我们知道redis是内存数据库，它的数据是存储在内存中的，我们知道内存的一个特点是断电数据就丢失，所以redis提供了持久化功能，可以将内存中的数据状态存储到磁盘里面，避免数据丢失。

Redis持久化有三种方案，分别是RDB、AOF、混合持久化；

RDB持久化(Redis DataBase)

RDB持久化是将某一时刻的内存快照(Snapshot)以二进制的方式写入磁盘。

触发方式：

手动触发

手动触发方式可以直接用命令save或者bgsave，这两个命令的区别是是否会阻塞Redis主线程执行。

save命令：在客户端直接执行save命令即可触发Redis的持久化，但是这种方式会使得Redis处于阻塞状态，直到RDB持久化完成，才会响应其它客户端发来的命令，所以一定要小心使用。

可以看到dump.rdb文件的时间变了，表示rdb文件被修改过，表示save触发成功了。

bgsave命令：英文名称是background save,看英文单词就知道是后台保存的命令，这种方式会fork()一个子进程来执行持久化，当子进程被创建之后，Redis主进程就可以响应其他客户端的请求了。

自动触发

自动触发的第一种方式就是在配置文件配置 save m n 意思就是在m秒内，如果有n个件发生变化，就会触发持久化；比如 save 20 1 意思就是在60秒内，至少有一个键发生变化就会触发持久化。

自动触发的第二种方式就是命令flushall，该命令是清空redis数据库的，要慎用，执行完这个命令之后就会自动触发持久化，但是这个持久化是把RDB的文件清空。

127.0.0.1:6379> flushall
OK
127.0.0.1:6379>

还有一种触发方式是主从同步触发，在redis主从同步复制中，当从节点执行全量复制操作时，主节点会执行bgsave命令，并将RDB文件发送给从节点，该过程会自动触发持久化。

配置RDB持久化：

在配置文件中配置：

#持久化条件
save 3600 1 
save 300 100
save 60 10000
#该配置是说bgsave失败之后，是否停止持久化数据到磁盘
stop-writes-on-bgsave-error yes 
#是否启用RDB文件压缩
rdbcompression yes
# 写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
rdbchecksum yes
# RDB 文件名
dbfilename dump.rdb
# RDB 文件目录
dir ./

RDB文件恢复

当Redis服务器启动的时候，如果redis的根目录存在RDB文件dump.rdb，redis就会自动加载RDB文件恢复持久化数据。

可以看到redis在启动的时候已经正常加载了RDB文件。

RDB持久化优缺点

优点：

1，RDB的内容是二进制数据，那么它占用的内存将更小更紧凑，也更适合作为备份文件。

2，RDB持久化可以后台持久化数据到磁盘(fork一个子进程)。

3，RDB文件恢复速度比AOF文件恢复得要快。

缺点：

缺点就是RDB可能会存在少量数据丢失，因为这种持久化方式是相当于每隔一段时间进行持久化，所以会丢失一段时间内得redis数据；还有就是进行持久化得时候会fork一个子进程进行持久化，如果数据量特别大可能会导致服务端有短暂得停顿。

AOF持久化

AOF持久化，Append Only File，根据这个英文名称就可以看到是追加到文件；AOF持久化就是把Redis的每个键值对的操作都记录到文件中。

开启持久化

可以通过命令: config get appendonly 来查看是否开启了AOF持久化功能。

开启持久化：

Redis默认是关闭了AOF持久化的，想要开启可以使用命令行方式或者修改配置文件。

命令行开启AOF持久化

使用命令 config set appendonly yes

127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes
OK
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "yes"

注意：命令行启动AOF持久化之后，Redis就已经开启持久化了，无需重启；但是Redis重启之后失效。

配置文件启动AOF

在配置文件中添加：

appendonly yes

可以通过在客户端输入： config get dir 来获取配置文件所在位置。

这种配置方式需要重启redis之后才能生效。

触发持久化

有两种吃法方式：手动触发和自动触发

自动触发

有两种情况可以自动触发AOF持久化，(1)满足AOF设置的策略触发；(2)，满足AOF重写触发。

第一种触发策略有三种：

1.always：每条redis操作命令都会写入磁盘，最多丢失一条数据。

2.everysec：每秒钟写入一次磁盘，最多丢失一条数据。

3.no：不设置写入磁盘规则，根据当前操作系统来决定何时决定写入磁盘，linux默认30s一次。

设置方式：在配置文件中配置

appendfsync everysec

AOF重写

因为AOF是通过记录redis的执行命令来进行持久化的，所以时间久了之后AOF文件会越来越大，这样启动服务器在恢复数据的时候也会比较慢，为了解决这个问题Redis提供了AOF重写功能。

所谓AOF重写就是去读取Redis服务器的状态，然后压缩保存为AOF文件。意思就是假如说我们在Redis设置了一个值 k，然后对这个值进行100次自增操作，如果不做AOF操作，那么文件中就有一百条对这个值操作的命令，而AOF重写之后，会记录最终的操作结果，这样就去掉了不必要的信息。

触发AOF 重写要满足两个条件，这两个条件在Redis配置文件中配置：

auto-aof-write-min-size: 允许AOF重写的最小文件容量，默认是64mb
auto-aof-rewrite-percentage:AOF文佳重写的大小比例，默认是100%，也就是只有当前AOF文件比上一次大一倍的时候才启动AOF文件重写。

数据恢复

一般情况下只要开启了持久化，并且正常提供了AOF文件，那么Redis在启动的时候就会自动加载AOF文件，进行数据恢复。

如果只开启了RDB持久化，那么Redis在启动的时候值会加载RDB文件。

如果两者同时开启了的花，Redis就只会加载AOF文件。

这种持久化的方式保存的数据更完整，根据选择只用不同的策略服务器最多可能会丢失1s内的数据，或者一条数据，默认是使用1s持久化一次的策略。AOF持久化有一个最大的缺点就是文件比较大，相比RDB持久化来说的话。在Redis负载较高的情况下RDB要比AOF性能好一些。

3.混合持久化

通过前面的介绍我们知道了RDB持久化和AOF持久化各有利弊，RDB持久化可能会导致一段时间的数据丢失，而AOF持久化形成的持久化文件比较大，启动加载会比较久。那么混合持久化结合这两种持久化的方式，来规避它们的缺点(混合持久化是在Redis 4.0版本之后才拥有的)。

开启混合持久化就是，基于AOF重写的时候，会把Redis当前的服务器数据以RDB格式写入到写入到AOF文件的开头，然年后续的梦里以AOF文件的格式追加到文件的末尾。这样每次重写就节省了更多的空间。

开启混合持久化

首先你可以在客户端输入命令：config get aof-use-rdb-preamble 来查看当前服务器是否开启了混合持久化。

通过命令行开启：

127.0.0.1:6379> config get aof-use-rdb-preamble
1) "aof-use-rdb-preamble"
2) "no"
127.0.0.1:6379> config set aof-use-rdb-preamble yes
OK

命令行开启方式存在的问题就是每次重启Redis服务器都得手动开启。

通过配置文件开启：

只需要更改配置文件中的：

aof-use-rdb-preamble no  #将no 改为yes即代表开启了

4.总结

对于Redis持久化我简单总结了三种持久化方式，虽然没讲啥原理上的东西(因为我自己也不懂：>)，但是仔细看把大致流程要在脑海里有个印象，最好安装个Redis自己看一下这些配置，跟着配置一下是最好的，以后当面试官问到的时候，要尽可能的多讲一点东西。因为Redis的确是一个很优秀的中间件，被广泛的运用到我们的几乎每个项目中。