- 第4章 数据安全与性能保障
- 4.1 持久化选项
- 4.1.1 快照持久化
- 4.1.2 AOF持久化
- 4.1.3 重写/压缩AOF文件
- 4.2 复制
- 4.2.1 对Redis的复制相关选项进行配置
- 4.2.2 Redis复制的启动过程
- 4.2.3 主从链
- 4.2.4 检验硬盘写入
- 4.3 处理系统故障
- 4.3.1 验证快照文件和AOF文件
- 4.3.2 更换故障主服务器
- 4.4 Redis事务
Redis提供了两种不同的持久化方法来讲数据存储到硬盘里面。一种方法叫做 快照，它可以将存在于某一个时刻的所有数据都写到硬盘里面 。另一种方法叫 只追加文件（append-only file，AOF），它会在执行写命令时，将被执行的写命令复制到硬盘里面。
这两种持久化方法既可以同时使用，又可以单独使用，在某些情况下甚至可以两种方法都不使用，具体选择哪种持久化方法需要根据用户的数据以及应用来决定。
4.1.1 快照持久化Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。
根据配置，快照将被写入dbfilename选项指定的文件里面，并储存在dir选项指定的路径上面。如果在新的快照文件创建完毕之前，Redis，系统或者硬件这三者之中的任意一个崩溃了，那么Redis将丢失最近一次创建快照之后写入的所有数据。
创建快照的办法有以下几种
- 客户端可以通过向Redis发送BGSAVE命令来创建一个快照。对于支持BGSAVE命令的平台来说，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。
- 客户端还可以通过向Redis发送SAVE命令来创建一个快照，接到SAVE命令的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命令。
在只使用快照持久化来保存数据时，一定要记住：如果系统真的发生崩溃，用户将丢弃最近一次生成快照之后更改的所有数据。因此，快照持久化只适用那些即使丢失一部分数据也不会造成问题的应用程序，而不能接受这种数据损失的应用程序可以考虑AOF持久化。
4.1.2 AOF持久化AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据的变化。因此，Redis只要从头到尾重新执行以此AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。
AOF持久化可以通过设置appendonly yes配置选项来打开。
文件同步：在向硬盘写入文件时，至少会发生3件事。当调用file.write()方法对文件进行写入时，写入的内容首先会被存储到缓冲区，然后操作系统会在将来的某个时刻将缓冲区存储的内容写入硬盘，而数据只有在被写入硬盘之后，才算是真正地保存到硬盘里面，用户可以通过调用file.flush()方法来请求操作系统尽快地将缓冲区存储地数据写入硬盘中，但具体何时执行写入操作仍然由操作系统决定。除此之外，用户还可以命令操作系统将文件同步到硬盘，同步操作会一直阻塞直到指定的文件被写入硬盘为止，当同步操作执行完毕之后，即使系统出现故障也不会对被同步的文件造成任何影响。
下表appendfsync选项及同步频率
| 选项 | 同步频率 |
|---|---|
| always | 每个Redis写命令都要同步写入硬盘，这样做会严重降低Redis的速度 |
| everysec | 每秒执行一次同步，显式地将多个写命令同步到硬盘 |
| no | 让操作系统来决定应该何时进行同步 |
Redis会不断地将被执行的写命令记录到AOF文件里面，所以随着Redis不断运行，AOF文件的体积也会不断增长，在机端情况下，体积不断增大的AOF文件甚至可能会用完硬盘的所有可用空间。还有另一个问题就是，因为Redis在重启之后需要通过重新执行AOF文件记录的所有写命令来还原数据集，所以如果AOF文件的体积非常大，那么还原操作执行的时间可能会非常长。
为了解决AOF文件体积不断增大的问题，用户可以向Redis发送BGREWRITEAOF命令，这个命令会通过移除AOF文件中的冗余命令来重写AOF文件，使AOF文件的体积变得尽可能的小。BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似：Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写，因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF持久化中也同样存在。更糟糕的是，如果不加以控制的话，AOF文件的体积可能会比快照文件的体积大好多倍，在进行AOF重写并删除旧AOF文件的时候，删除一个体积达到数十GB大的旧AOF文件可能会导致操作系统挂起数秒。
跟快照持久化可以通过设置save选项来自动执行BGSAVE一样，AOF持久化也可以通过设置auto-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项来自动执行BGREWRITEAOF。
4.2 复制复制可以让其他服务器拥有一个不断更新的数据副本，从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求。
在需要扩展读请求的时候，或者在需要写入临时数据的时候，用户可以通过设置额外的Redis从服务器来保存数据集的副本。在接收到主服务器发送的数据初始副本之后，客户端每次向主服务器进行写入时，从服务器都会实时地得到更新。在部署好主从服务器之后，客户端就可以向任意一个从服务器发送读请求了，而不必再像之前一样，总是把每个读请求都发送给主服务器。
4.2.1 对Redis的复制相关选项进行配置当服务器连接主服务器的时候，主服务器会执行BGSAVE操作，因此为了正确的使用复制特性，用户需要保证主服务器已经正确地设置了dir选项和dbfilename选项。
开启从服务器所必须的选项只有slaveof一个。如果用户在启动Redis服务器的时候，指定了一个包含slaveof host port选项的配置文件，那么Redis服务器将根据该选项给定的IP地址和端口号来连接主服务器。对于一个正在运行的Redis服务器，用户可以通过发送SLAVEOF no one命令来让服务器终止复制操作，不再接受主服务器的数据更新；也可以通过发送SLAVEOF host port命令来让服务器开始复制一个新的主服务器。
4.2.2 Redis复制的启动过程从服务器在连接一个主服务器的时候，主服务器会创建一个快照文件并将其发送到从服务器。
表4-2 从服务器连接主服务器时的步骤
| 步骤 | 主服务器操作 | 从服务器操作 |
|---|---|---|
| 1 | 等待命令进入 | 连接（或者重连接）主服务器，发送SYNC命令 |
| 2 | 开始执行BGSAVE，并使用缓冲区记录BGSAVE之后执行的所有写命令 | 根据配置选项来决定是继续使用现有的数据来处理客户端的命令请求，还是向发送请求的客户端返回错误 |
| 3 | BGSAVE执行完毕，向从服务器发送快照文件，并在发送期间继续使用缓冲区记录被执行的写命令 | 丢弃所有旧数据，开始载入主服务器发来的快照文件 |
| 4 | 快照文件发送完毕，开始向从服务器发送存储在缓冲区里面的写命令 | 完成对快照文件的解释操作，像往常一样开始接受命令请求 |
| 5 | 缓冲区存储的写命令发送完毕：从现在开始，每执行一个写命令，就向从服务器发送相同的写命令 | 执行主服务器发来的所有存储在缓冲区里面的写命令；并从现在开始，接受并执行主服务器传来的每个写命令 |
Redis在复制进行期间也会尽可能地处理接收到的命令请求，但是，如果主从服务器之间的网络带宽不足，或者主服务器没有足够的内存来创建子进程和创建记录写命令的缓冲区，那么Redis处理命令请求的效率就会收到影响。
当多个从服务器尝试连接同一个主服务器的时候，就会出现下表所示的两种情况中的一种
| 当有新的从服务器连接主服务器时 | 主服务器的操作 |
|---|---|
| 表4-2的步骤3尚未执行 | 所有从服务器都会接收到相同的快照文件和相同的缓冲区写命令 |
| 表4-2的步骤3正在执行或者已经执行完毕 | 当主服务器与较早进行连接的从服务器执行完复制所需的5个步骤之后，主服务器会与新连接的从服务器执行一次新的步骤1至步骤5 |
在大部分情况下，Redis都会尽可能地复制所需的工作，然而，如果从服务器连接主服务器的时间不凑巧，那么主服务器就需要多做一些额外的工作。另一方面，当多个从服务器同时连接主服务器时，同步多个从服务器所占用的带宽可能会使得其他命令请求难以传递给主服务器，与主服务器位于同一网络中的
4.2.3 主从链创建多个从服务器可能会造成网络不可用——当复制需要通过互联网进行或者需要在不同数据中心之间进行时，尤为如此。因为Redis的主服务器和从服务器并没有特别不同的地方，所以从服务器也可以拥有自己的从服务器，由此形成主从链。
从服务器对从服务器进行复制在操作上和从服务器对主服务器进行复制的唯一区别在于，如果从服务器X拥有从服务器Y，那么当从服务器X在执行表4-2中的步骤4时，他将断开从服务器Y的连接，导致从服务器Y需要重新连接并重新同步。
当读请求的重要性明显高于写请求的重要性，并且读请求的数量远远超过一台Redis服务器可以处理的范围时，用户就需要添加新的从服务器来处理读请求。随着负载不断上升，主服务器可能会无法快速地更新所有从服务器，或者因为重新连接和重新同步从服务器而导致系统超载。为了缓解这个问题，用户可以创建一个由Redis主从节点组成的中间层来分担主服务器的复制工作。
为了将数据保存到多台机器上面，用户首先需要为主服务器设置多个从服务器，然后对每个从服务器设置appendonly yes选项和appendfsync everysec选项。这样的话，用户就可以让多台服务器以每秒一次的频率将数据同步到硬盘上面，这只是第一步，因为用户还必须等待主服务器发送的写命令到达从服务器，并且在执行后续操作之前，检查数据是否已经被同步到了硬盘里面。
为了验证主服务器是否已经将写数据发送到从服务器，用户需要在向主服务器写入真正的数据之后，再向主服务器写入一个唯一的虚构值，然后通过检查虚构值是否存在于从服务器来判断写数据是否已经到达从服务器。
通过检查INFO命令的输出结果aof_pending_bio_fsync属性的值是否为0，如果为0，表示服务器已经将一直的所有数据都保存到硬盘中。
4.3 处理系统故障 4.3.1 验证快照文件和AOF文件Redis提供了两个命令行程序redis-check-aof和redis-check-dump，它们可以在系统故障发生之后，检查AOF文件和快照文件的状态，并在有需要的情况下对文件进行修复。
如果用户在运行redis-check-aof程序时给定了--fix参数，那么程序将对AOF文件进行修复。程序修复AOF文件的方法非常简单，它会扫描给定的AOF文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序会删除出错的命令以及位于出错命令之后的所有命令，只保留那些位于出错命令之前的正确命令。在大多数情况下，被删除的都是AOF文件末尾的不完整的写命令。
目前没有办法可以修复出错的快照文件，尽管发现快照文件首个出现错误的地方是有可能的，但因为快照文件本身经过了压缩，而出现在快照文件中间的错误有可能会导致快照文件的剩余部分无法被读取。因此，用户最好为重要的快照文件保留多个备份。
4.3.2 更换故障主服务器在运行一组同时使用复制和持久化的Redis服务器时，用户迟早都会遇到某个或某些Redis服务器停止运行得情况。造成故障的原因可能是硬盘驱动器出错，内存出错或者电量耗尽，但无论服务器因为何种原因出现故障，用户最终都要对发生故障的服务器进行更换。
在拥有一个主服务器和一个从服务器的情况下，更换主服务器的具体步骤
假设A，B两台机器都运行着Redis，其中机器A的Redis为主服务器，而机器B的Redis为从服务器。不巧的是，机器A刚刚因为某个暂时无法修复的故障而断开了网络连接，因此用户决定将同样安装了Redis的机器C用作新的主服务器。
更换服务器的计划非常简单：首先向机器B发送一个SAVE指令，让它创建一个新的快照文件，接着将这个快照文件发送给机器C，并在机器C上面启动Redis。最后，让机器B称为机器C的从服务器。
4.4 Redis事务Redis的事务和传统关系数据库的事务并不相同。在关系数据库中，用户首先向数据库服务器发送BEGIN，然后执行各个相互一致的写操作和读操作，最后，用户可以选择发送COMMIT来确认之前所做的修改，或者发送ROLLBACK来放弃那些修改。
在Redis里面也有简单的方法可以处理一连串相互一致的读操作和写操作。Redis的事务以特殊命令MULTI为开始，之后跟着用户传入的多个命令，最后以EXEC为结束。但是由于这种简单的事务在EXEC命令被调用之前不会执行任何实际操作，所以用户将没办法根据读取到的数据来做决定。这个问题看起来似乎无足轻重，但实际上无法以一致的形式读取数据将导致某一类型的问题变得难以解决，除此之外，因为在多个事务同时处理同一个对象时通常需要用到二阶段提交，所以如果事务不能以一致的形式读取数据，那么二阶段提交将无法实现，从而导致一些原本可以成功执行的事务沦落至失败的地步。
为了避免上面提到的问题，需要使用UNWATCH和DISCARD命令。在用户使用WATCH命令对键进行监视之后，直到用户执行EXEC命令的这段时间里面，如果有其他客户端抢先对任何被监视的键进行了替换，更新或者删除等操作，那么当用户尝试执行EXEC命令的时候，事务将失败并返回一个错误。
通过使用WATCH，MULTI/EXEC，UNWATCH/DISCARD等命令，程序可以在执行某些重要操作的时候，通过确保自己正在使用的数据没有发生变化来避免数据出错。
