Redis的复制特性

对于有扩展平台以适应更高负载经验的工程师和管理员来讲，复制（replication）是不可或缺的。复制可让其余服务器拥有一个不断更新的数据副本，从而使得拥有数据副本的服务器能够用于处理客户端发送的读请求。关系数据库一般会使用一个主服务器（master）向多个从服务器（slave）发送更新，并使用从服务器来处理全部读请求。Redis也采用了一样的方法来实现本身的复制特性，并将其用做扩展性能的一种手段。本节将对Redis的复制配置选项进行讨论，并说明Redis在进行复制时的各个步骤。

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

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

在须要扩展读请求的时候，或者在须要写入临时数据的时候，用户能够经过设置额外的Redis从服务器来保存数据集的副本。在接收到主服务器发送的数据初始副本（initialcopyofthedata）以后，客户端每次向主服务器进行写入时，从服务器都会实时地获得更新。在部署好主从服务器以后，客户端就能够向任意一个从服务器发送读请求了，而没必要再像以前同样，老是把每一个读请求都发送给主服务器（客户端一般会随机地选择使用哪一个从服务器，从而将负载平均分配到各个从服务器上）。

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

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

当从服务器链接主服务器的时候，主服务器会执行BGSAVE操做。所以为了正确地使用复制特性，用户须要保证主服务器已经正确地设置了dir选项和dbfilename选项，而且这两个选项所指示的路径和文件对于Redis进程来讲都是可写的（writable）。

尽管有多个不一样的选项能够控制从服务器自身的行为，但开启从服务器所必须的选项只有slaveof一个。若是用户在启动Redis服务器的时候，指定了一个包含slaveofhostport选项的配置文件，那么Redis服务器将根据该选项给定的IP地址和端口号来链接主服务器。对于一个正在运行的Redis服务器，用户能够经过发送SLAVEOFnoone命令来让服务器终止复制操做，再也不接受主服务器的数据更新；也能够经过发送SLAVEOF host port命令来让服务器开始复制一个新的主服务器。

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

Redis复制的启动过程

本章前面曾经说过，从服务器在链接一个主服务器的时候，主服务器会建立一个快照文件并将其发送至从服务器，但这只是主从复制执行过程的其中一步。表4-2完整地列出了当从服务器链接主服务器时，主从服务器执行的全部操做。

经过使用表4-2所示的办法，Redis在复制进行期间也会尽量地处理接收到的命令请求，可是，若是主从服务器之间的网络带宽不足，或者主服务器没有足够的内存来建立子进程和建立记录写命令的缓冲区，那么Redis处理命令请求的效率就会受到影响。所以，尽管这并非必须的，但在实际中最好仍是让主服务器只使用50%～65%的内存，留下30%～45%的内存用于执行BGSAVE命令和建立记录写命令的缓冲区。

设置从服务器的步骤很是简单，用户既能够经过配置选项SLAVEOFhostport来将一个Redis服务器设置为从服务器，又能够经过向运行中的Redis服务器发送SLAVEOF命令来将其设置为从服务器。若是用户使用的是SLAVEOF配置选项，那么Redis在启动时首先会载入当前可用的任何快照文件或者AOF文件，而后链接主服务器并执行表4-2所示的复制过程。若是用户使用的是SLAVEOF命令，那么Redis会当即尝试链接主服务器，并在链接成功以后，开始表4-2所示的复制过程。

从服务器在进行同步时，会清空本身的全部数据。由于有些用户在第一次使用从服务器时会忘记这件事，因此这里要特别提醒一下：从服务器在与主服务器进行初始链接时，数据库中原有的全部数据都将丢失，并被替换成主服务器发来的数据。

警告：Redis不支持主主复制（master-masterreplication）由于Redis容许用户在服务器启动以后使用SLAVEOF命令来设置从服务器选项（slavingoptions），因此可能会有读者误觉得能够经过将两个Redis实例互相设置为对方的主服务器来实现多主复制（multi-masterreplication）（甚至可能会在一个循环里面将多个实例互相设置为主服务器）。遗憾的是，这种作法是行不通的：被互相设置为主服务器的两个Redis实例只会持续地占用大量处理器资源而且接二连三地尝试与对方进行通讯，根据客户端链接的服务器的不一样，客户端的请求可能会获得不一致的数据，或者彻底得不到数据。

当多个从服务器尝试链接同一个主服务器的时候，就会出现表4-3所示的两种状况中的其中一种。

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

主从链

有些用户发现，建立多个从服务器可能会形成网络不可用——当复制须要经过互联网进行或者须要在不一样数据中心之间进行时，尤其如此。由于Redis的主服务器和从服务器并无特别不一样的地方，因此从服务器也能够拥有本身的从服务器，并由此造成主从链（master/slavechaining）。

从服务器对从服务器进行复制在操做上和从服务器对主服务器进行复制的惟一区别在于，若是从服务器X拥有从服务器Y，那么当从服务器X在执行表4-2中的步骤4时，它将断开与从服务器Y的链接，致使从服务器Y须要从新链接并从新同步（resync）。

当读请求的重要性明显高于写请求的重要性，而且读请求的数量远远超出一台Redis服务器能够处理的范围时，用户就须要添加新的从服务器来处理读请求。随着负载不断上升，主服务器可能会没法快速地更新全部从服务器，或者由于从新链接和从新同步从服务器而致使系统超载。为了缓解这个问题，用户能够建立一个由Redis主从节点（master/slavenode）组成的中间层来分担主服务器的复制工做，如图4-1所示。

 

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

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

参考资料

黄健宏：<Redis实战>