Redis数据持久化，安全

一、redis数据持久化

由于redis是一个内存数据库，如果系统遇到致命问题需要关机或重启，内存中的数据就会丢失，这是生产环境所不能允许的。所以redis提供了数据持久化的能力。

redis提供了两种持久化数据的方式，分别是RDB和AOF，这两种方式都是把数据写到硬盘上，实现内容数据的备份，在需要的时候redis会读取RDB或AOF文件，重新把数据加载到内存中，从而实现数据的恢复。

这两种持久化方式因为原理不同，因此各有优缺点，可根据实际情况灵活选用。

1、RDB

RDB原理

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照（Snapshot）存储，是默认的持久化方式。

RDB也是一种半持久化模式，因为它会按照一定的策略周期性的将数据保存到磁盘，产生名为dump.rdb（可以在配置中修改生成的数据文件名称）的数据文件，生成快照的周期策略可以通过配置文件定义。

RDB优点

从上面的原理可以看到，RDB方式有如下优点：

RDB是一个非常紧凑的文件,它保存了某个时间点得完整数据集,非常适用于数据集的备份
RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心，非常适用于灾难恢复.
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB缺点

当然RDB方式也有一些缺点：

Redis在意外停止工作（例如电源中断）的情况下会丢失上一次备份到现在的数据
RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求

2、AOF

AOF原理

AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据。

因为 AOF 的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。举个例子，如果你对一个计数器调用了 100 次 INCR ，那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。然而在实际上，只使用一条 SET 命令已经足以保存计数器的当前值了，其余 99 条记录实际上都是多余的。

为了处理这种情况， Redis 支持一种有趣的特性：可以在不打断服务客户端的情况下，对 AOF 文件进行重建（rebuild）。执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件，这个文件包含重建当前数据集所需的最少命令。

AOF优点

从上面的原理可以看到，AOF方式有如下优点：

使用AOF方式备份的数据更完整
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的策略，AOF 的速度可能会慢于 RDB 。

作者： atwal
链接：http://www.imooc.com/article/11205
来源：慕课网
本文原创发布于慕课网，转载请注明出处，谢谢合作！