CN104270271A - 一种互联网应用中的容灾备份系统及方法 - Google Patents

Abstract

本申请提供了一种互联网应用中的容灾备份系统及方法，以解决大规模互联网应用中的数据访问的问题。所述的容灾备份系统是一个整套的容灾解决方案，对互联网应用系统做到了分级的容灾备份，从数据库、缓存、业务访问各个级别分别进行主备实时同步，保证数据库有问题立刻切换备机使用，有一份缓存数据失效的时候，可以从备份缓存文件加载数据，一台业务逻辑服务器访问失败，可以从备机访问。这种整套的容灾备份系统，不是针对单个点来做容灾，因此对于大规模应用的访问数据情况可以做到更好地适应，最大限定地保证用户的服务可用，从而保证大型互联网数据访问的安全和访问成功率。

Description

一种互联网应用中的容灾备份系统及方法

技术领域

本申请涉及数据安全技术，特别是涉及一种互联网应用中的容灾备份系统及方法。

背景技术

在大规模的互联网应用，如大型的即时通讯、电子商务网站等应用中，很多业务的处理都需要服务器集群来操作。服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。

但是，长期运行的服务器，由于服务器运行比较久，出现宕机或者出问题的情况会越来越普遍。而且，运行久了之后硬件会有损坏，系统也有可能出现不稳定的情况。系统运行的不稳定不仅造成数据丢失，还无法及时为用户提供应用服务，造成用户的等待。

为了解决上述问题，需要提出一种容灾解决方案，以更好地适应大规模互联网应用中的数据访问。

发明内容

本申请提供了一种互联网应用中的容灾备份系统及方法，以解决大规模互联网应用中的数据访问的问题。

为了解决上述问题，本申请公开了一种互联网应用中的容灾备份系统，包括：

业务逻辑服务器、数据库服务器和缓存服务器，其中，所述业务逻辑服务器通过部署在每个应用服务器上的代理模块与应用服务器交互，并通过部署在每个数据库服务器上的代理模块与数据库服务器交互；

所述业务逻辑服务器包含两组，其中一组包含多个主业务逻辑服务器，另一组包含一个或多个备用业务逻辑服务器；

所述数据库服务器和缓存服务器也分别包含主、备两种；

所述部署在每个应用服务器上的代理模块包含以下子模块：

请求路由子模块，用于将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器；还用于当其中任意一台主业务逻辑服务器访问失败时，从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器并将访问请求进行路由；

所述业务逻辑服务器包含以下子模块：

数据库访问子模块，用于接收访问请求，并根据该访问请求，通过部署在每个数据库服务器上的代理模块访问主、备中的一台数据库服务器；

缓存访问子模块，用于接收访问请求，并根据该访问请求，访问主、备中的一台缓存服务器。

优选的，所述数据库服务器包含两组，其中一组包含多个主数据库服务器，另一组包含一个或多个备用数据库服务器；所述缓存服务器包含双层，其中第一层包含多个主缓存服务器，第二层包含一个或多个备用缓存服务器。

优选的，所述业务逻辑服务器的数据库访问子模块用于接收访问请求，并根据该访问请求，通过部署在每个数据库服务器上的代理模块访问其中一台主数据库服务器；还用于当其中任意一台主数据库服务器访问失败时，从所述两组数据库服务器中选择一台主或备用数据库服务器进行访问；所述业务逻辑服务器的缓存访问子模块用于接收访问请求，并根据该访问请求，访问其中一台主缓存服务器；还用于当其中任意一台主缓存服务器访问失败时，从所述双层缓存服务器中选择一台主或备用缓存服务器进行访问。

优选的，所述数据库服务器采用读写分离，其中主数据库服务器用于读操作和写操作，备用数据库服务器仅用于读操作；针对读操作的访问请求，当其中任意一台主数据库服务器访问失败时，所述业务逻辑服务器的数据库访问子模块从所述两组数据库服务器中选择一台备用数据库服务器进行访问。

优选的，所述部署在每个应用服务器上的代理模块还包括：选择子模块，用于通过一致性哈希从多个主业务逻辑服务器中选择一台主业务逻辑服务器，还用于通过一致性哈希从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器。

