上一篇文章：Python--Redis实战：第四章：数据安全与性能保障：第3节：AOF持久化
下一篇文章：Python--Redis实战：第四章：数据安全与性能保障：第5节：处理系统故障

对于有扩展平台以适应更高负载经验的工程师和管理员来说，复制(replication)是不可或缺的。复制可以让其他服务器拥有一个不断地更新的数据副本，从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求，。关系数据库通常会使用一个主服务器（

master）向多个从服务器（slave）发送更新，并使用从服务器来处理所有读请求。Redis也采用了同样的方法来实现自己的复制特性，并将其用作扩展性能的一种手段。本节将对Redis的复制配置选项进行讨论，并说明Redis在进行复制的各个步骤。

尽管Redis的性能的非常优秀，但它也会遇上没办法快速的处理请求的情况，特别是在对集合和有序集合进行操作的时候，涉及的元素可能会有上万个甚至上百万个，在这种情况下，执行操作所花费的时间可能需要以秒来进行计算，而不是毫秒或者微妙。但即使一个命令值需要花费10毫秒就能完成，单个Redis实例1秒也只能处理100个命令。

sunionstore命令的性能：
作为对Redis性能的一个参考，在主频为2.4GHz的英特尔酷睿2处理器上，对两个分别包含10 000个元素的集合执行sunionstore命令并产生一个包含20 000个元素的结果集合，需要花费Redis七八毫秒的时间。

在需要扩展读请求的时候，或者在需要写入临时数据的时候，用户可以通过设置额外的Redis【从服务器】来保存数据集的副本。在接受到主服务器发送的数据初始副本（initial copy of data）之后，客户端每次向【主服务器】进行写入时，【从服务器】都会实时地得到更新。在部署好主从服务器之后，客户端就可以向任意一个服务器发送读请求了，而不必再像之前一样，总是把每个读请求都发送给主服务器（客户端通常会随机地选择使用哪个从服务器，从而将负载平均分配到各个从服务器上）。

接下来将介绍配置Redis主从服务器的方法，并说明Redis在整个复制过程中所做的各项操作。

对Redis的复制相关选项进行配置

之前介绍过，当从服务器连接主服务器的时候，主服务器会执行bgsave操作。因此为了正确的使用复制特性，用户需要保证主服务已经正确的配置了dir选项和dbfilename选项，并且这两个选项所指示的路径和文件对于Redis进程来说都是可写的。

尽管有多个不同的选项可以控制从服务器自身的行为，但开启从服务器所必须的选项只有slaveof一个。如果用户在启动Redis服务器的时候，指定了一个包含slaveof host port选项的配置文件，那么Redis服务器将根据该选项给定的IP地址和端口号来连接主服务器。对于一个正在运行的Redis服务器，用户可以通过发送slaveof no one命令来让服务器终止复制操作，不再接受主服务器的数据更新，也可以通过发送slaveof host port命令来让服务器开始复制一个新的主服务器。

开启Redis的主从复制特性并不需要进行太多的配置，但了解Redis服务器是如何变成主服务器或者从服务器的，对于我们来说将是非常有用和有趣的过程。

Redis复制的启动过程

上面曾将说过，从服务器在连接一个主服务器的时候，主服务器会创建一个快照文件并将其发送至从服务器，但这只是主从复制执行的其中一步，下表完整的列出了当从服务器连接主服务器时，主从服务器执行的所有操作：

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

Redis在复制进行期间也会尽可能地处理接受到的命令请求，但是，如果主从服务器之间的网络带宽不足，或者主服务器没有足够的内存来创建子进程和创建记录写命令的缓冲区，那么Redis处理命令请求的效率会受到影响。因此，尽管这并不是必需的，但在实际中华最好还是让主服务器只使用50%~65%的内存，预留30%~45%烦人内存用于执行bgsave命令和创建记录写命令的缓冲区。

设置从服务器的步骤非常简单，用户既可以通过配置选项slaveof host port来将一个Redis服务器设置为从服务器，又可以通过向运行中的Redis服务器发送slaveof命令来将其设置为从服务。如果用户使用的是slaveof配置选项，那么Redis在启动时首先载入当前可用的任何快照问价或者AOF文件，然后连接主服务并执行上表的复制过程。如果用户使用的是slaveof命令，那么Redis会立即尝试连接主服务器，并在连接成功后，开始上表所示的复制过程。

从服务器在运行同步时，会清空自己的所有数据：

因为有些用户在第一次使用从服务器时会忘记这件事，所以在这里要特别提醒一下：从服务器在于主服务器进行初始连接时，数据库中原有的所有数据将丢失，并被替换成主服务器发送来的数据。

警告：Redis不支持主主复制：

因为Redis允许用户在服务器启动之后使用slaveof命令来设置从服务器选项，所以可能会有读者误以为可以通过将两个Redis实例互相设置为对方的主服务器来实现多主复制，遗憾的是，这种做法是行不通的：被互相设置为主服务器的两个Redis实例只会持续的占用大量处理器资环并持续不断的尝试与对方进行通信，根据客户端链接的服务器的不同，客户端的请求可能会得到不一致的数据或者完全得不到数据。

当多个从服务器尝试连接同一个主服务器的时候，机会出现下表所示的两种情况中的一种：

当有新的从服务器连接主服务时	主服务器的操作
当上表步骤3尚未执行	所有从服务器都会接受到相同的快照文件和相同的缓冲区写命令
当上表步骤3正在执行或者已经执行完毕	当主服务器与较早进行连的从服务器执行完复制所需的5个步骤之后，主服务会与新连接的从服务器执行一次进的步骤1至步骤5.

