Redis（三）数据安全和性能保障

持久化选项

Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。一种方法叫快照（snapshotting）,它可以将存在于某一时刻的所有数据都写入到硬盘里面。另一种方法叫只追加文件（AOF）,它会在执行写命令时，将执行的写命令复制到硬盘里面。

快照持久化（RDB)

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。根据配置，快照将被写入dbfilename选项指定的文件里面，并储存在dir选项指定的路径上面。
配置文件内容：

save配置项：

用户可根据实际情况设置save配置项

创建快照的几种方法

• 客户端可以通过向Redis发送BGSAVE命令来创建一个快照。对于支持BGSAVE命令的平台来说（基本上所有的平台都支持，除了Windows）平台，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。
• 客户端还可以通过向Redis发送SAVE命令来创建一个快照，接到SAVE命令来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前将不再响应任何其他命令。SAVE命令并不常用，通常只会在没有足够内存去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令。
• 如果用户设置了save配置选项，，比如save 60 10000，那么从Redis最近一次创建快照之后开始算起，当“60秒内有10000次写入”这个调价满足时，Redis就会自动触发BGSAVE命令。如果用户设置了多个save配置选项，那么当任意一个save配置选项所设置的条件被满足时，Redis就会h触发一次BGSAVE命令。（这种使用最多）
• 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所哟客户端，步再执行客户端发送的任何命令，并在SAVE 命令执行完毕之后关闭服务器。
• 当一个Redis服务器连接另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令

快照持久化的的优缺点

RDB持久化时全量备份，一次保存整个数据库，恢复数据速度快。但保存时间间隔长，随着Redis占用的内存越来越多，BGSAVE创建子进程时耗费的时间也会越来越多。为防止Redis因为创建子进程而出现的停顿，可以考虑关闭自动保存，转而通过手动发送BGSAVE或者SAVE来进行持久化。手动发送BGSAVE一样会引起停顿，唯一不同的是用户可以通过手动发送BGSAVE命令来控制停顿出现的时间。另一方面，SAVE会一直阻塞Redis直到快照生成完毕，但是因为它不需要创建子进程，所以不像BGSAVE一样因为创建子进程而导致Redis停顿；并因为没有子进程在争抢资源，所以SAVE创建快照的速度会比BGSAVE创建的快照速度要快一些。

AOF持久化

AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。（存储的时命令，而不是真实的数据）默认不开启。Redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件中所记录的数据集。
配置选项：

appendfsync always      # 每个Redis写命令都要同步写入硬盘，数据丢失最少，但这样做会严重降低Redis的速度，写入放大问题
appendfsync everysec    # 每秒执行同步一次，显示地将多个写命令同步到硬盘，最多只丢失1秒
appendfsync no           # 让操作系统来决定应该何时进行同步，会丢失不定数量的数据

AOF持久化的优缺点

AOF持久化既可以将丢失数据的时间窗口降低至1秒（甚至不丢失任何数据），又可以在极短的时间内完成定期持久化操作，但随着Redis不断运行，不断的将被执行的写命令记录到AOF文件里面，AOF文件的体积也会不断增大，如果AOF文件的体积非常大，那么还原操作执行的时间就可能会非常长。

重写/压缩AOF文件

• 客户端向Redis服务器发送BGREWRITEAOF命令，这个命令通过移除AOF文件中的冗余命令来重写AOF文件，使AOF文件的体积变得尽可能小。
• 通过设置auto-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项来自动执行BGREWRITEAOF，例如：当AOF文件的体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍的时候，Redis将执行BGREWRITEAOF命令。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

总结

无论是使用RDB持久化还是AOF持久化，将数据持久化到硬盘上都是非常有必要的，但除了持久化外，用户还必须对持久化所得的文件进行备份（最好备份到多个不同的地方），这样才能尽量避免数据丢失事故发生。如果条件允许的话，最好能将快照文件和最新重写的AOF文件备份到不同的服务器上面。

复制

复制可以让其他服务器用有一个不断地更新的数据副本，从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求。
系统的主要运行机制：

• 当一个 master 实例和一个 slave 实例连接正常时， master 会发送一连串的命令流来保持对 slave 的更新，以便于将自身数据集的改变复制给 slave ， ：包括客户端的写入、key 的过期或被逐出等等。
• 当一个 master 实例和一个 slave 实例连接正常时， master 会发送一连串的命令流来保持对 slave 的更新，以便于将自身数据集的改变复制给 slave ， ：包括客户端的写入、key 的过期或被逐出等等。
• 当无法进行部分重同步时， slave 会请求进行全量重同步。这会涉及到一个更复杂的过程，例如 master 需要创建所有数据的快照，将之发送给 slave ，之后在数据集更改时持续发送命令流到 slave 。

配置项

主服务器（Master）：

dbfilename dump.rdb
dir /var/lib/redis

从服务器（Slave）：

slaveof host port   # Redis将根据该选项给定的IP地址和端口号来连接主服务器

一个正在运行的Redis服务器，用户可以通过发送SLAVEOF no one命令来让服务器终止复制操作

Redis复制的启动过程

