Redis的数据安全

Redis的数据安全

Redis支持将数据持久化至硬盘，是Redis非常有用的一个特性，之前介绍的Redis可以存储比实际内存大的数据，就是依赖这一特性，即将不常用的数据持久化到硬盘中。现在，让我们来看看Redis是如何将数据存储到硬盘里面，使得数据在Redis重启之后依然存在的。

一.持久化选项

Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。一种方法叫快照，它可以将存在于某一时刻的所有数据都写入硬盘里面。另一种方法叫只追加文件(AOF)，它会在执行写命令时，将被执行的写命令复制到硬盘里面。这两种持久化方法既可以同时使用，也可以单独使用，在某些情况下甚至可以两种都不使用，具体选择哪种持久化方案需要根据具体场景来选择。

将内存中的数据存储到硬盘的一个重要原因是为了在以后重用数据，或者是为了防止系统故障而将数据备份到一个远程位置。

1.快照持久化

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本(主从同步会利用这点)，还可以将快照留在原地以便重启服务器时使用。

值得注意的是，根据配置，快照将被写入dbfilename选项指定的文件里面，并存储在dir选项指定的路径上面。 如果在新的快照文件创建完毕之前，Redis，系统或者硬件这三者之中的任意一个崩溃了，那么Redis将丢失最近一次创建快照之后写入的所有数据，这是快照持久化的一个重要问题。

客户端可以通过想Redis发送BGSAVE命令来创建一个快照，对于支持BGSAVE命令的平台来说，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。

客户端还可以通过向Redis发送SAVE命令来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前将不再响应任何额其他命令。SAVE命令并不常用， 我们通常只会在没有足够内存去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令。不过虽然SAVE会一直阻塞Redis直到快照生成完毕，但是因为它不需要创建子进程，所以就不会想BGSAVE一样因为创建子进程而导致Redis停顿，并且因为没有紫禁城在争抢资源，所以 SAVE创建快照的速度会比BGSAVE创建快照的速度要来得更快一些。

如果用户设置了save配置选项，比如save 60 10000,那么从Redis最近一次创建快照之后开始算起，当"60秒内有10000次写入"这个条件被满足时，Redis就会自动触发BGSAVE命令。如果用户设置了多个save配置选项，那么当任意一个save配置选项所设置的条件被满足时，Redis就会 触发一次BGSAVE命令。

当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不在执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器。

当一个Redis服务器连接另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者从服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令。

再次强调，在只使用快照持久化来保存数据时，一定要记住： 如果系统真的发送崩溃，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化只适用于那些即使丢失一部分数据也不会造成问题的应用程序。

2.AOF持久化

简单来说，AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。因此，Redis只要从头到尾从新执行一次AOF文件包含的所有写命令，就可以回复AOF文件所记录的数据集。

在向硬盘写入文件时，至少会发生3件事。当调用file.write()方法对文件进行写入时，写入的内容首先会被存储到缓冲区，然后操作系统会在将来的某个时候将缓冲区存储的内容写入硬盘，而数据只有在被写入硬盘之后，才算是真正地保存到了硬盘里面。用户可以通过file.flush()方法来请求操作系统尽快地将缓冲区存储的数据写入硬盘里，但具体何时执行写入操作仍然由操作系统决定。

Redis的AOF持久化可以配置三个参数，always，everysec,no。always表示每个Redis写命令都要同步写入硬盘，这样做会严重降低Redis的速度。everysec每秒执行一次同步，显示地将多个写命令同步到硬盘。no是让操作系统来决定何时进行同步。

我们知道通过配置AOF持久化的参数，AOF持久化可以将丢失数据的时间降低至1秒(everysec)，甚至不丢失任何数据(always)，又可以在极短的时间内完成定期的持久化操作，那么我们有什么理由不使用AOF持久化呢？但是这个问题实际上并没有那么简单 ，AOF文件的体积也会不断增长，在极端情况下，体积不断增大的AOF文件甚至可能会用完磁盘的所有可用空间。还有一个问题就是，因为Redis在重启之后需要通过重新执行AOF文件记录的所有写命令还原数据集，所以如果AOF文件的体积非常大，那么还原操作执行的时间就可能会非常长，这是AOF持久化存在的问题。