在大部分情况下，Redis都会尽可能地减少复制所需的工作，然而，如果从服务器连接主服务器的时间并不凑巧，那么主服务器就需要多做一些额外的工作，。另一方面，当多个从服务器同时连接主服务器的时候，同步多个主服务器所占用的宽带可能会使得其他命令请求难以传递给主服务器，与主服务器位于同一网络中的其他硬件的网速可能也会因此而降低。

主从链

有些用户发现，创建多个从服务器可能或造成网络不可用：当复制需要通过互联网进行或者需要在不同数据中心之间进行时，尤为如此。因为Redis的主服务和从服务器并没有特别不同的地方，所以从服务器也可以拥有自己的从服务器，并由此形成主从链。

从服务器对从服务器进行复制在操作上和佛那个服务器对主服务器进行复制的唯一区别在于，如果从服务器X拥有从服务器Y，那么当从服务器X在执行上节复制步骤的步骤4时，它将断开与从服务器Y的连接，导致从服务器Y需要重新连接并重新同步。

当【读请求】的重要性明显高于【写请求】的重要性，并且读请求的数量远远超出一台Redis服务器可以处理的范围时，用户就需要添加新的从服务器来处理【读请求】。随着负载不断上升，主服务器可能会无法快速地更新所有从服务器，或者因为重新连接和重新同步从服务器而导致系统超载。为了缓解这个问题，用户可以创建一个由Redis主从节点组成的中间层来分担主服务器的复制工作。如下图所示：

图片描述

一个Redis主从复制树示例，树的中层有3个帮助开展复制工作的服务器，底层与9个从服务器。

尽管主从服务器之间并不一定要像上图那样组成一个树状结构，但记住并理解这种树状结构对于Redis复制来说是可行的并且是合理的，有主于读者理解之后的内容。AOF持久化的同步选项可以控制数据丢失的时间长度：通过将每个写命令同步到硬盘里面，用户几乎可以不损失任何数据（除非系统崩溃或者硬盘驱动器损坏），但这种做法会对服务器的性能造成影响；另一方面，如果用户将同步的频率设置为每秒一次，那么服务器的性能将回到正常水平，但故障可能会造成1秒的数据损失。通过同时使用复制和AOF持久化，我们可以将数据持久化到多台服务器上面。

为了将数据保存到多台服务器上面，用户首先需要为主服务器设置多个从服务器，然后对每个从服务设置appendonly yes选项和sppendonly everysec选项（如果有需要得我话，也可以对主服务器进行相同的设置），这样的话，用户就可以让多台服务器以每秒1次的频率将数据同步到硬盘上了，但这还只是第一步：因为用户还必须等待主服务器发送的写命令到达从服务器，并且在执行后续操作之前，检查数据是否已经被同步到硬盘里面。

检查硬盘写入

为了验证主服务器是否已经将写数据发送至从服务器，用户需要在向主服务器写入真正的数据之后，再向从服务器写入一个唯一的虚构值，然后通过验证虚构值是否存在于从服务器来判断写数据是否已经到达从服务器，这个操作很容易就可以实现。另一方面，判断数据是否已经被保存到硬盘里面则要困难的多。对于每秒同步一次AOF文件的Redis服务器来说，用户总是可以通过等待1秒来确保数据已经被保存到硬盘里面，但更节约时间的做法是，检查info命令的输出结果中aof_pending_bio_fsync属性的值是否为0，如果是的话，那么就表示服务器已经将已知的所有数据都保存到硬盘里面了。在向主服务器写入数据之后，用户可以将主服务器和从服务器的连接作为参数，调用下面函数来能自动进行上述的检查操作。

import time
import uuiddef wait_for_sync(mconn,sconn):identifier=str(uuid.uuid4())#将令牌添加至主服务器mconn.zadd('sync:wait',identifier,time.time())#如果有必要的话，等待从服务器完成同步while not sconn.info()['master_lin_status']!='up':time.sleep(.001)#等待从服务器接收数据更新while not sconn.zscore('sync:wait',identifier):time.sleep(.001)deadline=time.time()+1.01#最多只等待一秒while time.time()<deadline:#检查数据更新是否已经被同步到了硬盘if sconn.info()['aof_pending_bio_fsync']==0:break#清理刚刚创建的新令牌以及之前可能留下的旧令牌mconn.zrem('sync:wait',identifier)mconn.zremrangebyscore('sync:wait',0,time.time()-900)

info命令中的其他信息：
info命令提供了大量的与Redis服务器当前状态相关的信息，比如内存占用量、客户端连接数、每个数据库包含的键的数量、上一次创建快照文件之后执行的命令数量、等待。总的来说，info命令对于了解Redis服务器的综合状态非常有帮助，网上有很多资源对info命令进行了详细的介绍。

为了确保操作可以正确执行，上面函数会首先确认从服务器已经连接上主服务器，然后检查自己添加到等待同步有序集合里面的值是否已经存在于从服务器。在发现值已经存在于从服务器之后，函数会检查从服务器写入缓冲区的状态，并在一秒之内，等待从服务器将缓冲区中的所有数据写入硬盘里面。虽然函数最多会花费1秒来等待同步完成，但实际上大部分同步都会在很短的时间完成。最后，在确认数据已经被保存到硬盘之后，函数会执行一些清理操作。

通过同步使用复制和AOF持久化，用户可以增强Redis对于系统崩溃的抵抗能力。