优选的，所述业务逻辑服务器还包括：选择子模块，用于通过一致性哈希从多个主数据库服务器中选择一台主数据库服务器，或者，通过一致性哈希从多个主缓存服务器中选择一台主缓存服务器；还用于通过一致性哈希从两组数据库服务器中选择一台主或备用数据库服务器，或者，通过一致性哈希从双层缓存服务器中选择一台主或备用缓存服务器。

本申请还提供了一种互联网应用中的容灾备份方法，用于互联网应用系统中：

所述互联网应用系统包括应用服务器、业务逻辑服务器、数据库服务器和缓存服务器；其中，所述业务逻辑服务器包含两组，其中一组包含多个主业务逻辑服务器，另一组包含一个或多个备用业务逻辑服务器；所述数据库服务器和缓存服务器也分别包含主、备两种；

所述方法包括：

将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器；

当其中任意一台主业务逻辑服务器访问失败时，从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器并将访问请求进行路由；

所述业务逻辑服务器接收访问请求，并根据该访问请求，访问主、备中的一台数据库服务器，或者，访问主、备中的一台缓存服务器。

优选的，所述数据库服务器包含两组，其中一组包含多个主数据库服务器，另一组包含一个或多个备用数据库服务器；所述业务逻辑服务器访问主、备中的一台数据库服务器包括：所述业务逻辑服务器访问其中一台主数据库服务器，当其中任意一台主数据库服务器访问失败时，从所述两组数据库服务器中选择一台主或备用数据库服务器进行访问。

优选的，所述缓存服务器包含双层，其中第一层包含多个主缓存服务器，第二层包含一个或多个备用缓存服务器；所述业务逻辑服务器访问主、备中的一台缓存服务器包括：所述业务逻辑服务器访问其中一台主缓存服务器，当其中任意一台主缓存服务器访问失败时，从所述双层缓存服务器中选择一台主或备用缓存服务器进行访问。

优选的，所述数据库服务器采用读写分离，其中主数据库服务器用于读操作和写操作，备用数据库服务器仅用于读操作；针对读操作的访问请求，当其中任意一台主数据库服务器访问失败时，所述业务逻辑服务器从所述两组数据库服务器中选择一台备用数据库服务器进行访问。

优选的，将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器之前，还包括：通过一致性哈希从多个主业务逻辑服务器中选择一台主业务逻辑服务器；当其中任意一台主业务逻辑服务器访问失败时，还包括：通过一致性哈希从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器。

与现有技术相比，本申请包括以下优点：

第一，本申请所述的容灾备份系统是一个整套的容灾解决方案，对互联网应用系统做到了分级的容灾备份，从数据库、缓存、业务访问各个级别分别进行主备实时同步，保证数据库有问题立刻切换备机使用，有一份缓存数据失效的时候，可以从备份缓存文件加载数据，一台业务逻辑服务器访问失败，可以从备机访问。这种整套的容灾备份系统，不是针对单个点来做容灾，因此对于大规模应用的访问数据情况可以做到更好地适应，最大限定地保证用户的服务可用，从而保证大型互联网数据访问的安全和访问成功率。

第二，所有级别的主备服务器都为分组，其中备机可以与传统方案不同，备机分组可以不是一台机器，而是一组机器，使得备机的能力更强，主机宕机后，服务压力可集中到备份分组的多台机器上，分担压力。

第三，对于业务访问级，尽量把业务逻辑服务器做成无状态的，即每台业务逻辑服务器提供一样的服务，这样可以更好地动态扩容，并且更好地做到服务不受硬件故障的影响。

第四，通过代理机制，一方面，后端业务做到对前端尽量透明，使得数据访问不会因为后端的扩容受到影响；另一方面，数据同步、备份等都是通过代理内部实现，全部为内网访问，因此没有多余的网络开销。

第五，对于数据库级别，主备读写分离，主库可以读写，备库只能用来读数据，这样的好处是可以更好地利用数据的读能力。例如，针对读操作的访问请求，当其中任意一个主库访问失败时，将读操作全部切换到备库进行，减轻其他主库的读写负担，也减少了对用户的影响。

第六，所有级别的主备分组内采用一致性哈希来路由请求，最大限度地使得数据失效减少。

当然，实施本申请的任一产品不一定需要同时达到以上所述的所有优点。

附图说明

