redis数据持久化介绍

在实际生活中，不可能完全避免断电这种突发事件，如果发生断电，生产环境中redis里面的数据怎么办？redis提供了两种数据持久化的操作：

1. RDB：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。
2. AOF：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据操作过程。

本篇我们先学习RDB的相关知识。

save指令

save指令相当简单，就是save。
先简单看一看其中的玄机。
先起一个redis服务端，往里面塞一条数据：set name jam，然后保存。

可以看到已经保存成功了，保存的数据存在哪里呢？在我们redis配置文件里，我们有一个参数：

就存在这个目录下。（对于这个配置文件不了解的同学可以参考我的前一篇博客或者在网上找更好的教程，毕竟这个只是我的学习笔记）
进这个目录，看看配置文件长什么样子。

这个dump.rdb文件就是我们使用save指令后存的快照数据。我们再塞一条数据试一下。set age 22然后保存。

保存成功后再看一下我们的快照文件。

可以看到文件大小确实变了，我们的数据也的确存进去了。

RDB相关配置

前面我们可以看到，快照的文件名叫dump.rdb，难道我起多个redis服务，不同的端口号的数据都存在一个文件里？不能修改文件名吗？当然可以！我们还是通过配置文件来解决。下面看看4个相关参数：

• dbfilename dump.rdb：设置本地数据库文件名，默认为dump.rdb，通过是dump-[端口号].rdb。
• dir：存储.rdb文件的路径，通常设置为空间较大的目录，目录名为data。
• rdbcompression yes：设置存储至本地文件时，是否压缩，默认为yes，采用LZF压缩。
• rdbchecksum yes：设置是否进行rdb文件格式校验，这个校验在读写时都会发生。
  下面我们把这些参数在配置文件中配置一下。
  
  下面我们重启下redis服务，然后重新save一下数据，在看看data目录中的文件。(这里我已经提前把之前的dump.rdb文件删除了)
  
  可以看到，我们的rdb文件名已经按照我们配置的来创建了。

redis数据恢复

我们生成rdb文件之后，什么时候会用到rdb文件来恢复数据呢？在我们启动redis服务的时候，这个时候就会读取rdb文件，从而恢复数据。

save指令工作原理

save指令说白了其实也是一条指令，当有多个客户端，同时像redis服务器发送指令，而其中有一条时save指令时，save指令会像其他指令一样，排队等待redis服务器来执行，save指令执行时，如果数据量过大，所需要花费的时间较多，后面的指令就将被阻塞在那里，这对于用户体验来说十分不友好。有什么办法可以避免这个问题呢？可以看看下面的bgsave指令。

bgsave指令与工作原理

bgsave：在后台做持久化操作，不过这个操作是异步的，bgsave指令只是告诉redis要持久化，具体什么时间点做持久化的操作这个就是由redis控制。
bgsave的工作原理如下：

• 首先客户端给服务器发送bgsave指令。
• 服务器接收到指令后会调用fork函数，创建一个子进程，具体的save操作是由这个子进程去执行。
• 子进程执行完保存操作，创建了rdb文件后，会返回给redis服务器一条消息，以得以执行结果。
  下面我们调用一下bgsave操作，然后看看子进程给redis服务器返回的执行结果。
  
  当redis服务器接收到这条信息后，就说明bgsave执行成功了。
  关于bgsave，有一个参数：stop-writes-on-bgsave-error yes：如果bgsave存储过程中发生错误，是否停止操作，默认开启。

save配置与工作原理

前面介绍的save和bgsave指令都是在发送指令后才会执行，那怎么设置定时去保存数据呢？还是通过配置文件，我们可以在配置文件中加一个参数：save second changes，意思是如果在second指定的时间范围内，有changes个key发生了变化，那么就进行保存操作，注意，这里调用的保存是bgsave。
下面我们来试一试，首先在配置文件中加入参数save 300 2，5分钟内，有2个key被修改则调用保存操作。先看看保存前的rdb文件。

然后我们随便改动2个key，再来看看这个rdb文件。

可以看到文件变小了，因为我是删除了2个key触发的保存操作。
关于怎么判断key受到改变，redis有3个判断的点：

1. 会对数据产生影响。
2. 真正产生影响，即get这种不对数据有影响的操作不会计算。
3. 不进行数据对比，比如set重复的值，他也会算两次改变。

当上面3个点都满足时，就算产生了改变。

三种save方式对比

方式	save	bgsave	配置文件(同bgsave)
读写	同步	异步	异步
阻塞客户端指令	是	否	否
消耗额外内存	否	是	是
启动新线程	否	是	是

其他rdb启动模式：

• 全量复制
• 服务器重启：debug reload。
• 关闭服务器时指定保存数据：shutdown save。

rdb优点

• rdb内部是用二进制存储，存储效率高。
• rdb内部存储的是redis某个时间点的快照，非常适合做数据备份、全量复制等。
• rdb恢复数据的速度比AOF快。
• 应用：服务器中每隔一段时间执行bgsave备份，并将rdb文件存至远程机器中，用于灾难恢复。

rdb缺点

• rdb不论是执行指令还是用配置，都不能做到实时持久化，容易丢失数据。
• bgsave每次持久化都要创建子进程，会消耗一定的性能。
• redis的众多版本中，rdb文件格式不统一，容易出现各个版本不兼容，有一个方法就是先按创建rdb文件的版本恢复数据，再把数据进行备份。