组成双机热备的方案主要的三种方式分别为：基于共享存储（磁盘阵列）的方式，全冗余方式和复制方式。
基于共享存储（磁盘阵列）的方式
共享存储方式主要通过磁盘阵列提供切换后，对数据完整性和连续性的保障。用户数据一般会放在磁盘阵列上，当主机宕机后，备机继续从磁盘阵列上取得原有数据。
如下图所示这种方式因为使用一台存储设备，往往被业内人士称为磁盘单点故障。但一般来讲存储的安全性较高。所以如果忽略存储设备故障的情况下，这种方式也是业内采用最多的热备方式。
全冗余方式
全冗余方式就是双机双存储，基于单台存储的传统双机热备方式，确实存在存储单点故障的情况，为实现存储冗余，存储高可用也已经越来越多的被用户接受。我们从理解上可以看出，双机热备最早是为解决服务器的计划性停机与非计划性宕机的解决方案，但是我们无法实现存储的计划性停机与非计划性宕机带来的服务器停机，而存储作为双机热备中唯一存储数据的设备，它一旦发生故障往往会造成双机热备系统全面崩溃。
随着科技的进步，云存储，云计算发展，对于存储热备已经进入了成熟及快速发展阶段，双机热备也随着技术的进步，进入到了没有单点故障的全冗余双机热备方式。如图：
这种方式的特点在于：
1、存储之间的数据复制不经过网络，而是由存储之间进行复制。
2、两个存储之间的复制是完全实时的，不存在任何时间延时。
3、主备存储之间的切换时间小于500ms，以确保系统存储时不产生延时。
4、硬盘盘符及分区不因为主备存储之间的切换而改变。
5、服务器的切换，不影响存储之间的初始化，增量同步及数据复制。
6、某一存储设备的计划性停机，不影响整个服务器双机热备系统的工作。
7、存储设备之间使用重复数据删除技术，完成增量同步工作。
8、真正的7X24小时或切换的全冗余方案。
复制方式
这种方式主要利用数据的同步方式，保证主备服务器的数据一致性。
基于数据复制的方式有多种方法，其性能和安全也不尽相同，其主要方法有以下几种：
A、单纯的文件方式的拷贝不适用于数据库等应用，因为打开的文件是不能被复制的，如果要复制必须将数据库关闭，这显然是不可以的。以文件方式的复制主要适用于WEB页的更新，FTP上传应用，对主备机数据完整性，连续性要求不高的情况下使用。
B、利用数据库所带有复制功能，比如SQLServer2000或2005所带的定阅复制，这种方式用户要根据自己的应用小心使用，原因主要是：
（1）SQLServer的定阅复制会在用户表上增加字段，对那些应用软件编程要求较高，如果在应用软件端书写时未明确指定字段的用户，而使用此功能会造成应用程序无法正常工作。
（2）数据滞留，这个限制怕也是最要命的，因为SQLServer在数据传输过程中数据并非实时的到达主备机，而是数据先写到主机，再写到备机，如此一来，备机的数据往往来不及更新，此时如果发生切换，备机的数据将不完整，也不连续，如果用户发现已写入的数据在备机找不到，重新写入的话，则主机修复后，就会发生主备机数据严重冲突，数据库会乱掉。
（3）复杂应用切莫使用定阅复制来做双机热备，包括数据结构中存储过程的处理，触发器和序列，一旦发生冲突，修改起来非常麻烦。
（4）服务器性能降低，对于大一点的数据库，SQLServer2000或2005所带的定阅复制会造成服务器数据库运行缓慢。
总之SQLServer2000或2005所带的定阅复制主要还是应用于数据快照服务，切莫用他来做双机热备中的数据同步。
C：硬盘数据拦截，目前国际国内，比较成熟的双机热备软件通常会使用硬盘数据拦截的技术，通常称为镜像软件即Mirror软件，这种技术当前已非常成熟，拦截的方式也不尽相同。
（1）分区拦截技术，以Pluswell热备份产品为例，他采用的是一种分区硬盘扇区拦截的技术，通过驱动级的拦截方式，将数据写往硬盘的数据提取，并首先写到备用服务器，以保证备用服务器的数据最新，然后再将数据回写到主机硬盘。这种方式将绝对保证，主备机数据库的数据完全一致，无论发生哪种切换，都能保证数据库的完整性与连续性。由于采用分区拦截技术，所以用户可以根据需要在一块硬盘上划分适合大小的分区来完成数据同步工作。
（2）硬盘拦截技术，以Symantec的Co-Standby为例，也是一种有效的硬盘拦截软件，他的拦截主要基于一整块硬盘，往往在硬盘初始化时需要消耗大量的时间。
双机热备中需要指出的几个概念
1、可以使用如图所示的工具进行热备份。
2、也可以从如图位置获取。
3、获取后安装并认证。
4、完成后设置备份规则，即可开始热备份。
注意事项：
磁盘镜像是一种在其中写往物理驱动器的信息也被写入第二个物理驱动器的一种方法,也称为热备份它不同于硬盘之间的定时拷贝,作镜像是由智能控制器和一些软件自动地进行的。
是FTP。
FTP（File Transfer Protocol，文件传输协议） 是 TCP/IP 协议组中的协议之一。FTP协议包括两个组成部分，其一为FTP服务器，其二为FTP客户端。
其中FTP服务器用来存储文件，用户可以使用FTP客户端通过FTP协议访问位于FTP服务器上的资源。
同大多数Internet服务一样，FTP也是一个客户/服务器系统。用户通过一个客户机程序连接至在远程计算机上运行的服务器程序。
依照 FTP 协议提供服务，进行文件传送的计算机就是 FTP服务器，而连接FTP服务器，遵循FTP协议与服务器传送文件的电脑就是FTP客户端。
用户要连上FTP 服务器，就要用到 FTP 的客户端软件，通常 Windows自带“ftp”命令，这是一个命令行的 FTP客户程序，另外常用的 FTP 客户程序还有FileZilla、 CuteFTP、Ws_FTP、Flashfxp、LeapFTP、流星雨-猫眼等。
扩展资料：
在FTP的使用当中，用户经常遇到两个概念："下载"（Download）和"上载"（Upload）。"下载"文件就是从远程主机拷贝文件至自己的计算机上；
"上载"文件就是将文件从自己的计算机中拷贝至远程主机上。用Internet语言来说，用户可通过客户机程序向（从）远程主机上载（下载）文件。
作为一个Internet用户，可通过FTP在任何两台Internet主机之间拷贝文件。但是，实际上大多数人只有一个Internet帐户，FTP主要用于下载公共文件，例如共享软件、各公司技术支持文件等。
Internet上有成千上万台匿名FTP主机，这些主机上存放着数不清的文件，供用户免费拷贝。实际上，几乎所有类型的信息，所有类型的计算机程序都可以在Internet上找到。这是Internet吸引我们的重要原因之一。
匿名FTP使用户有机会存取到世界上最大的信息库，这个信息库是日积月累起来的，并且还在不断增长，永不关闭，涉及到几乎所有主题。而且，这一切是免费的。
匿名FTP是Internet网上发布软件的常用方法。Internet之所以能延续到今天，是因为人们使用通过标准协议提供标准服务的程序。像这样的程序，有许多就是通过匿名FTP发布的，任何人都可以存取它们。
参考资料来源：百度百科——FTP协议
FTP的工作原理是在 OSI 模型的第七层， TCP 模型的第四层， 即应用层， 使用TCP传输而不是 UDP， 客户在和服务器建立连接前要经过一个“三次握手”的过程， 保证客户与服务器之间的连接是可靠的。
在开发网站的时候，通常利用FTP协议把网页或程序传到Web服务器上。此外，由于FTP传输效率非常高，在网络上传输大的文件时，一般也采用该协议。
默认情况下FTP协议使用TCP端口中的 20和21这两个端口，其中20用于传输数据，21用于传输控制信息。
但是，是否使用20作为传输数据的端口与FTP使用的传输模式有关，如果采用主动模式，那么数据传输端口就是20；如果采用被动模式，则具体最终使用哪个端口要服务器端和客户端协商决定。
扩展资料
FTP 客户端首先和FTP服务器的TCP 21端口建立连接，通过这个通道发送命令，客户端需要接收数据的时候在这个通道上发送PORT命令。 PORT命令包含了客户端用什么端口接收数据。
在传送数据的时候，服务器端通过自己的TCP 20端口连接至客户端的指定端口发送数据。 FTP server必须和客户端建立一个新的连接用来传送数据。
在建立控制通道的时候和Standard模式类似，但建立连接后发送的不是Port命令，而是Pasv命令。FTP服务器收到Pasv命令后，随机打开一个高端端口（端口号大于1024）并且通知客户端在这个端口上传送数据的请求，客户端连接FTP服务器此端口。
很多防火墙在设置的时候都是不允许接受外部发起的连接的，所以许多位于防火墙后或内网的FTP服务器不支持PASV模式，因为客户端无法穿过防火墙打开FTP服务器的高端端口。
而许多内网的客户端不能用PORT模式登陆FTP服务器，因为从服务器的TCP 20无法和内部网络的客户端建立一个新的连接，造成无法工作。
参考资料来源：百度百科-ftp
FTP不是软件，而是一种协议。
文件传输协议（英文：File Transfer Protocol，缩写：FTP）是用于在网络上进行文件传输的一套标准协议，使用客户/服务器模式。
它属于网络传输协议的应用层。文件传送（file transfer）和文件访问（file access）之间的区别在于：前者由FTP提供，后者由如NFS等应用系统提供。
作用：FTP是一个8位的客户端-服务器协议，能 *** 作任何类型的文件而不需要进一步处理，就像MIME或Unicode一样。但是，FTP有着极高的延时，这意味着，从开始请求到第一次接收需求数据之间的时间，会非常长；并且不时的必须执行一些冗长的登录进程。
扩展资料：
传输方式：
1、ASCII传输方式
假定用户正在拷贝的文件包含的简单ASCII码文本，如果在远程机器上运行的不是UNIX，当文件传输时ftp通常会自动地调整文件的内容以便于把文件解释成另外那台计算机存储文本文件的格式。
但是常常有这样的情况，用户正在传输的文件包含的不是文本文件，它们可能是程序，数据库，字处理文件或者压缩文件。在拷贝任何非文本文件之前，用binary 命令告诉ftp逐字拷贝。
2、二进制传输模式
在二进制传输中，保存文件的位序，以便原始和拷贝的是逐位一一对应的。即使目的地机器上包含位序列的文件是没意义的。
例如，macintosh以二进制方式传送可执行文件到Windows系统，在对方系统上，此文件不能执行。如在ASCII方式下传输二进制文件，即使不需要也仍会转译。
这会损坏数据。（ASCII方式一般假设每一字符的第一有效位无意义，因为ASCII字符组合不使用它。如果传输二进制文件，所有的位都是重要的。）
参考资料来源：百度百科--ftp （文件传输协议）
FTP是File Transfer Protocol（文件传输协议）的缩写，用来在两台计算机之间互相传送文件。相比于>
在被动方式FTP中，命令连接和数据连接都由客户端，这样就可以解决从服务器到客户端的数据端口的入方向连接被防火墙过滤掉的问题。
当开启一个FTP连接时，客户端打开两个任意的非特权本地端口。第一个端口连接服务器的21端口，但与主动方式的FTP不同，客户端不会提交PORT命令并允许服务器来回连它的数据端口，而是提交PASV命令。
扩展资料：
工作方式
FTP支持两种模式，一种方式叫做Standard (也就是 PORT方式，主动方式)，一种是 Passive(也就是PASV，被动方式)。 Standard模式 FTP的客户端发送 PORT 命令到FTP服务器。Passive模式FTP的客户端发送 PASV命令到 FTP Server。
下面介绍一下这两种方式的工作原理：
Port
FTP 客户端首先和FTP服务器的TCP 21端口建立连接，通过这个通道发送命令，客户端需要接收数据的时候在这个通道上发送PORT命令。 PORT命令包含了客户端用什么端口接收数据。在传送数据的时候，服务器端通过自己的TCP 20端口连接至客户端的指定端口发送数据。 FTP server必须和客户端建立一个新的连接用来传送数据。
Passive
在建立控制通道的时候和Standard模式类似，但建立连接后发送的不是Port命令，而是Pasv命令。FTP服务器收到Pasv命令后，随机打开一个高端端口（端口号大于1024）并且通知客户端在这个端口上传送数据的请求，客户端连接FTP服务器此端口，通过三次握手建立通道，然后FTP服务器将通过这个端口进行数据的传送。
redis主从复制总结整理
主题 Redis
Redis的主从复制策略是通过其持久化的rdb文件来实现的，其过程是先dump出rdb文件，将rdb文件全量传输给slave，然后再将dump后的 *** 作实时同步到slave中。让从服务器(slave server)成为主服务器(master server)的精确复制品。官方文档ReplicationHowto中提到以下特点：
一个master支持多个slave，slave可以接受其他slave的连接，作为其他slave的master，从而形成一个master-slave的多级结构
复制功能不会阻塞主服务器： 即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。复制功能不会阻塞从服务器： 只要在 redisconf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。不过， 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内， 连接请求会被阻塞。
复制被利用来提供可扩展性，比如可以将slave端用作数据冗余，也可以将耗时的命令（比如sort）发往某些slave从而避免master的阻塞，另外也可以用slave做持久化，由从服务器去执行持久化 *** 作，这只需要将master的配置文件中的save指令注释掉。
Redis 使用异步复制。 从 Redis 28 开始， 从服务器会以每秒一次的频率向主服务器报告复制流的处理进度。
复制功能的实现
redis的主从复制分为两个阶段：
1）同步 *** 作：将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
2）命令传播：在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器重新回到一致状态。
同步
当客户端向从服务器发送 SLAVEOF 命令， 要求从服务器复制主服务器时， 从服务器首先需要执行同步 *** 作， 也即是， 将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
从服务器对主服务器的同步 *** 作需要通过向主服务器发送 SYNC 命令来完成， 以下是 SYNC 命令的执行步骤：
从服务器向主服务器发送 SYNC 命令。
收到 SYNC 命令的主服务器执行 BGSAVE 命令， 在后台生成一个 RDB 文件， 并使用一个缓冲区记录从现在开始执行的所有写命令。
当主服务器的 BGSAVE 命令执行完毕时， 主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器， 从服务器接收并载入这个 RDB 文件， 将自己的数据库状态更新至主服务器执行 BGSAVE 命令时的数据库状态。
主服务器将记录在缓冲区里面的所有写命令发送给从服务器， 从服务器执行这些写命令， 将自己的数据库状态更新至主服务器数据库当前所处的状态。
下图展示了 SYNC 命令执行期间， 主从服务器的通信过程：
命令传播
在同步 *** 作执行完毕之后， 主从服务器两者的数据库达到一致状态， 但这种一致并不是一成不变的。当主服务器执行客户端发送的写命令时，主服务器的数据库就有可能会被修改， 并导致主从服务器状态不再一致。为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播 *** 作： 主服务器会将自己执行的写命令 —— 即造成主从服务器不一致的那条写命令发送给从服务器执行， 当从服务器执行了相同的写命令之后， 主从服务器将再次回到一致状态。但是这样的复制功能有缺陷：在主从服务器断线重连之后执行同步动作时，生成完整的RDB文件并且发送到从服务器载入，但主从服务器的数据库状态在断线前基本上是一致的，不一致的部分只有断线后主服务器执行那一部分修改数据库的命令，所以这时SYNC命令就非常浪费，因为生成RDB文件时一个非常消耗CPU、内存和IO资源的过程，发送RDB文件到从服务器会占用大量的网络带宽资源，从服务器在载入RDB文件的过程中会阻塞不会响应任何命令，所以大部分情况下执行SYNC命令是没有必要也是非常不合理的。
为了解决28之前版本SYNC命令的性能问题，28版本设计了一个新的命令PSYNC，PSYNC命令分为 完整重同步 和 部分重同步 ，完整重同步过程用于从服务器初始化时初次复制的情况和SYNC命令基本一致，PSYNC则用于断线后重新复制，在条件允许的情况下，它不会生成RDB文件，而是给从服务器回复一个+Continue表示执行部分重同步，并且把从服务器断线后主服务器执行的修改数据库的命令发送到从服务器，从服务器执行这些命令同步数据库。
部分重同步功能由下面几个部分构成：
主服务器的复制偏移量 和 从服务器的复制偏移量 ：当主服务器在向从服务器进行命令同步时，主服务器和从服务器会各自记录一个复制偏移量，当主从服务器的数据库状态一致时这两个复制偏移量是相同的，如果这两个偏移量不一致说明当前主从服务器的状态不一致。
主服务器的复制积压缓冲区 ：复制积压缓冲区是一个固定大小的FIFO队列，当队列已满时会d出最早插入的数据，在主服务器进行命令传播时会同时把命令放到缓冲区中，缓冲区包含两部分数据，偏移量和字节。在进行复制时从服务器会将偏移量上报到主服务器，主服务检查当前偏移量是否还存在缓冲区中，如果存在进行部分重同步，如果不存在进行完整重同步。因为这个积压缓冲区是一个固定大小的队列，所以当从服务器长时间断线时，从服务器的复制偏移量很可能已不再缓冲区中，这时候只能进行完整重同步。
服务器的运行ID ：初次同步时主服务器会把ID发给从服务器，从服务器保存主服务器ID，当断线重连后，会把之前保存的主服务器ID上报给主服务器，主服务器检查从服务器之前复制的主服务器ID是否和自己的ID相同，如果相同，执行部分重同步，如果不同说明从服务器之前记录的状态不是当前主服务器，这时候需要执行完整重同步。
PSYNC命令实现
初始复制或者之前执行过SLAVEOF no one命令，执行完整重同步：发送PSYNC -1命令到主服务器。如果从服务器已经复制过某个主服务器，在开始新复制时向主服务器发送PSYNC <runid> <offset>命令，runid是上次复制的主服务器id，offset是从服务器的复制偏移量，主服务器会根据这个两个参数来决定做哪种同步，判断服务器id是否和本机相同，复制偏移量是否在缓冲区中，主服务器有三种回复：
回复+FULLRESYNC <runid> <offset>执行完整重同步，从服务器把offset当做初始复制偏移量
回复+CONTINUE，表示执行部分重同步，从服务器等待主服务器发送缺少的数据
回复-ERR，表示主服务器版本低于28，不支持PSYNC命令
新版本复制过程：
设置主服务器地址和端口，通过调用SAVEOF <master_ip> <master_port>命令。
建立套接字连接。
发送PING命令，检查主从服务器是否能够正常处理命令。
身份验证，从服务器设置了masterauth并且主服务器设置了requirepass是需要进行身份验证。这两个选项要么都设置要么都不设置，如果只设置了一个从服务器向主服务器发送命令时会报错。
发送端口信息，通过执行命令REPLCONF listening-port <port-number>，向主服务器发送从服务器的监听端口号。
同步，从服务器向主服务器发送PSYNC命令。
命令传播，完成同步之后主服务器会把之后执行的写命令传播到从服务器保证主从服务器的状态一致。
心跳检测
在命令传播阶段，从服务器默认每秒一次的频率向主服务器发送命令：REPLCONF ACK <replication_offset>，replication_offset是从服务器的复制偏移量，该命令有三个作用：
检测从服务器的网络连接状态，检测主从服务器连接是否正常，如果主服务器超过一定时间没有收到从服务器的REPLCONF ACK 命令，那么它们的连接可能出了问题。
辅助实现min-slaves选项，min-slaves-to-write和min-slaves-max-lag两个选项可以防止主服务器在不安全的情况下执行写命令，min-slaves-to-write 3 min-slaves-max-lag 10 表示如果从服务器少于3个，或者3个从服务器的延迟都大于10秒时，主服务器拒绝写命令。
检测命令丢失，主服务器接收到从服务器的REPLCONF ACK 命令之后会检查从服务器的偏移量是否和主服务器的一致，如果不一致会把积压缓冲区中的从服务器偏移量后面的命令发送到从服务器。
关闭主服务器持久化时，复制功能的数据安全
当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。 否则的话，由于延迟等问题，部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性，参考一下以下会导致主从服务器数据全部丢失的例子：
假设节点A为主服务器，并且关闭了持久化。 并且节点B和节点C从节点A复制数据
节点A崩溃，然后由自动拉起服务重启了节点A 由于节点A的持久化被关闭了，所以重启之后没有任何数据
节点B和节点C将从节点A复制数据，但是A的数据是空的， 于是就把自身保存的数据副本删除。
在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。 因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。
只读从服务器
从 Redis 26 开始， 从服务器支持只读模式， 并且该模式为从服务器的默认模式。
只读模式由 redisconf 文件中的 slave-read-only 选项控制， 也可以通过 CONFIG SET 命令来开启或关闭这个模式。
只读从服务器会拒绝执行任何写命令， 所以不会出现因为 *** 作失误而将数据不小心写入到了从服务器的情况。
即使从服务器是只读的， DEBUG 和 CONFIG 等管理式命令仍然是可以使用的， 还是不应该将服务器暴露给互联网或者任何不可信网络。 不过， 使用 redisconf 中的命令改名选项， 可以通过禁止执行某些命令来提升只读从服务器的安全性。
一些不重要的临时数据， 仍然是可以保存在从服务器上面的。 比如说， 客户端可以在从服务器上保存主服务器的可达性信息， 从而实现故障转移策略。所以仍然要让一个从服务器变得可写。
从服务器相关配置
如果主服务器通过 requirepass 选项设置了密码， 那么为了让从服务器的同步 *** 作可以顺利进行， 我们也必须为从服务器进行相应的身份验证设置。
对于一个正在运行的服务器， 可以使用客户端输入以下命令：
config set masterauth <password>
要永久地设置这个密码， 那么可以将它加入到配置文件中：
masterauth <password>
详细的信息可以参考 Redis 源码中附带的redisconf 示例文件。
主服务器只在有至少 N 个从服务器的情况下，才执行写 *** 作
从 Redis 28 开始， 为了保证数据的安全性， 可以通过配置， 让主服务器只在有至少 N 个当前已连接从服务器的情况下， 才执行写命令。不过， 因为 Redis 使用异步复制， 所以主服务器发送的写数据并不一定会被从服务器接收到， 因此， 数据丢失的可能性仍然是存在的。以下是这个特性的运作原理：
从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ， 以及执行写 *** 作所需的至少从服务器数量 min-slaves-to-write 。
如果至少有 min-slaves-to-write 个从服务器， 并且这些服务器的延迟值都少于 min-slaves-max-lag 秒， 那么主服务器就会执行客户端请求的写 *** 作。你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本： 尽管不能保证写 *** 作的持久性， 但起码丢失数据的窗口会被严格限制在指定的秒数中。
如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件， 那么写 *** 作就不会被执行， 主服务器会向请求执行写 *** 作的客户端返回一个错误。
以下是这个特性的两个选项和它们所需的参数：
min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>
详细的信息可以参考 Redis 源码中附带的 redisconf 示例文件。
Redis可扩展集群搭建
1 主动复制避开Redis复制缺陷。
既然Redis的复制功能有缺陷，不妨放弃Redis本身提供的复制功能，我们可以采用主动复制的方式来搭建我们的集群环境。所谓 主动复制 是指由业务端或者通过代理中间件对Redis存储的数据进行双写或多写，通过数据的多份存储来达到与复制相同的目的，主动复制不仅限于 用在Redis集群上，目前很多公司采用主动复制的技术来解决MySQL主从之间复制的延迟问题，比如Twitter还专门开发了用于复制和分区的中间件gizzard( >
主动复制虽然解决了被动复制的延迟问题，但也带来了新的问题，就是数据的一致性问题，数据写2次或多次，如何保证多份数据的一致性呢？如果你的应用 对数据一致性要求不高，允许最终一致性的话，那么通常简单的解决方案是可以通过时间戳或者vector clock等方式，让客户端同时取到多份数据并进行校验，如果你的应用对数据一致性要求非常高，那么就需要引入一些复杂的一致性算法比如Paxos来保证 数据的一致性，但是写入性能也会相应下降很多。
通过主动复制，数据多份存储我们也就不再担心Redis单点故障的问题了，如果一组Redis集群挂掉，我们可以让业务快速切换到另一组Redis上，降低业务风险。
2 通过presharding进行Redis在线扩容。
通过主动复制我们解决了Redis单点故障问题，那么还有一个重要的问题需要解决：容量规划与在线扩容问题。我们前面分析过Redis的适用场景是全部数据存储在内存中，而内存容量有限，那么首先需要根据业务数据量进行初步的容量规划，比如你的业务数据需 要100G存储空间，假设服务器内存是48G，至少需要3~4台服务器来存储。这个实际是对现有 业务情况所做的一个容量规划，假如业务增长很快，很快就会发现当前的容量已经不够了，Redis里面存储的数据很快就会超过物理内存大小，如何进行 Redis的在线扩容呢？Redis的作者提出了一种叫做presharding的方案来解决动态扩容和数据分区的问题，实际就是在同一台机器上部署多个Redis实例的方式，当容量不够时将多个实例拆分到不同的机器上，这样实际就达到了扩容的效果。
拆分过程如下：
在新机器上启动好对应端口的Redis实例。
配置新端口为待迁移端口的从库。
待复制完成，与主库完成同步后，切换所有客户端配置到新的从库的端口。
配置从库为新的主库。
移除老的端口实例。
重复上述过程迁移好所有的端口到指定服务器上。
以上拆分流程是Redis作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。
新浪微博的replication改进思路：
首先写Redis的AOF文件，并对这个AOF文件按文件大小进行自动分割滚动，同时关闭Redis的Rewrite命令，然后会在业务低峰时间进行内存快照存储，并把当前的AOF文件位置一起写入到快照文件中，这样我们可以使快照文件与AOF文件的位置保持一致性，这样我们得到了系统某一时刻的内存快照，并且同时也能知道这一时刻对应的AOF文件的位置，那么当从库发送同步命令时，我们首先会把快照文件发送给从库，然后从库会取出该快照文件中存储的AOF文件位置，并将该位置发给主库，主库会随后发送该位置之后的所有命令，以后的复制就都是这个位置之后的增量信息了。
Redis的复制由于会使用快照持久化方式，所以如果Redis持久化方式选择的是日志追加方式(aof),那么系统有可能在同一时刻既做aof日志文件的同步刷写磁盘，又做快照写磁盘 *** 作，这个时候Redis的响应能力会受到影响。所以如果选用aof持久化，则加从库需要更加谨慎。
总结
Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
尽量避免在压力较大的主库上增加从库
为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3……，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立即启用Slave1做Master，其他不变。
参考资料：
《redis设计与实现》
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）