图1是本申请实施例所述一种互联网应用中的容灾备份系统的部署架构图；

图2是本申请另一实施例所述一种互联网应用中的容灾备份系统的部署架构图；

图3是本申请实施例所述一种互联网应用中的容灾备份方法流程图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

容灾备份技术是通过特定的容灾机制，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因异常停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作，最大限度地保障提供正常应用服务。

从其对应用系统的保护程度来分，容灾系统分为数据容灾和应用容灾。

数据容灾，是指建立另一个数据系统，该系统是关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时，至少在另一个系统中保存有一份可用的关键业务的数据。该数据可以是与本地生产数据的完全实时复制，也可以比本地数据略微落后，但一定是可用的。采用的主要技术是数据备份和数据复制技术。

应用容灾，是在数据容灾的基础上，建立另一套完整的与关键应用系统相当的备份应用系统(可以是互为备份)。建立这样一个系统是相对比较复杂的，不仅需要一份可用的数据复制，还要有包括网络、主机、应用、甚至IP等资源，以及各资源之间的良好协调。主要的技术包括负载均衡、集群技术。

数据容灾需要保证用户数据的完整性、可靠性和一致性。而对于提供实时服务的信息系统，用户的服务请求在灾难中可能会中断，应用容灾却能提供不间断的应用服务，让用户的服务请求能够继续运行，保证容灾系统提供的服务完整、可靠、一致。

数据容灾是容灾系统的基础，也是容灾系统能够正常工作的保障；应用容灾则是容灾系统的建设目标，它必须建立在可靠的数据备份的基础之上，通过应用系统、网络系统等各种资源之间的良好协调来实现。

本申请从数据容灾和应用容灾两个方面构建了一套完整的容灾备份系统，一方面可以保证数据安全，另一方面可以进行访问容错，保证访问的成功率。所述容灾备份系统尤其适用于大规模应用的数据访问。

下面通过实施例对本申请所述系统进行详细说明。

参照图1，是本申请实施例所述一种互联网应用中的容灾备份系统的部署架构图。

所述容灾备份系统主要包括业务逻辑服务器10、数据库服务器20和缓存服务器30，以及部署在每个应用服务器上的代理模块40，部署在每个数据库服务器20上的代理模块50。其中，应用服务器可以提供各种互联网服务，如提供web服务的web服务器，提供即时通讯服务的IM服务器，提供电子商务的服务器，等等。

每个应用服务器上部署一个代理模块40，每个数据库服务器20上也部署一个代理模块50。所述业务逻辑服务器10可通过部署在每个应用服务器上的代理模块40与应用服务器交互，并可通过部署在每个数据库服务器20上的代理模块50与数据库服务器20交互。所述业务逻辑服务器10还可以与缓存服务器30交互。

这种代理机制可使后端业务做到对前端尽量透明，使得数据访问不会因为后端的扩容受到影响；而且，数据同步、备份等都是通过代理内部实现，全部为内网访问，因此没有多余的网络开销。

此外，所述业务逻辑服务器10将业务处理与数据访问相分离，即业务逻辑服务器10仅处理业务逻辑，数据访问通过数据库服务器20或缓存服务器30实现。这样的好处是可以避免业务处理与数据访问相互干扰。

所述容灾备份系统采用分级的容灾备份机制，从数据库、缓存、业务访问各个级别分别进行主备实时同步，保证数据库有问题立刻切换备机使用，有一份缓存数据失效的时候，可以从备份缓存文件加载数据，一台业务逻辑服务器访问失败，可以从备机访问。这种分级机制通过以下方式实现：

1)对于业务访问级，所述业务逻辑服务器10包含两组，其中一组包含多个主业务逻辑服务器，另一组包含一个或多个备用业务逻辑服务器；

2)对于数据库级，所述数据库服务器20也包含主、备两种；进一步地，所述数据库服务器20也可包含两组，其中一组包含多个主数据库服务器，另一组包含一个或多个备用数据库服务器；

3)对于缓存级，所述缓存服务器30也包含主、备两种；进一步地，所述缓存服务器30也可包含双层，其中第一层包含多个主缓存服务器，第二层包含一个或多个备用缓存服务器。

各级的主备分组都采用主备同步、实时备份，保证主备的一致性。