步骤	主服务器操作	从服务器操作
1	（等待命令进入）	连接（或着重连接）主服务器，发送SYNC命令
2	开始执行BGSAVE，并使用缓冲区记录BGSAVE之后执行的所有命令	根据配置选项来决定是继续使用现有的数据（如果有点话）来处理客户端的命令请求，还是向发送请求的客户端返回错误
3	BGSAVE执行完毕，向从服务器发送快照文件，并在发送期间继续使用缓冲区记录被执行的写命令	丢弃所有旧数据（如果有点话），开始载入主服务器发来的快照文件
4	快照文件发送完毕，开始向从服务器发送存储在缓冲区里面的写命令	完成对快照文件的解释操作，像往常一样开始接收命令请求
5	缓冲区存储的写命令发送完毕；从现在开始，每执行一个写命令，就向从服务器发送相同的写命令	执行服务器发来等待所有存储在缓冲区里面的写命令；并从现在开始，接收并执行主服务器传来的每个写命令

Redis在复制进行期间也会尽可能地处理接收到的命令请求，但是，如果主从服务器之间的网络宽带不足，或者主服务器没有足够的内存来创建子进程和创建记录写命令的缓冲区，那么Redis处理命令请求的效率就会受到影响。因此，在实际中最好让主服务器只使用50%-65%的内存，剩下的内存用于执行BGSAVE命令和创建记录命令的缓冲区。

设置从服务器的步骤非常简单，用户既可以通过配置选项SLAVEOF host poort来将一个Redis服务器设置为从服务器，又可以通向运行中的Redis服务器发送SLAVEOF命令来将其设置为从服务器。如果用户使用的是SLAVEOF配置选项，那么Redis在启动时首先会载入当前可用的任何快照文件或者AOF文件，然后连接主服务器并执行复制过程。如果使用的是SLAVEOF命令，那么Redis会立即尝试连接主服务器，并在连接成功之后，开始复制过程。
注意：从服务器在进行同步时，会清空自己的所有数据，Redis不支持主主复制

主从链

Redis的从服务器也可以拥有自己的从服务器，并由此形成主从链。从服务器对从服务器进行复制操作在操作上和从服务器对主服务器进行复制唯一区别在于，如果从服务器X拥有从服务器Y，那么当从服务器X在执行复制操作时，它将断开与从服务器Y的连接，导致从服务器Y需要重新连接并重新同步。

检验硬盘写入

为了验证主服务器是否已经将写数据发送至从服务器，用户需要在向主服务器写入真正的数据之后，再向主服务器写入一个唯一的虚构值，然后通过检查虚构值是否存在于从服务器来判断写数据是否已经达到从服务器，这个操作很容易就可以实现。判断是否已经保存到硬盘里面则要困难的多。对于AOF持久化，可以检查INFO命令的输出结果aof_pengding-bio-fsync属性的值是否为0，如果是的话，那么就表示服务器已经将已知的数据都保存到硬盘里面了。

处理系统故障

必须做好相应的准备来应对Redis的系统故障

验证快照文件和AOF文件

无论事快照持久化还是AOF持久化，都提供了在遇到系统故障时进行数据恢复的工具。Redis提供了两个命令行程序redis-check-aof和redis-check-dump，它们可以在系统故障发生之后，检查AOF文件和快照文件的状态，并在有需要的情况下对文件进行修复。

redis-check-aof
redis-check-dump

如果用户在运行redis-check-aof程序时给定了–fix参数，那么程序将对AOF文件进行修复。程序修复AOF文件的方法非常简单：它会扫描给定的AOF文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序会删除出错的命令以及位于出错命令之后的所有命令，只保留那些位于出错命令之前的正确命令，大多数情况下被删除的都是AOF文件末尾的不完整的写命令。
遗憾的是，目前没有办法可以修复出错的快照文件，因此，最好为重要的快照文件保留多个备份。

更换故障主服务器

假设A、B两台机器都运行着Redis，其中机器A的Redis为主服务器，而机器B为从服务器，现在A出现故障，需要将同样安装了Redis的机器C作为新的主服务器

1.向B机器发送一个SAVE命令，创建一个新的快照文件
2.将这个快照文件发送给机器C
3.启动机器C上的Redis

Redis事务

在多个客户端同时处理不相同的数据时，不谨慎的操作很容易会导致数据出错，可以使用Redis事务来防止数据出错，还可以提升性能。
Redis的事务已MULTI开始，之后跟着用户传入的多个命令，最后以EXEC为结束。Redis在执行事务的过程中，会延迟执行已入队的命令直到客户端EXEC命令为止。可以通过减少客户端与Redis服务器之间的网络通信次数来提升Redis在执行多个命令时的性能。
使用WATCH命令对键进行监视之后，直到执行EXEC命令的这段时间里面，如果有其他客户端抢先对任何被监视的键进行替换、更新或删除等操作，那么当用户尝试执行EXEC命令时，事务将失败并返回一个错误。UNWATCH或DISCARD命令可以在MULTI命令执行之后、EXEC命令执行之前对连接进行重置。

为什么Redis没有实现典型的枷锁功能？

如果有其他客户端试图对被加锁的数据进行写入，那么该客户端将被阻塞，直到第一个事务执行完毕，加锁非常有效，但是缺点在于持有锁的客户端运行越慢，等待解锁的客户端被阻塞的时间就越长。Redis为了尽可能的减少客户端的等待时间，并不会在执行WATCH命令时对数据进行加锁。Redis只会在数据已经被其他客户端抢先修改了情况下，通知执行了WATCH命令的客户端，这种做法被称为乐观锁。

性能测试

要对Redis的性能进行优化，首先需要弄清楚各种类型的Redis命令到底能跑多快，可以通过Redis附带的性能测试程序redis-benchmark来得知

$ redis-benchmark -c 1 -q   # -q让程序简化输出结果 -c 1让程序只使用1个客户端来进行测试