大话Redis系列--聊聊redis是如何做到“持久化”的

关于Redis(4.0+)里面的持久化方案有三种：

RDB(Redis DataBase)

AOF(Append Only File)

混合型方案

RDB相关配置

这是redis里面默认提供的一套持久化技术方案，专门用于保证内存中的数据被写入到磁盘里面去。主要配置是修改相应的redis.conf来实现

redis里面的这一行主要是用于将数据持久化在redis的dump.rdb文件里面，然后每一次开启redis的时候都会将里面的数据重新加载，进行数据恢复。（dump.rdb的存放位置由下边的dir来标识）

这一段配置主要是rdb的核心规则配置内容：

save <指定时间间隔> <执行指定次数更新操作> （默认是save 900 1）

举个例子来说：

save m n

也就是说m秒类如果进行了n次操作，就会将数据存储到dump.rdb文件中去。

rdb里面并不是单纯将数据直接存储起来，而是通过一种特定的lzf压缩方式来实现的：

这个配置开关最好打开（默认开启），否则会导致rdb文件过大，占用磁盘空间。

触发rdb存储机制的条件：

1.显示执行save指令（但是这是一种阻塞式指令）

2.执行flushall指令的时候，清空所有数据

3.执行shutdown指令

4.在指定时间间隔，操作次数达到save配置的数目

RDB的优缺点

缺点

• RDB 在服务器故障时容易造成数据的丢失。RDB 允许我们通过修改 save point 配置来控制持久化的频率。但是，因为 RDB 文件需要保存整个数据集的状态， 所以它是一个比较重的操作，如果频率太频繁，可能会对 Redis 性能产生影响。所以通常可能设置至少5分钟才保存一次快照，这时如果 Redis 出现宕机等情况，则意味着最多可能丢失5分钟数据。

  
  

  
  

  
  

  
  

• RDB 保存时使用 fork 子进程进行数据的持久化，如果数据比较大的话，fork 可能会非常耗时，造成 Redis 停止处理服务N毫秒。如果数据集很大且 CPU 比较繁忙的时候，停止服务的时间甚至会到一秒。

• Linux fork 子进程采用的是 copy-on-write 的方式。在 Redis 执行 RDB 持久化期间，如果 client 写入数据很频繁，那么将增加 Redis 占用的内存，最坏情况下，内存的占用将达到原先的2倍。刚 fork 时，主进程和子进程共享内存，但是随着主进程需要处理写操作，主进程需要将修改的页面拷贝一份出来，然后进行修改。极端情况下，如果所有的页面都被修改，则此时的内存占用是原先的2倍。

关于Redis在使用RDB方案解决数据持久化的时候实际上底层的主进程是fork了一个子进程用于处理RDB文件，我在网上找到了一份比较清晰的流程图用于展示这个环节中的细节点：

优点

• RDB 文件是是经过压缩的二进制文件，占用空间很小，它保存了 Redis 某个时间点的数据集，很适合用于做备份。比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

  
  

• RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。

  
  

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

  
  

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

实战--RDB的数据恢复过程

接下来我们来演示一段redis里面进行rdb数据恢复的过程

首先我们需要修改rdb的配置信息

[root@idea-centos bin]# vim redis.conf
1

修改内容

    save 900 1
    save 120 5
    save 60 10000

修改了对应的配置属性之后，我们可以先模拟制造一些数据信息，如下所示：

[root@idea-centos bin]# ./redis-server redis.conf
[root@idea-centos bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> set key4 value4
OK
127.0.0.1:6379> set key5 value5
OK
127.0.0.1:6379> set key6 value6
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

由于已经制造了部分数据信息，所以此时的dump.rdb文件内就已经存在一些数据内容了。为了后期的演示，我这里做个数据备份：

[root@idea-centos bin]# cp dump.rdb dump_bk.rdb
[root@idea-centos bin]# ./redis-server redis.conf
[root@idea-centos bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

接下来我们对已经清空的数据库进行rdb文件的恢复操作：

[root@idea-centos bin]# cp dump_bk.rdb  dump.rdb
cp: overwrite `dump.rdb'? y
[root@idea-centos bin]# ./redis-server redis.conf
[root@idea-centos bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "key5"
2) "key1"
3) "key3"
4) "key4"
5) "key6"
6) "key2" 
......

恢复之后会发现先前清理掉的部分数据又再次恢复正常了。

ps:一般情况下我们会禁止flushall指令和shutdown指令，这里只是为了模拟测试才使用的。

问题：假设我们给redis配置的保存机制是10秒内10次操作才做保存，倘若某一天redis在10秒内只执行了9次修改操作，当满了10秒的时候机器宕机了，那么这些对应的10次操作的key就会发生丢失。这也是rbd作为数据备份时候对一个缺陷，为了优化这种问题，redis后边又提出了aof的持久化解决手段。

AOF方式持久化

为了弥补rdb的不足之处，aof出现了。它是采用日志的形式来将每一次写操作都进行记录，追加到相应的文件中去。Redis重启的时候会根据日志文件的内容从前到后执行一次。

关于aof内部对一些配置我们可以关注以下几个内容点：

appendonly：默认值为no，也就是说redis 默认使用的是rdb方式持久化，如果想要开启 AOF 持久化方式，需要将 appendonly 修改为 yes。

appendfilename ：aof文件名，默认是"appendonly.aof"

appendfsync：aof持久化策略的配置

AOF的持久化策略有哪些

always策略

这类策略是每次处理redis指令的时候都会将数据立马写入磁盘进行持久化，虽然性能差，但是安全性是最高的。

everysec策略（推荐）

会有一个异步子线程，每一秒将新写入到内存的数据持久化到磁盘中。

no策略

直接写入aof的内存缓冲区，剩下部分由操作系统自身来控制

AOF文件过大如何优化

上边在写rdb重写机制的时候有讲到过rdb文件压缩的原理是使用算法将二进制文件进行压缩，而对于AOF来说，它自身是采用去除无效命令的方式来进行空间压缩的。

例如说同一个key进行了重复的插入，那么就只保留最后一次插入的数据。如下图所示：

AOF里触发该机制的条件可以在conf文件里面进行配置：

当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

配置参数：

auto-aof-rewrite-min-size 64mb #aof文件要达到一定体积才会进行重写

auto-aof-rewrite-percentage 100 #当aof文件大小增长了100%才会触发重写

重写的原理

aof在进行重写处理的时候，会额外开辟一个bgrewriteaof线程，将原先的aof文件数据拷贝到一个临时文件进行处理，最后再覆盖原先文件。

相比于rdb而言，aof的数据备份效率更高，但是在数据恢复的时候其性能却远远不如rdb高效。

长按二维码

就可以关注我们啦~