需要说明的是，上述所有级别的主备分组中，其中备机可以与传统方案不同，备机分组可以不是一台机器，而是一组机器，使得备机的能力更强，主机宕机后，服务压力可集中到备份分组的多台机器上，分担压力。图1示出的所有级别的备机都是多台，但也可以是一台。

此外，对于业务访问级，尽量把业务逻辑服务器做成无状态的，即每台业务逻辑服务器提供一样的服务，这样可以更好地动态扩容，并且更好地做到服务不受硬件故障的影响。

进一步地，所述部署在每个应用服务器上的代理模块40可以包含以下子模块：

请求路由子模块，用于将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器；还用于当其中任意一台主业务逻辑服务器访问失败时，从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器并将访问请求进行路由。

由上可知，由于主备分组都包含多台机器，因此所述代理模块40采用的路由策略是：在主备都可用的情况下，先从主机分组中选择一台主业务逻辑服务器，如果任意一台主机出现问题，则从剩余的所有主备分组中选择一台业务逻辑服务器，所选的可能是主业务逻辑服务器，也可能是备用业务逻辑服务器。

所述业务逻辑服务器10具体可以包含以下子模块：

数据库访问子模块，用于接收访问请求，并根据该访问请求，通过部署在每个数据库服务器20上的代理模块50访问主、备中的一台数据库服务器；

缓存访问子模块，用于接收访问请求，并根据该访问请求，访问主、备中的一台缓存服务器。

具体地，所述业务逻辑服务器10接收到访问请求后，根据该访问请求确定是访问数据库服务器20，还是访问缓存服务器30，访问结束后业务逻辑服务器10将访问结果返回。如果访问数据库服务器20，则调用所述数据库访问子模块在主备都可用的情况下，通过部署在每个数据库服务器20上的代理模块50访问其中一台主数据库服务器。当其中任意一台主数据库服务器访问失败时，从所述两组数据库服务器中选择一台主或备用数据库服务器进行访问，此时所选的可能是主数据库服务器，也可能是备用数据库服务器。

同样的，如果访问缓存服务器30，则调用所述缓存访问子模块访问其中一台主缓存服务器。当其中任意一台主缓存服务器访问失败时，从所述双层缓存服务器中选择一台主或备用缓存服务器进行访问，此时所选的可能是主缓存服务器，也可能是备用缓存服务器。

优选地，为了最大限度地使得数据失效减少，所有级别的主备分组内均可采用一致性哈希来路由请求。一致性哈希算法最早提出的设计目标是为了解决因特网中的热点(Hot spot)问题。一致性哈希提出了在动态变化的Cache(高速缓冲存储器)环境中，哈希算法应该满足的4个适应条件：

(1)平衡性(Balance)

平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。

(2)单调性(Monotonicity)

单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲区加入到系统中，那么哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲区中去，而不会被映射到旧的缓冲集合中的其他缓冲区。

(3)分散性(Spread)

在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。

(4)负载(Load)

负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

总之，一致性哈希算法背后最基础的思想就是：对object(对象)和cachemachine使用相同的hash函数。这样做的好处是能够把cache机器映射到一段interval上，而这段interval就会包含一定数目的对象的hash值。如果某台cache机器被移除了，那么它映射到的interval被和它相邻的一个cache机器托管，其他所有的cache机器都不用变。

基于以上的一致性哈希，所述部署在每个应用服务器上的代理模块40还可以包括以下子模块：

选择子模块，用于通过一致性哈希从多个主业务逻辑服务器中选择一台主业务逻辑服务器，还用于通过一致性哈希从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器。

所述业务逻辑服务器10也可以还包括以下子模块：

选择子模块，用于通过一致性哈希从多个主数据库服务器中选择一台主数据库服务器，或者，通过一致性哈希从多个主缓存服务器中选择一台主缓存服务器；还用于通过一致性哈希从两组数据库服务器中选择一台主或备用数据库服务器，或者，通过一致性哈希从双层缓存服务器中选择一台主或备用缓存服务器。

优选地，对于数据库级别，所述数据库服务器20还可以采用读写分离，其中主数据库服务器用于读操作和写操作，备用数据库服务器仅用于读操作，这样的好处是可以更好地利用数据的读能力。例如，针对读操作的访问请求，当其中任意一台主数据库服务器访问失败时，所述业务逻辑服务器的数据库访问子模块可以从所述两组数据库服务器中选择一台备用数据库服务器进行访问，即将读操作全部切换到备库进行，减轻其他主库的读写负担，也减少了对用户的影响。

