9、redis的持久化策略

学习目标：

1、了解Redis的持久化的使用

1、掌握Redis的持久化的配置

学习过程：

    Redis是内存数据库，所以在服务器重启或者断电时，内存数据肯定会丢失，对于某些应用来说这是不可接收，例如如果使用Redis作为订单号的生成器，每一次都会逐次增1，如果断电重启后，订单号必须能够接着增1，而不是从0开始。所以Redis有必要持久化数据。当然如果你的业务仅仅只是用于简单的缓存，那么你也可以禁用持久化以提升效率。  

Redis的有两种持久化策略：

• rdb:快照形式是直接把内存中的数据保存到一个dump文件中，定时保存，保存策略

• aof：把所有的对redis的服务器进行修改的命令都存到一个文件里，命令的集合

一、rdb方式

    快照rdb持久化方式时安装redis时的默认方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是dump.rdb，这些也都可以通过配置文件修改的。

redis.conf常见配置：

dbfilename "dump.rdb" 

dir "/data/dbs/redis/6381"

save 900 1 

save 300 10

save 60 10000

意义如下：

    dbfilename "dump.rdb"          #持久化文件名称

    dir "/data/dbs/redis/6381"    #持久化数据文件存放的路径

    默认是如上配置：900秒之内，如果超过1个key被修改，则发起快照保存；

    300秒内，如果超过10个key被修改，则发起快照保存

    1分钟之内，如果1万个key被修改，则发起快照保存

    rdb持久化工作原理简单：当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write。

   RDB持久化也分两种：SAVE和BGSAVE

  1、SAVE是阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件（即上面的dump.rdb）中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。

 2、BGSAVE属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。这种方式尤其需要注意的。如果redis本身内存使用率就60%，总的内存使用率在80%左右，持久化的时候立马占到100%以上的。

可以使用命令操作的。

127.0.0.1:6379> bgsave

Background saving started

127.0.0.1:6379> save

OK

   从上面的配置可知，rdb方式不能完全保证数据持久化，因为是定时保存，所以当redis服务down掉，就会丢失一部分数据，而且数据量大，写操作多的情况下，会引起大量的磁盘IO操作，会影响性能。

 

二、aof方式

    使用aof做持久化，每一个写命令都通过write函数追加到appendonly.aof中.配置方式：启动aof持久化的方式 

    appendonly yes  

    Append-only方法可以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到redis关闭前的最后时刻。

    LOG Rewriting随着修改数据的执行AOF文件会越来越大，其中很多内容记录某一个key的变化情况。因此redis有了一种比较有意思的特性：在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），缩小的AOF文件的大小。所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。

    AOF文件刷新的方式，有三种，参考配置参数appendfsync ：

    appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；

    appendfsync everysec每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；

    appendfsync no依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。

appendonly yes              //启用aof持久化方式

# appendfsync always      //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用

appendfsync everysec     //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐 

# appendfsync no    //完全依赖os，性能最好,持久化没保证

 

    可能由于系统原因导致了AOF损坏，redis无法再加载这个AOF，可以按照下面步骤来修复：首先做一个AOF文件的备份，复制到其他地方；修复原始AOF文件，执行：$ redis-check-aof –fix ;可以通过diff –u命令来查看修复前后文件不一致的地方；重启redis服务。

redis-check-aof --fix  appendonly.aof   

 

三、Redis 4.0版本后支持---混合持久化
Redis 4.0有一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。AOF文件的前半段是RDB格式的全量数据后半段是redis命令格式的增量数据。

修改配置

aof-use-rdb-preamble yes #默认时没有开启混合持久化的改成yes

我们先看看原来的aof文件

[root@localhost redis]# cat appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$6
liubao
*2
$6
SELECT
$1
0
*3
$3
set
$3
age
$3
456
*2
$6
SELECT
$1
0
*3
$3
set
$3
msg
$5
hello

执行一下

192.168.137.101:0>BGREWRITEAOF

然后在设置一个值

192.168.137.101:0>set test abc

然后再看看aof文件
[root@localhost redis]# cat appendonly.aof 
REDIS0008dis-ver4.0.13edis-bitsctime\ed-mem-preambleagenameliubaomsghello

SELECT
$1
0
*3
$3
set
$4
test
$3
abc

可以看到前面实际上就是rdb的内容，后面就是新的aof的内容了，混合持久化的有点就是再redis重启后，加载aof恢复数据时是会快很多，同时aof文件也会小很多。

四、取消持久化

    其实我们也可以把持久化取消，以达到最高的运行效率，当然数据一旦断电也就会没有，我们可以使用主从配置或者集群的方式提高稳定性。所以很多时候也会在取消持久化功能的

1. 注释掉原来的持久化规则

#save 900 1

#save 300 10

#save 60 10000

2.设置为空

save ""

   取消持久化需要注意的一点：如果你以前有使用过持久化功能，那么需要把以前的持久化文件删除才行。最好运行flushall命令清楚旧数据了。

3、aof持久化也需要关闭了。

aof-use-rdb-preamble no

appendonly no

总结：

   两种方式你可以自己根据需要选择，也可以同时开启两种持久化方式：

1、在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

2、RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要使用AOF呢？那要看情况而定，如果缓存信息比较重要，那么可以使用AOF，因为RDB更适合用于备份数据库，这也是大部分的使用场景。