08_Redis持久化——RDB方式

【简述】

持久化：Redis能将数据从内存中以某种形式同步到硬盘中，使得重启后可以根据硬盘中的记录恢复数据，这一过程就是持久化。

Redis支持两种方式的持久化，简单来说如下：

RDB方式：会根据指定的规则”定时“将内存中的数据存储在硬盘上

AOF方式：在每次执行命令后将命令本身记录下来。

【RDB方式】

RDB（Redis Database）

RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时，即在指定的时间间隔内，Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上，这个过程即为”快照“。

数据恢复时，将快照文件直接再读取到内存。

Redis会在以下情况下对数据进行快照：

1.根据配置规则进行自动快照

2.用户执行 SAVE 或 BGSAVE 命令

3.执行FLUSHALL命令

4.执行复制（replication）时

【1.根据配置规则进行自动快照】

Redis允许用户自定义快照条件，当符合快照条件时，Redis会自动执行快照操作。

进行快照的条件可以由用户在配置文件redis.conf中自定义。

由两个参数构成：时间窗口M 和 改动的键的个数N

每当时间M被更改的键的个数> N时，即符合快照条件。

redis配置文件中预留的三个快照条件：

save 900 1

save 300 10                   //300秒内至少有10个键被修改

save 60 10000

每条快照条件占一行，并且以save参数开头，各个条件之间是”或“的关系。

【2.用户执行SAVE或BGSAVE命令】

除了Redis自动进行快照外，当进行服务重启、手动迁移以及备份时，我们也会用到手动快照操作。

[ SAVE 命令]

当执行SAVE命令时，Redis同步地进行快照操作，在快照执行的过程中，会阻塞所有来自客户端的请求，当Redis中的数据比较多时，这一过程会导致Redis较长时间不响应，所以要尽量避免在生产环境中使用这一命令。

[ BGSAVE命令 ]

需要手动快照时，推荐使用BGSAVE命令。BGSAVE命令可以在后台异步地进行快照操作，快照的同时，服务器依然可以继续响应来自客户端的请求。执行BGSAVE后，Redis会立即返回OK表示开始执行快照操作。如果想知道快照是否完成，可以通过LASTSAVE命令获取最经一次成功执行快照的时间，返回结果是一个Unix时间戳。

【3.执行FLUSHALL命令】

当执行FLUSHALL命令时，Redis会清除Redis中的所有数据，

需要注意，不论清空Redis的过程中是否触发了自动快照条件，只要自动快照的条件不为空，Redis就会执行一次快照操作。

如：当定义的快照条件为1秒内修改10000个键时自动快照，而当Redis中只有一个键时，执行FLUSHALL也会触发快照，即使这一过程实际上只有一个键被修改了。

注意：当没有定义自动快照条件时，即使执行FLUSHALL则不会进行快照。

【4.执行复制时】

当设置了主从模式时，Redis会在复制初始化时进行自动快照。

当使用复制时，即使没有自定义快照条件，并且没有手动执行快照操作，也会生成RDB快照文件。

【快照的原理】

Redis默认会将快照文件存储在Redis当前进程的工作目录中的dump.rdb文件中，可以通过配置dir和dbfilename两个参数分别执行快照的存储路径和文件名。

[ 快照的过程 ]

1.Redis使用fork函数复制一份当前进程（父进程）的副本为子进程。

2.父进程会继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。

3.当子进程写入完所有数据会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

【RDB文件】

通过上述快照的过程，可以发现Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。

我们可以通过定时任务备份RDB文件来实现Redis数据备份。

Redis启动后会读取RDB快照文件，将数据从硬盘中载入到内存。通常将一个记录1000万个字符串类型键、大小为1GB的快照文件载入到内存中需要20~30秒。

通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据，如果丢失近几秒的数据或者丢失最近更新的几十个键没有很大的影响，可以使用RDB方式，如果数据相对重要，希望将损失降到最小，可以使用AOF方式进行持久化。

【总结——RDB方式的优点】

1.RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。
你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本。
2.基于上面所描述的特性，RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。
3.RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。
4.比起AOF，在数据量比较大的情况下，RDB的启动速度更快。

【总结——RDB方式的缺点】

1.RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，
那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。
2.RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，
造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。