此外，所述容灾备份系统还包含以下特点：

1)动态配置：主要体现在代理这样的配置需要更新的地方，以及各个需要逻辑更新的地方。全部的配置的动态更新都通过协议的形式，这样直接一条访问过来，就可以动态加载修改后的配置自动生效，不对业务造成影响。

2)动态扩容：数据库服务器的动态扩容，主要利用分库分表机制+主备实时同步机制。所述分库分表机制是指每个数据库对应一张表，将扩容数据库的表实时备份到备机，然后前段业务切换，数据库重新分配备机。

3)业务访问的动态扩容：业务逻辑服务器全部构造为无状态形式，这样部署后，可以动态加载配置文件。

综上所述，这种整套的容灾备份系统，同时结合了数据容灾和应用容灾，并且分级容灾，而不是针对单个点来做容灾，因此对于大规模应用的访问数据情况可以做到更好地适应，最大限定地保证用户的服务可用，从而保证大型互联网数据访问的安全和访问成功率。

下面通过图2给出另一实施例所示的容灾备份系统。

参照图2，是本申请另一实施例所述一种互联网应用中的容灾备份系统的部署架构图。

所述互联网应用部署了应用层、中间层服务、DB(数据库)服务和分布式Cache服务。其中，应用层部署了web服务器(web server)和IM服务器(IM server)两种应用服务器。

中间层部署了多个中间层进程，每个中间层进程可对应一台业务逻辑服务器。中间层进程可分为主(master)、备(slave)两组，每组都可包含多个进程，图中仅示出了一个备用的中间层进程，但备用的中间层进程也可以包含多个。其中，无论主备，每个中间层进程都提供无状态的中间服务，即每个中间层进行都是一样的。

DB服务也部署了多个数据库，每个数据库可对应一台数据库服务器，也可分为主(master)、备(slave)两组。同样，图中仅示出了一个备用的数据库，但备用的数据库也可以包含多个。

分布式Cache服务采用双层Cache，每一层都包含多个Cache池进程，每个Cache池进程可对应一台缓存服务器。而且，两层可采用不同的hash方式。

此外，每个应用服务器上部署各自的代理模块(agent)，每个数据库上也部署各自的代理模块(DBagent)。中间层进程通过部署在各应用服务器上的代理与应用层通信，并通过部署在各数据库上的代理与DB服务通信。其中，中间层对应用层是透明的。

对于上述图2所示的系统实施例而言，由于其与图1实施例基本相似，所以描述的比较简单，相关之处参见图1所示实施例的部分说明即可。

基于以上各实施例所述的容灾备份系统，本申请还提供了一种容灾备份方法的实施例，如图3所示。

参照图3，是本申请实施例所述一种互联网应用中的容灾备份方法流程图。

所述容灾备份方法主要用于互联网应用系统中，所述互联网应用系统包括应用服务器、业务逻辑服务器、数据库服务器和缓存服务器；其中，所述业务逻辑服务器包含两组，其中一组包含多个主业务逻辑服务器，另一组包含多个备用业务逻辑服务器；所述数据库服务器和缓存服务器也分别包含主、备两种。

所述方法包含以下步骤：

步骤301，将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器；

步骤302，当其中任意一台主业务逻辑服务器访问失败时，从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器并将访问请求进行路由；

步骤303，所述业务逻辑服务器接收访问请求，并根据该访问请求，访问主、备中的一台数据库服务器，或者，访问主、备中的一台缓存服务器；

步骤304，将访问结果返回。

优选地，所述数据库服务器也可以包含两组，其中一组包含多个主数据库服务器，另一组包含多个备用数据库服务器。相应的，所述业务逻辑服务器访问主、备中的一台数据库服务器的步骤具体可包括：

所述业务逻辑服务器访问其中一台主数据库服务器，当其中任意一台主数据库服务器访问失败时，从所述两组数据库服务器中选择一台主或备用数据库服务器进行访问。