用户可以向Redis发送BGREWRITEAOF命令，这个命令会移除AOF文件中冗余命令来重写AOF文件，使AOF文件的体积变得尽可能地小。BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似:Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写。

二.复制

对于有扩展平台以适应更高负载经验的工程师和管理员来说，复制是不可或缺的。复制可以让其他服务器拥有一个不断地更新的数据副本，从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求。关系数据库通常会使用一个主服务器向多个从服务器发送更新，并使用从服务器来处理所有读请求。Redis也采用了同样的方法来实现自己的复制特性，并使用从服务器来处理所有读请求。

在需要扩展读请求的时候，或者在需要写入临时数据的时候，用户可以通过设置额外的Redis从服务器来保存数据集的副本。在接收到主服务器发送的数据初始副本之后，客户端每次向主服务器进行写入时，从服务器都会实时地得到更新。在部署好主从服务器之后，客户端就可以向任意一个从服务器发送读请求了，而不必再像之前一样，总是把每个读请求都发送给主服务器。

下面介绍下复制过程中，从服务器连接主服务器的步骤：

1.从服务器连接主服务器，发送SYNC命令。

2.主服务器开始执行BGSAVE命令，并使用缓冲区记录BGSAVE之后执行的所有写命令。

3.从服务器根据配置决定继续使用现有数据处理客户端的命令请求还是向客户端返回错误。

4.主服务器BGSAVE执行完毕，向从服务器发送快照文件，并在发送期间继续使用缓冲区记录被执行的写命令。

5.从服务器丢弃所有旧数据，开始载入主服务器发来的快照文件。

6.主服务器快照发送完毕，开始向从服务器发送存储在缓冲区里面的写命令。

7.主服务器缓冲区存储的写命令发送完毕，从现在开始，每执行一个写命令，就向从服务器发送相同的写命令。

8.从服务器执行主服务器发来的所有存储在缓冲区里面的写命令，并从现在开始，接收并执行主服务器传来的每个写命令。

值得注意的是，Redis是不支持主主复制的。不过从服务器可以拥有自己的从服务器，从而形成主从链。

随着负载不断上升，主服务器可能会无法快速地更新所有从服务器，或者因为重新连接和重新同步从服务器而导致系统超载。为了缓解这个问题，用户可以创建一个由Redis主从节点组成的中间层来分担主服务器的复制工作。

三.处理系统故障

Redis是一个软件，它运行在硬件之上，即使软件和硬件都设计的完美无瑕，也有可能会出现停电，故障等情况，下面先来看看在出现系统故障时，用户应该采取什么措施。

1.验证快照文件和AOF文件

无论是快照持久化还是AOF持久化，都提供了在遇到系统故障时进行数据修复的工具。Redis提供了两个命令行程序redis-check-aof和redis-check-dump，他们可以在系统故障发生后，检查AOF文件和快照文件的状态，并在有需要的情况下对文件进行修复。程序修复AOF文件的方法非常简单：它会扫描给定的AOF文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序会删除出错的命令以及位于出错命令之后的所有命令。遗憾的是，目前并没有办法可以修复出错的快照文件，因为快照文件本身经过了压缩，导致出现在快照文件中间的错误有可能导致快照文件的剩余部分无法被读取。

2.更换故障主服务器

假设A,B两台机器都运行着Redis，其中机器A的Redis为主服务器，而机器B的Redis为从服务器。机器A因为故障断开了网络连接，因此决定用机器C作为新的主服务器。

更换服务器的计划非常简单：首先向机器B发送一个SAVE命令，让它创建一个新的快照文件，接着将这个快照文件发送给机器C，并在机器C上面启动Redis，最后让机器B成为机器C的从服务器。

这里为什么用SAVE命令而不是BGSAVE命令，以及SAVE之后的Redis写命令如何发送到机器C，书中没有介绍，我也不好下结论。

另一种创建新的主服务器的方法，就是将从服务器升级为主服务器，并为升级后的主服务器创建从服务器。