优选地，所述缓存服务器也可包含双层，其中第一层包含多个主缓存服务器，第二层包含多个备用缓存服务器。相应的，所述业务逻辑服务器访问主、备中的一台缓存服务器的步骤具体包括：

所述业务逻辑服务器访问其中一台主缓存服务器，当其中任意一台主缓存服务器访问失败时，从所述双层缓存服务器中选择一台主或备用缓存服务器进行访问。

优选地，所述数据库服务器可采用读写分离，其中主数据库服务器用于读操作和写操作，备用数据库服务器仅用于读操作；针对读操作的访问请求，当其中任意一台主数据库服务器访问失败时，所述业务逻辑服务器从所述两组数据库服务器中选择一台备用数据库服务器进行访问。

优选地，将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器之前，还包括以下步骤：通过一致性哈希从多个主业务逻辑服务器中选择一台主业务逻辑服务器；

当其中任意一台主业务逻辑服务器访问失败时，还包括以下步骤：通过一致性哈希从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器。

需要说明的是，对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请所必需的。

对于上述容灾备份方法实施例而言，由于其与系统实施例基本相似，所以描述的比较简单，相关之处参见图1、图2所示系统实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

综上所述，本申请实施例提供的互联网应用中的容灾备份系统及方法，包含以下优点：

第一，本申请所述的容灾备份系统是一个整套的容灾解决方案，对互联网应用系统做到了分级的容灾备份，从数据库、缓存、业务访问各个级别分别进行主备实时同步，保证数据库有问题立刻切换备机使用，有一份缓存数据失效的时候，可以从备份缓存文件加载数据，一台业务逻辑服务器访问失败，可以从备机访问。这种整套的容灾备份系统，不是针对单个点来做容灾，因此对于大规模应用的访问数据情况可以做到更好地适应，最大限定地保证用户的服务可用，从而保证大型互联网数据访问的安全和访问成功率。

第二，所有级别的主备服务器都为分组，其中备机可以与传统方案不同，备机分组可以不是一台机器，而是一组机器，使得备机的能力更强，主机宕机后，服务压力可集中到备份分组的多台机器上，分担压力。

第三，对于业务访问级，尽量把业务逻辑服务器做成无状态的，即每台业务逻辑服务器提供一样的服务，这样可以更好地动态扩容，并且更好地做到服务不受硬件故障的影响。

第四，通过代理机制，一方面，后端业务做到对前端尽量透明，使得数据访问不会因为后端的扩容受到影响；另一方面，数据同步、备份等都是通过代理内部实现，全部为内网访问，因此没有多余的网络开销。

第五，对于数据库级别，主备读写分离，主库可以读写，备库只能用来读数据，这样的好处是可以更好地利用数据的读能力。例如，针对读操作的访问请求，当其中任意一个主库访问失败时，将读操作全部切换到备库进行，减轻其他主库的读写负担，也减少了对用户的影响。

第六，所有级别的主备分组内采用一致性哈希来路由请求，最大限度地使得数据失效减少。

以上对本申请所提供的一种互联网应用中的容灾备份系统及方法，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (11)

1.一种互联网应用中的容灾备份系统，其特征在于，包括：

业务逻辑服务器、数据库服务器和缓存服务器，其中，所述业务逻辑服务器通过部署在每个应用服务器上的代理模块与应用服务器交互，并通过部署在每个数据库服务器上的代理模块与数据库服务器交互；

所述业务逻辑服务器包含两组，其中一组包含多个主业务逻辑服务器，另一组包含一个或多个备用业务逻辑服务器；

所述数据库服务器和缓存服务器也分别包含主、备两种；

所述部署在每个应用服务器上的代理模块包含以下子模块：

请求路由子模块，用于将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器；还用于当其中任意一台主业务逻辑服务器访问失败时，从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器并将访问请求进行路由；

所述业务逻辑服务器包含以下子模块：

数据库访问子模块，用于接收访问请求，并根据该访问请求，通过部署在每个数据库服务器上的代理模块访问主、备中的一台数据库服务器；

缓存访问子模块，用于接收访问请求，并根据该访问请求，访问主、备中的一台缓存服务器。

2.根据权利要求1所述的系统，其特征在于：

所述数据库服务器包含两组，其中一组包含多个主数据库服务器，另一组包含一个或多个备用数据库服务器；

所述缓存服务器包含双层，其中第一层包含多个主缓存服务器，第二层包含一个或多个备用缓存服务器。

3.根据权利要求2所述的系统，其特征在于：

所述业务逻辑服务器的数据库访问子模块用于接收访问请求，并根据该访问请求，通过部署在每个数据库服务器上的代理模块访问其中一台主数据库服务器；还用于当其中任意一台主数据库服务器访问失败时，从所述两组数据库服务器中选择一台主或备用数据库服务器进行访问；

所述业务逻辑服务器的缓存访问子模块用于接收访问请求，并根据该访问请求，访问其中一台主缓存服务器；还用于当其中任意一台主缓存服务器访问失败时，从所述双层缓存服务器中选择一台主或备用缓存服务器进行访问。

4.根据权利要求1或3所述的系统，其特征在于：

所述数据库服务器采用读写分离，其中主数据库服务器用于读操作和写操作，备用数据库服务器仅用于读操作；

针对读操作的访问请求，当其中任意一台主数据库服务器访问失败时，所述业务逻辑服务器的数据库访问子模块从所述两组数据库服务器中选择一台备用数据库服务器进行访问。

5.根据权利要求1所述的系统，其特征在于，所述部署在每个应用服务器上的代理模块还包括：

选择子模块，用于通过一致性哈希从多个主业务逻辑服务器中选择一台主业务逻辑服务器，还用于通过一致性哈希从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器。

6.根据权利要求3所述的系统，其特征在于，所述业务逻辑服务器还包括：

选择子模块，用于通过一致性哈希从多个主数据库服务器中选择一台主数据库服务器，或者，通过一致性哈希从多个主缓存服务器中选择一台主缓存服务器；还用于通过一致性哈希从两组数据库服务器中选择一台主或备用数据库服务器，或者，通过一致性哈希从双层缓存服务器中选择一台主或备用缓存服务器。

7.一种互联网应用中的容灾备份方法，用于互联网应用系统中，其特征在于：

所述互联网应用系统包括应用服务器、业务逻辑服务器、数据库服务器和缓存服务器；其中，所述业务逻辑服务器包含两组，其中一组包含多个主业务逻辑服务器，另一组包含一个或多个备用业务逻辑服务器；所述数据库服务器和缓存服务器也分别包含主、备两种；

所述方法包括：

将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器；

当其中任意一台主业务逻辑服务器访问失败时，从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器并将访问请求进行路由；

所述业务逻辑服务器接收访问请求，并根据该访问请求，访问主、备中的一台数据库服务器，或者，访问主、备中的一台缓存服务器。

8.根据权利要求7所述的方法，其特征在于：

所述数据库服务器包含两组，其中一组包含多个主数据库服务器，另一组包含一个或多个备用数据库服务器；

所述业务逻辑服务器访问主、备中的一台数据库服务器包括：

所述业务逻辑服务器访问其中一台主数据库服务器，当其中任意一台主数据库服务器访问失败时，从所述两组数据库服务器中选择一台主或备用数据库服务器进行访问。

9.根据权利要求7所述的方法，其特征在于：

所述缓存服务器包含双层，其中第一层包含多个主缓存服务器，第二层包含一个或多个备用缓存服务器；

所述业务逻辑服务器访问主、备中的一台缓存服务器包括：

所述业务逻辑服务器访问其中一台主缓存服务器，当其中任意一台主缓存服务器访问失败时，从所述双层缓存服务器中选择一台主或备用缓存服务器进行访问。

10.根据权利要求7或8所述的方法，其特征在于：

所述数据库服务器采用读写分离，其中主数据库服务器用于读操作和写操作，备用数据库服务器仅用于读操作；

针对读操作的访问请求，当其中任意一台主数据库服务器访问失败时，所述业务逻辑服务器从所述两组数据库服务器中选择一台备用数据库服务器进行访问。

11.根据权利要求7所述的方法，其特征在于：

将应用服务器产生的访问请求路由到其中一台主业务逻辑服务器之前，还包括：通过一致性哈希从多个主业务逻辑服务器中选择一台主业务逻辑服务器；

当其中任意一台主业务逻辑服务器访问失败时，还包括：通过一致性哈希从两组业务逻辑服务器中选择一台主或备用业务逻辑服务器。