CN104426968A - 数据管理方法和装置 - Google Patents

Abstract

本发明公开了一种数据管理方法和装置。其中，该方法包括：将接收到的第一主用数据存储至第一服务器上的第一主用数据库，其中，第一主用数据为第一服务器直接或间接连接的一个或多个客户端上执行的第一业务的相关数据；将接收到的第二备用数据存储至第一服务器上的第二备用数据库，其中，第二备用数据用于对第二主用数据进行备份，其中，第二主用数据为第二服务器直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。本发明解决了在传统主从式架构的数据管理系统中由于主用服务器的处理能力限制导致的在不增设服务器的前提下数据管理系统的业务容量较低的技术问题，达到了利用现有设备扩大数据管理系统的数据处理容量的技术效果。

Description

数据管理方法和装置

技术领域

本发明涉及通信领域，具体而言，涉及一种数据管理方法和装置。

背景技术

在互联网通信领域中，主从式架构是一种常见的网络架构。其中，在基于传统的主从式架构组建的网络系统中，通常存在一个主控节点，例如一个主用服务器，从而该网络系统中的客户端对于集群的操作通常经由该主控节点处理。

图1示出了一种现有的基于主从式架构的数据管理系统，其中，客户端102和104与主用服务器106连接，从而主用服务器106可以对客户端102和104发出的请求进行处理，例如，可以客户端发出的写操作请求作出响应，将客户端发出的数据写入主用服务器106上的主用数据库中。

如图1所示，该数据管理系统的服务器集群中通常还包括与作为主用服务器106的冗余设计的备用服务器108和110，从而在作为主控节点的主用服务器106出现故障时，可以将主用服务器106的主用数据库以及相关数据处理服务转为由备用服务器108或110提供。

然而，当主用服务器106对相关业务进行处理的压力增大，或者该数据管理系统需要对多项不同业务进行相关数据的处理时，由于主用服务器106的处理能力的限制，以及不同业务拆分的要求，通常需要增设另一组主备服务器，例如图2所示的基于主从式架构的数据管理系统，其中，由主用服务器106、备用服务器108和110组成的第一服务器组与客户端102和104连接，用于执行第一业务，由主用服务器206、备用服务器208和210组成的第二服务器组与客户端202和204连接，用于执行第二业务。

然而，上述扩容方式需要增设整套服务器组，增加了设备成本，而在维持现有硬件设备规模的情形下，由于主用服务器的处理能力的限制，难以达到扩容的要求。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种数据管理方法和装置，以至少解决在传统主从式架构的数据管理系统中由于主用服务器的处理能力限制导致的在不增设服务器的前提下数据管理系统的业务容量较低的技术问题。

根据本发明实施例的一个方面，提供了一种数据管理方法，包括：将接收到的第一主用数据存储至第一服务器上的第一主用数据库，其中，上述第一主用数据为上述第一服务器直接或间接连接的一个或多个客户端上执行的第一业务的相关数据；将接收到的第二备用数据存储至上述第一服务器上的第二备用数据库，其中，上述第二备用数据用于对第二主用数据进行备份，其中，上述第二主用数据为第二服务器直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

根据本发明实施例的另一方面，还提供了一种数据管理装置，包括：将接收到的第一主用数据存储至第一服务器上的第一主用数据库，其中，上述第一主用数据为上述第一服务器直接或间接连接的一个或多个客户端上执行的第一业务的相关数据；将接收到的第二备用数据存储至上述第一服务器上的第二备用数据库，其中，上述第二备用数据用于对第二主用数据进行备份，其中，上述第二主用数据为第二服务器直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

在本发明实施例中，利用同一服务器同时作为主用服务器和备用服务器工作的特点，从而降低了对服务器的数量要求以及总体的设备成本。在另一方面，利用上述特点，在本发明实施例中，采用本发明技术方案在一台或多台服务器上实施的方式，形成多台服务器互为主备的架构，从而在保留数据管理系统的主备切换功能的基础上，达到了将原有主用服务器处理的不同业务由多台服务器分担的目的，从而实现了在限制单一服务器的数据处理压力的基础上扩大数据管理系统处理的业务容量的技术效果，进而解决了在传统主从式架构的数据管理系统中由于主用服务器的处理能力限制导致的在不增设服务器的前提下数据管理系统的业务容量较低的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据现有技术的一种数据管理方法的示意图；

图2是根据现有技术的另一种数据管理方法的示意图；

图3是根据本发明实施例的一种可选的数据管理方法的示意图；

图4是本发明技术方案的一种可选的实施环境的示意图；

图5是本发明技术方案的另一种可选的实施环境的示意图；

图6是根据本发明实施例的另一种可选的数据管理方法的示意图；

图7是本发明技术方案的又一种可选的实施环境的示意图；

图8是根据本发明实施例的又一种可选的数据管理方法的示意图；

图9是本发明技术方案的又一种可选的实施环境的示意图；

图10是根据本发明实施例的又一种可选的数据管理方法的示意图；

图11是本发明技术方案的又一种可选的实施环境的示意图；

图12是根据本发明实施例的又一种可选的数据管理方法的示意图；

图13是根据本发明实施例的又一种可选的数据管理方法的示意图；

图14是本发明技术方案的又一种可选的实施环境的示意图；

图15是本发明技术方案的又一种可选的实施环境的示意图；

图16是根据本发明实施例的又一种可选的数据管理方法的示意图；

图17是根据本发明实施例的又一种可选的数据管理方法的示意图；

图18是根据本发明实施例的又一种可选的数据管理方法的示意图；

图19是根据本发明实施例的又一种可选的数据管理方法的示意图；

图20是根据本发明实施例的又一种可选的数据管理方法的示意图；

图21是根据本发明实施例的一种可选的数据管理装置的示意图；

图22是根据本发明实施例的另一种可选的数据管理装置的示意图；

图23是根据本发明实施例的又一种可选的数据管理装置的示意图；

图24是根据本发明实施例的又一种可选的数据管理装置的示意图；

图25是根据本发明实施例的又一种可选的数据管理装置的示意图；

图26是根据本发明实施例的又一种可选的数据管理装置的示意图；

图27是根据本发明实施例的又一种可选的数据管理装置的示意图；

图28是根据本发明实施例的又一种可选的数据管理装置的示意图；

图29是本发明技术方案的又一种可选的实施环境的示意图；

图30是本发明技术方案的又一种可选的实施环境的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种数据管理方法，如图3所示，该方法可以包括：

S302：将接收到的第一主用数据存储至第一服务器402上的第一主用数据库，其中，第一主用数据为第一服务器402直接或间接连接的一个或多个客户端上执行的第一业务的相关数据；

S304：将接收到的第二备用数据存储至第一服务器402上的第二备用数据库，其中，第二备用数据用于对第二主用数据进行备份，其中，第二主用数据为第二服务器502直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

应当明确的是，本发明所要解决的问题之一是提供一种基于主从式架构的更优的数据管理方案，因此，在本发明技术方案的实施环境中，如图4所示，可以至少包括：一个或多个客户端、用于对上述客户端的请求作出处理和回应的服务器、以及位于上述服务器上的作为实现集中对客户端的请求进行上述处理的基础的主用数据库，为便于表述，以下将该服务器记为第一服务器402，将第一服务器402上的主用数据库记为第一主用数据库。需要说明的是，除本发明实施例特别说明的外，不应理解为本发明对第一服务器402、第一主用数据库及其对应的客户端作出了任何不必要的限定。

进而根据本发明实施例提供的数据管理方法，在步骤S302中，可以将接收到的第一主用数据存储至第一服务器402上的第一主用数据库，其中，第一主用数据可以为第一服务器402直接或间接连接的一个或多个客户端上执行的第一业务的相关数据。

首先，本发明实施例中所称的第一主用数据库和第一业务在本发明实施例中的具体表现形式适用于前述解释，在此不作赘述。然而，对于本发明实施例中所称的第一主用数据，其可以仅用于表示上述主从式架构中的客户端上执行的第一业务的相关数据，并且，在本发明实施例中，可以在步骤S302中将该第一主用数据存储至上述第一主用数据库。除此之外，对于该第一主用数据的具体使用方式以及第一服务器402上的第一主用数据库的后续处理操作等，本发明均不作任何限定。

从以上描述可以看出，通过步骤S302所述的将接收到的第一主用数据存储至第一服务器402上的第一主用数据库的操作，可以将第一业务的相关数据记录到第一服务器402上的第一主用数据库中，从而第一服务器402可以在正常的工作状态下进一步执行与第一业务相关的处理操作，并实现类似于图2中所示的主用服务器106的功能。

一般而言，类似于传统的主从式架构，如图4所示，在本发明实施例中，同属于执行第一业务的客户端102和客户端104也可以与第一服务器402连接，以便将第一业务相关的第一主用数据发送到第一服务器402。具体地，上述的连接方式既可以为直接连接，也可以为间接连接，例如，在客户端与第一服务器402之间可以设置有网关等为本领域技术人员所知的网络设备，或者如本申请之后的实施例中所描述的特定的数据传输或处理设备，等，本发明对此不作限定。除此之外，在本发明实施例中，还可以将传统的主从式架构中其他可行的技术手段与本发明技术方案结合实施，且此类情形仍应视为在本发明的保护范围中。

在本发明实施例中，上述的第一业务的相关数据，也即第一主用数据可以包括多种不同形式的数据，例如，其可以表现为数字编码形式的数据流，也可以为封装形成的数据帧或数据包，具体地，可以根据第一主用数据的具体的接收方式而定。此外，第一主用数据也可以包括多种不同类型的数据，例如，其可以表现为第一业务所需的信息本身，也可以为第一业务所需的网络资源的路径信息，存储至第一主用数据库中，还可以为用于对第一主用数据库中的数据进行请求所需的索引信息，等。在另一方面，第一主用数据所包含的信息也可以有多种类型，例如，其可以包含用户的个人资料信息，也可以包含客户端即时反馈的用户的动作信息，等。当然，上述实施例仅作为示例提出，并不意味着对本发明作出了任何限定，例如，第一主用数据并不必须来自于客户端的写操作，其中，上述的用户的个人资料信息也可以来自于其他的服务器。

还需要说明的是，作为与第一主用数据库对应的、功能上类似于图2中所示的备用服务器108和110的第一备用数据库，可以如图4和图5所示的位于第一服务器402的外部，例如，类似于备用服务器108和110的服务器，也可以如图7、9、11、14和15所示的，位于本申请之后的实施例中所描述的特定的并非由传统的单一的主、备功能所限定的服务器上。

根据本发明实施例提供的数据管理方法，在步骤S304中，可以将接收到的第二备用数据存储至第一服务器402上的第二备用数据库，其中，第二备用数据可以用于对第二主用数据进行备份，其中，第二主用数据可以为第二服务器502直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

一般而言，类似于传统的主从式架构，如图4所示，在本发明实施例中，同属于执行第二业务的客户端202和客户端204也可以与第二服务器502连接，以便将第二业务相关的第二主用数据发送到第一服务器402。类似于第一服务器402与客户端102和104之间的连接关系，上述第二服务器502与与客户端202和204的连接方式也可以包括直接或间接连接的方式，本发明对此不作限定。

此外，第二备用数据库和第二业务在本发明实施例中的具体表现形式同样适用于本发明前述的解释，且上述第二主用数据可以仅用于表示第二业务的相关数据。进一步地，作为第二主用数据的备份，第二备份数据的内容可以与第二主用数据的内容一致。其中，对于第二主用数据的复制操作可以在第二服务器502上完成，然而本发明对此不作限定，例如，其还可以在存储有与第二主用数据对应的第二备用数据的其他服务器上完成，然后将根据第二备用数据复制的内容一致的数据作为相同的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，值得注意的是，用于执行第一业务的客户端和用于执行第二业务的客户端并不必须为不同的客户端，在本发明的一些实施例中，也可以存在同一客户端同时用于执行第一业务和第二业务的情形。但这并不妨碍本发明技术方案的实施及其描述，如上所述，第一主用数据和第二主用数据可以分别与第一业务和第二业务对应，也即，接收到的数据可以根据不同业务进行划分，并可以不限于客户端本身。

在上述场景下，进一步地，可以将接收到的第二业务的相关数据记录到第二服务器502上的第二主用数据库中，从而第二服务器502可以在正常的工作状态下进一步执行与第二业务相关的处理操作，并实现类似于图2中所示的主用服务器206的功能。

然而，区别于图2所示的现有技术，在步骤S304中，可以将接收到的第二备用数据存储至第一服务器402上的第二备用数据库，从而，如图5所示，在本发明实施例中，与第二主数据库对应的、功能上类似于图2中所示的备用服务器208和210的第二备用数据库可以位于第一服务器402上，从而免除了传统的具有主备功能的主从式架构中的备用服务器的需求，进而在保持现有的主备功能的基础上，可以达到降低对服务器的数量要求以及总体设备成本的技术效果。

在另一方面，本发明技术方案还可以在如图1所示的现有架构上实施，其中，至少可以将备用服务器108和110之一作为与第二业务对应的第二主用数据库的载体也即第二服务器502与执行第二业务的客户端连接，并将与第二主用数据库对应的第二备用数据库设置在主用服务器106上，从而，主用服务器106即可以视为上述第一服务器402，其上可以既存有与第一业务对应的第一主用数据库，又存有与第二业务对应的第二备用数据库。在上述场景下，整个服务器组同时处理的业务容量由第一业务增加为第一业务和第二业务，且作为第一服务器402的原主用服务器106面向客户端的写操作的处理压力仍然维持在处理第一业务的相关数据的标准上，而面向第二业务的相关数据的写操作的处理压力将由作为第二服务器502的原备用服务器108和110之一分担，从而可以达到在限制单一服务器的数据处理压力的基础上扩大写入数据处理容量的技术效果。

下面将通过下述实施例对本发明技术方案及其可选的实施方式进行更为详细的阐述。

可选地，如图6所示，在本发明实施例中，在步骤S302之后，还可以包括：

S602：将第一备用数据存储至目标服务器上的第一备用数据库，其中，第一备用数据用于对第一主用数据进行备份，目标服务器包括第三服务器和/或第二服务器502。

其中，目标服务器仅表示用于存储第一备用数据的第一备用数据库所在的服务器，除此之外并无特别限定。在步骤S602中，第一备用数据可以作为第一主用数据的备份存入上述目标服务器，二者在内容上保持一致，以达到针对第一业务的相关数据的主备功能设计要求。

在本发明的一些实施例中，如图5中用虚线示出的，第一备用数据库可以位于第一服务器402和第二服务器502外的第三服务器上。在上述场景下，该第三服务器可以视为起到与图1中所示的备用服务器106和108类似的作用。

在另一方面，如图7所示，在本发明的一些实施例中，第一备用数据库也可以位于上述第二主用数据库所在的第二服务器502。在上述场景下，如图8所示，第一服务器402和第二服务器502也可以视为对称地执行了以下步骤：

S302：将接收到的第一主用数据存储至第一服务器402上的第一主用数据库；

S602：将第一备用数据存储至第二服务器502上的第一备用数据库；

S304：将接收到的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，对于第二服务器502而言，上述步骤中的“第一”和“第二”可以互换。通过上述步骤，可以在第一服务器402和第二服务器502之间形成互为主备的数据存储结构，具体地，可以如图7所示，其中，存储有第一主用数据的第一主用数据库和存储有第二备用数据的第二备用数据库均位于第一服务器402，而存储有第一备用数据的第一备用数据库和存储有第二主用数据的第二主用数据库均位于第二服务器502。

如图7所示，在上述场景下，第一服务器402和第二服务器502可以分别连接执行第一业务和第二业务的客户端，并且在正常的工作状态下，第一服务器402和第二服务器502可以分别用于对第一业务和第二业务的相关数据，也即第一主用数据和第二主用数据进行存储，以及对第一业务和第二业务的分别处理，从而可以实现对于整体的写入压力的分担，并且可以克服现有技术中当用于对全部业务进行主控处理的主用服务器出现故障时，由于要将全部业务的相关数据切换为由备用服务器提供，所导致的错误数据可能出现在全部业务范围的问题，进而达到分散风险的目的。

一般而言，作为本发明更为优选的一种实施方式，还可以通过类似的手段将服务器规模扩大到两台以上的多台服务器形成的服务器组，并可以通过在这一环境下的本发明技术方案的实施，实现面向多项业务的更为高效的数据管理。

例如，图9示出了由三台服务器所组成的本发明技术方案的一种可选的应用环境，其中，如图10所示，三台服务器中的每一台可以对称地执行以下步骤：

S302：将接收到的第一主用数据存储至第一服务器402上的第一主用数据库；

S602：将第一备用数据存储至第三服务器902上的第一备用数据库；

S304：将接收到的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，对于第二服务器502而言，上述步骤中的“第一”可以替换为“第二”，“第二”可以替换为“第三”，“第三”可以替换为“第一”；对于第三服务器902而言，上述步骤中的“第一”可以替换为“第三”，“第二”可以替换为“第一”，“第三”可以替换为“第二”。

进一步地，在上述场景下，第一服务器402、第二服务器502和第三服务器902可以分别连接执行第一业务、第二业务和第三业务的客户端，并且在正常的工作状态下，第一至第三服务器902可以分别用于对第一至第三业务的相关数据，也即第一至第三主用数据进行存储，以及对第一至第三业务的分别处理，从而可以实现对于整体的写入压力的分担，并且可以克服现有技术中当用于对全部业务进行主控处理的主用服务器出现故障时，由于要将全部业务的相关数据切换为由备用服务器提供，所导致的错误数据可能出现在全部业务范围的问题，进而达到分散风险的目的。

在另一方面，如图11所示，在本发明的另一些实施例中，对于类似于图9中的由三台服务器组成的本发明技术方案的一种可选的应用环境，如图12所示，三台服务器中的每一台还可以对称地执行以下步骤：

S302：将接收到的第一主用数据存储至第一服务器402上的第一主用数据库；

S602：将第一备用数据存储至第二服务器502和第三服务器902上的第一备用数据库；

S304：将接收到的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，对于第二服务器502而言，上述步骤中的“第一”可以替换为“第二”，“第二”可以替换为“第三”，“第三”可以替换为“第一”；对于第三服务器902而言，上述步骤中的“第一”可以替换为“第三”，“第二”可以替换为“第一”，“第三”可以替换为“第二”。

在这一场景下，类似地，分别位于第一至第三服务器902上的第一至第三主用数据库可以分别用于存储第一至第三业务的相关数据，从而在第一至三服务器上实现对于第一至第三业务的分别处理，在此不作赘述。然而，与图9和图10示出的本发明技术方案的实施方式形成区别的是，在本发明实施例中，利用类似的硬件条件，可以在实现主备功能的基础上，在主用数据库所在的服务器外，为每一主用数据库提供两个备用数据库，且上述两个备用数据库可以分别位于不同的服务器，从而可以避免主用数据库和备用数据库之一或者二者所在的服务器同时出现故障而造成的对应业务无法处理的问题，进而提高了整个数据管理系统的稳定性和可靠性。

通过上述实施例，对本发明技术方案作出了更为详细的阐述，当然，上述实施例作为示例提出，不应视为对本发明提出了任何不必要的限定。此外，应当理解，上述实施例中作为本发明技术方案在第二服务器502和/或第三服务器902上的类同的实施方式，仍应视为在本发明的保护范围之内。

在另一方面，特别值得注意的是，本发明对步骤S302和步骤S304的执行主体不作限定，其中，该主体可以为第一服务器402的本地数据管理，也可以为第一服务器402内部的其他进程，还可以为第一服务器402外部的处理设备，其中，该处理设备可以包括缓存或其他类型的存储器，从而可以先将接收的数据存放在存储器中，并在对上述接收的数据进行识别和筛选以后，再将其分配给用于处理不同业务的各服务器。

在上述场景下，如图13所示，作为一种可选的实施方式，在步骤S302和S304之前，上述数据管理方法可以包括：

S1302：在第一服务器402的内部或外部对接收到的数据进行筛选，并将接收数据中的第一主用数据分配给第一服务器402处理，将接收数据中的第二主用数据分配给第二服务器502处理。

如图14和图15所示，在本发明的一些实施例中，可以先将接收到的数据存储在缓存1402中，进而可以在步骤S1302中对上述接收到的数据进行筛选，并根据其所对应的业务将接收到的数据分配给各服务器处理。更具体地，图14和图15示出了两种可选的实施方式，其中，缓存1402可以如图14所示的，设置于第一服务器402的内部，也可以如图15所示的，设置于第一服务器402和第二服务器502的外部，当然，还可以有其他的可行的实施方式，例如，缓存1402还可以设置于第二服务器502上，或者同时设置于服务器组中的每一服务器上，从而可以在不改变原有的主从式架构的硬件基础上实施本发明的技术方案。当然，以上只是一些示例，本发明对此不作限定。

在上述场景下，如图16所示，步骤S1302可以进一步包括：

S1602：判断接收到的数据是否包含与第一业务对应的第一标识项或者与第二业务对应的第二标识项，其中，

若满足第一判断条件，则执行步骤S1604，

若满足第二判断条件，则执行步骤S1606，其中，

第一判断条件包括：接收到的数据包含与第一业务对应的第一标识项，

第二判断条件包括：接收到的数据包含与第二业务对应的第二标识项；

S1604：判断出接收到的数据为第一主用数据；

S1606：判断出接收到的数据为第二主用数据。

其中，第一标识项和第二标识项可以分别作为第一业务和第二业务的相关数据识别标识，设置在相关数据内，例如，可以在客户端对发送的数据进行封装时，根据客户端执行的业务，将第一标识项或第二标识项添加至数据包中，从而在对该数据包进行接收时，可以识别出其所对应的业务。

一般而言，上述的第一标识项和第二标识项可以设置为与业务唯一对应的代码，该代码可以由特定的字符串形成，然而本发明对此不作任何限定，例如，第一标识项和第二标识项也可以通过通信领域中可行的其他识别方式来实现，在此不作累述。

特别地，在本发明的一些实施例中，第一标识项和第二标识项可以分别设置为第一服务器402和第二服务器502的网络地址，从而对该第一标识项和第二标识项的识别以及数据的分送也可以在交换机或网关进行。当然，此类实施方式也可以视为在第一服务器402与执行第一业务的客户端、以及第二服务器502与执行第二业务的客户端之间建立了连接，从而形成类似于前述实施例中已经描述的场景。

进一步地，如图17所示，在步骤S1602之前，上述数据管理方法还可以包括：

S1702：将包括第一业务和第二业务在内的多个业务与包括第一标识项和第二标识项在内的多个标识项之间的对应关系存储至第一服务器402的内部或外部，其中，多个业务与多个标识项一一对应。

一般而言，在本发明实施例中，上述业务与标识项之间的对应关系可以通过映射表来体现，例如表1所示，对于由第一服务器402和第二服务器502形成的本发明技术方案的应用环境，该映射表可以包括以下两种数据：

1）业务ID，表示与业务对应的标识项；

2）Master IP，表示用于执行对应业务的主用数据库所在的服务器的地址。

表1

业务ID	Master IP
		S1	Master1
S2	Master2

其中，Master1可以用于表示第一服务器402的地址，Master2可以用于表示第二服务器502的地址，且第一服务器402和第二服务器502可以分别对应接收第一业务和第二业务的相关数据，从而在本发明实施例中，可以通过对业务ID的识别，判断出将接收到的数据发送至哪一个服务器。例如，当接收到的数据包含S1时，可以将其识别为第一业务，并发送至与第一业务对应的第一服务器402的地址Master1。

当然，应当理解，本发明通过上述实施例给出了基于第一和第二服务器502以及第一和第二业务的示例，然而这并不意味着对本发明形成了限制，例如，上述实施方式还可以扩展到多台服务器形成的服务器组的应用环境下，例如，可以在第一服务器402的内部存储如表2所示的规模更大的映射表，以便将接收到的数据发送至用于执行对应业务的服务器。

表2

业务ID	Master IP
		S1	Master1
S2	Master2
		S3	Master3
S4	Master4

当然，以上只是一种示例，上述多个业务与多个标识项之间的对应关系还可以通过为本领域技术人员所知的其他可行的方式建立，本发明在此不做累述。

下面将结合一个现实场景给出本发明的更为具体的实施例。如图29所示，这一场景展示了一个Hadoop分布式文件系统HDFS（Hadoop Distributed File System），其中，该系统可以至少包括：一个数据仓库服务器2902、一个名称节点服务器2904以及多个数据节点服务器2906、2908和2910。其中，数据仓库服务器2902可以表现为决策支持系统DSS（Decision Support System）和联机分析应用数据源的结构化数据环境，其上建立的数据仓库的通常可以用于为前端查询和分析提供查询和分析基础，名称节点服务器2904可以用于对平台中存储信息的元数据进行管理，以确保上述数据仓库中的数据完整性，其中，该元数据可以用于数据仓库和底层存储结构之间的解析，而数据节点服务器2906、2908和2910可以用于实际数据信息的存储，并直接与客户端程序进行交互以及数据传输。

一般而言，在上述场景下作出的主备冗余设计中，通常可以将数据节点服务器之一，例如数据节点服务器2906作为主用服务器，而将数据节点服务器2908和2910设置为备用服务器，从而客户端在对数据仓库中的数据进行访问时，可以将数据请求提交给数据仓库服务器2902，进而通过名称节点服务器2904找到实际存储该数据请求对应的数据记录的数据节点服务器2906，并从该数据节点服务器2906向该客户端返回该数据记录。

与此不同的是，如图30所示，在本发明实施例中，数据仓库服务器2902可以作为前述数据管理方法的执行主体，用于对从上述数据仓库中的所有数据记录中划分出的多个数据块，例如图29中所示的实际存储并冗余备份在数据节点服务器2906、2908和2910上的第一数据块、第二数据块和第三数据块进行管理，其中，第一数据块可以包括第一业务对应的相关数据记录，比如可以用于记录一款即时通讯产品的用户相关信息，第二数据块可以包括第二业务对应的相关数据记录，比如可以用于记录一款在线游戏产品的用户相关信息，第三数据块可以包括第三业务对应的相关数据记录，比如可以用于记录一款社交服务产品的用户相关信息，其中，特别地，上述三款产品可以共享同一用户管理平台，从而三款产品各自对应用户相关信息可以合并到一张大数据表中，在另一方面，也可以视为该大数据表被划分为第一数据块、第二数据块和第三数据块。

进一步地，在本发明实施例中，作为可以将数据节点服务器2906作为上述即时通讯产品对应的主用服务器以及上述在线游戏产品和社交服务产品的备用服务器，将数据节点服务器2908作为在线游戏产品对应的主用服务器以及即时通讯产品和社交服务产品的备用服务器，并将数据节点服务器2906作为社交服务产品对应的主用服务器以及即时通讯产品和在线游戏产品。其中，该存储结构可以反映在名称节点服务器2904中，从而客户端在对数据仓库中的数据进行访问时，可以将数据请求提交给数据仓库服务器2902，进而通过名称节点服务器2904找到实际存储该数据请求对应的数据记录的数据节点服务器，例如，请求在线游戏的用户相关信息的，可以访问数据节点服务器2908并返回对应的数据记录。

作为与这一架构对应的数据管理方式，在步骤S302中，可以通过数据仓库服务器2902将接收到的第一主用数据即上述即时通讯产品的用户相关信息录入第一数据块，并实际存储至第一服务器即数据节点服务器2906，并且在步骤S304中，将接收到的第二主用数据即上述在线游戏产品的用户相关信息并入第二数据块，并实际存储至该数据节点服务器2906，并进一步地在数据节点服务器2908和2910上执行类似的操作，从而实现上述的存储结构。进一步地，可以将上述实际存储信息记录到元数据中，以便名称节点服务器的管理。

在这一存储结构下，面向即时通讯产品、在线游戏产品和社交服务产品的三个不同业务的底层存储结构的数据读/写压力可以分摊到三个数据节点服务器上，然而对于上层的数据仓库而言，其查询和分析的对象仍然可以是上述用户管理平台的大数据表，从而达到了在分布式文件系统下实现主备架构、且降低单个数据节点服务器的数据处理压力的技术效果。

当然，以上只是一个具体应用示例，并不意味着对本发明构成了任何不必要的限定，例如，上述数据管理方法的执行主体也可以不为数据仓库服务器2902，而是名称节点服务器2904或者独立在数据仓库服务器2902外的一个客户端模块等。进而以上述具体实施例为例，其他符合本发明构思的等效方案或者明显变型，均应视为在本发明的保护范围之内。

通过本发明的以上实施例，给出了上述数据管理方法的多种具体实施方式。在此还需要说明的是，在根据本发明实施例的数据管理方法中，步骤S302和S304之间并无必须的先后顺序限定，其中，其可以如图3所示的，先执行步骤S302、然后再执行步骤S304，也可以反过来先执行步骤S304、再执行步骤S302，当然，在本发明的一些实施例中，还可以将步骤S302和S304分派为两个并行的任务，并在不为这两个任务设置任何时序关系的条件下分别执行，以上实施方式均不影响本发明技术效果的体现，本发明对此也不作任何限定。

下面将结合图18至图20对根据本发明实施例的数据管理方法中的主备切换进行描述。

在如图5或图7所示的实施环境中，可选地，如图18所示，在本发明实施例中，在步骤S302之后，上述数据管理方法还可以包括：

S1802：判断第一服务器402或第一主用数据库是否处于正常的工作状态，

若否，则执行步骤S1804；

S1804：将用于指示第一备用数据库由备用状态切换至主用状态的消息通知给目标服务器。

如前所述，目标服务器表示用于存储第一备用数据的第一备用数据库所在的服务器，且在前述步骤S602中，第一备用数据可以作为第一主用数据的备份存入上述目标服务器。

在上述场景下，可以在步骤S1802中判断第一服务器402或第一主用数据库是否处于正常的工作状态，其中，该正常的工作状态通常可以指第一服务器402的不报错的运行状态，或者第一主用数据库能够进行正常的读写操作的状态。与之相反，若第一服务器402在运行中出现错误报告，或者第一主用数据库无法进行正常的读写操作。当然，以上只是一种示例，本发明对此不作限定，例如，也可以将在第一主用数据库中检测到错误的数据记录作为第一主用数据库未处于正常的工作状态的判断标准，等。

一般而言，考虑到数据批量处理中可能出现的个例错误，可以为第一服务器402或第一主用数据库未处于正常的工作状态设定一个时间阈值，其中，若非正常状态持续时间超过该时间阈值，则判断出未处于正常的工作状态，从而执行步骤S1804，以通知第一备用数据库所在的目标服务器由备用状态切换至主用状态。

进一步地，在目标服务器包括多个服务器的场景下，例如图11所示的应用环境，可以通过竞争机制，选举出最终执行备用到主用的切换的目标服务器。其具体实现方式在现有技术中存在多种选择，本发明在此不作累述。

在另一方面，可选地，如图19所示，在本发明实施例中，步骤S1804可以进一步包括：

S1902：将用于询问第一备用数据库是否准备完成的消息通知给目标服务器；

S1904：判断在预定的时间内是否从目标服务器中的一个或多个接收到用于指示第一备用数据库准备完成的消息，

若是，则执行步骤S1906；

S1906：将用于指示第一备用数据库由备用状态切换至主用状态的消息通知给目标服务器中的一个或多个。

其中，在步骤S1902中，在通知目标服务器进行备用到主用的切换之前，可以先向目标服务器发送该目标服务器上的第一备用数据库是否准备完成的询问信息，进而可以在步骤S1904中对该目标服务器是否作出回应进行判断，其中，若在预定的时间内接收到用于指示第一备用数据库准备完成的消息，则可以判断出该目标服务器处于正常的备用状态，从而可以在步骤S1906中，将上述由备用到主用的切换指示信息通知给该目标服务器，反之，若未在预定的时间内从目标服务器接收到回应，或接收到的回应并非为预定的准备完成信息，则判断出目标服务器未处于正常的备用状态，从而可以将该目标服务器排除出第一主用数据库对应的备用列表，其中，该备用列表可以用于存放可用的第一备用数据库的位置信息，例如其所在的服务器地址。

在上述场景中，通过对目标服务器是否准备完成的确认，可以确保第一备用数据库由备用到主用的切换的可靠进行，从而提高了整个数据管理系统的稳定性。

在另一方面，在本发明实施例中，也可以由备用数据库所在的服务器向与之对应的主用数据库所在的服务器反馈该备用数据库是否准备完成的信息，例如，可选地，如图20所示，在步骤S304之后，上述数据管理方法还可以包括：

S2002：判断第一服务器402或第二备用数据库是否处于正常的工作状态，

若否，则执行步骤S2004；

S2004：将用于指示第二备用数据库未准备完成的消息通知给第二主用数据库所在的服务器，和/或，将第一服务器402的标识从备用列表中移除，其中，第二主用数据库记录有第二主用数据，备用列表中记录的标识所指示的服务器用于在第二主用数据库所在的服务器未处于正常的工作状态时，接收用于指示第二备用数据库由备用状态切换至主用状态的消息。

其中，可以在步骤S2002中对第一服务器402或位于第一服务器402上的第二备用数据库是否处于正常的工作状态，若未处于正常的工作状态，则在步骤S2004中，可以将用于指示第一服务器402或第二备用数据库未准备完成的信息通知给第二主用数据库所在的服务器。其中，在如图5或图7所示的应用环境中，与第二备用数据库对应的第二主用数据库可以位于第二服务器502上，从而，可以在判断出第一服务器402或第二备用数据库未处于正常的工作状态时，将该状态信息通知给第二服务器502，从而在第二服务器502或其上的第二主用数据库出现故障时，可以指示第一服务器402以外的存储有第二备用数据库的服务器进行备用到主用的切换，进而提高数据管理系统的可靠性。

当然，如上所述，也可以通过将第一服务器402的标识从备用列表中移除来实现在切换前对备用数据库的准备状态的确认。其中，上述备用列表可以存储在第一服务器402的内部或外部，或者服务器组以外的存储设备中，其中，该备用列表用于存放可用的备用数据库的位置信息，例如其所在的服务器地址，从而在主用数据库或其所在的服务器出现故障时，可以将用于指示主备切换的消息通知给备用列表中的服务器。

值得注意的是，在根据本发明实施例提供的数据管理方法中，上述步骤中的一个或多个可以在现有的可编辑的数据管理平台上，例如Zookeeper等，利用其内设的功能或模块，通过程序或命令行的编写等可选的方式来实现，应当理解，此类实现方式仍应视为在本发明的保护范围之内。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的数据管理方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述数据管理方法的数据管理装置，如图21所示，该装置包括：

1）第一处理单元2102，用于将接收到的第一主用数据存储至第一服务器402上的第一主用数据库，其中，第一主用数据为第一服务器402直接或间接连接的一个或多个客户端上执行的第一业务的相关数据；

2）第二处理单元2104，用于将接收到的第二备用数据存储至第一服务器402上的第二备用数据库，其中，第二备用数据用于对第二主用数据进行备份，其中，第二主用数据为第二服务器502直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

应当明确的是，本发明所要解决的问题之一是提供一种基于主从式架构的更优的数据管理方案，因此，在本发明技术方案的实施环境中，如图4所示，可以至少包括：一个或多个客户端、用于对上述客户端的请求作出处理和回应的服务器、以及位于上述服务器上的作为实现集中对客户端的请求进行上述处理的基础的主用数据库，为便于表述，以下将该服务器记为第一服务器402，将第一服务器402上的主用数据库记为第一主用数据库。需要说明的是，除本发明实施例特别说明的外，不应理解为本发明对第一服务器402、第一主用数据库及其对应的客户端作出了任何不必要的限定。

进而根据本发明实施例提供的数据管理装置，在第一处理单元2102中，可以将接收到的第一主用数据存储至第一服务器402上的第一主用数据库，其中，第一主用数据可以为第一服务器402直接或间接连接的一个或多个客户端上执行的第一业务的相关数据。

首先，本发明实施例中所称的第一主用数据库和第一业务在本发明实施例中的具体表现形式适用于前述解释，在此不作赘述。然而，对于本发明实施例中所称的第一主用数据，其可以仅用于表示上述主从式架构中的客户端上执行的第一业务的相关数据，并且，在本发明实施例中，可以在第一处理单元2102中将该第一主用数据存储至上述第一主用数据库。除此之外，对于该第一主用数据的具体使用方式以及第一服务器402上的第一主用数据库的后续处理操作等，本发明均不作任何限定。

从以上描述可以看出，通过第一处理单元2102中所述的将接收到的第一主用数据存储至第一服务器402上的第一主用数据库的操作，可以将第一业务的相关数据记录到第一服务器402上的第一主用数据库中，从而第一服务器402可以在正常的工作状态下进一步执行与第一业务相关的处理操作，并实现类似于图2中所示的主用服务器106的功能。

一般而言，类似于传统的主从式架构，如图4所示，在本发明实施例中，同属于执行第一业务的客户端102和客户端104也可以与第一服务器402连接，以便将第一业务相关的第一主用数据发送到第一服务器402。具体地，上述的连接方式既可以为直接连接，也可以为间接连接，例如，在客户端与第一服务器402之间可以设置有网关等为本领域技术人员所知的网络设备，或者如本申请之后的实施例中所描述的特定的数据传输或处理设备，等，本发明对此不作限定。除此之外，在本发明实施例中，还可以将传统的主从式架构中其他可行的技术手段与本发明技术方案结合实施，且此类情形仍应视为在本发明的保护范围中。

在本发明实施例中，上述的第一业务的相关数据，也即第一主用数据可以包括多种不同形式的数据，例如，其可以表现为数字编码形式的数据流，也可以为封装形成的数据帧或数据包，具体地，可以根据第一主用数据的具体的接收方式而定。此外，第一主用数据也可以包括多种不同类型的数据，例如，其可以表现为第一业务所需的信息本身，也可以为第一业务所需的网络资源的路径信息，存储至第一主用数据库中，还可以为用于对第一主用数据库中的数据进行请求所需的索引信息，等。在另一方面，第一主用数据所包含的信息也可以有多种类型，例如，其可以包含用户的个人资料信息，也可以包含客户端即时反馈的用户的动作信息，等。当然，上述实施例仅作为示例提出，并不意味着对本发明作出了任何限定，例如，第一主用数据并不必须来自于客户端的写操作，其中，上述的用户的个人资料信息也可以来自于其他的服务器。

还需要说明的是，作为与第一主用数据库对应的、功能上类似于图2中所示的备用服务器108和110的第一备用数据库，可以如图4和图5所示的位于第一服务器402的外部，例如，类似于备用服务器108和110的服务器，也可以如图7、9、11、14和15所示的，位于本申请之后的实施例中所描述的特定的并非由传统的单一的主、备功能所限定的服务器上。

根据本发明实施例提供的数据管理装置，在第二处理单元2104中，可以将接收到的第二备用数据存储至第一服务器402上的第二备用数据库，其中，第二备用数据可以用于对第二主用数据进行备份，其中，第二主用数据可以为第二服务器502直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

一般而言，类似于传统的主从式架构，如图4所示，在本发明实施例中，同属于执行第二业务的客户端202和客户端204也可以与第二服务器502连接，以便将第二业务相关的第二主用数据发送到第一服务器402。类似于第一服务器402与客户端102和104之间的连接关系，上述第二服务器502与与客户端202和204的连接方式也可以包括直接或间接连接的方式，本发明对此不作限定。

此外，第二备用数据库和第二业务在本发明实施例中的具体表现形式同样适用于本发明前述的解释，且上述第二主用数据可以仅用于表示第二业务的相关数据。进一步地，作为第二主用数据的备份，第二备份数据的内容可以与第二主用数据的内容一致。其中，对于第二主用数据的复制操作可以在第二服务器502上完成，然而本发明对此不作限定，例如，其还可以在存储有与第二主用数据对应的第二备用数据的其他服务器上完成，然后将根据第二备用数据复制的内容一致的数据作为相同的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，值得注意的是，用于执行第一业务的客户端和用于执行第二业务的客户端并不必须为不同的客户端，在本发明的一些实施例中，也可以存在同一客户端同时用于执行第一业务和第二业务的情形。但这并不妨碍本发明技术方案的实施及其描述，如上所述，第一主用数据和第二主用数据可以分别与第一业务和第二业务对应，也即，接收到的数据可以根据不同业务进行划分，并可以不限于客户端本身。

在上述场景下，进一步地，可以将接收到的第二业务的相关数据记录到第二服务器502上的第二主用数据库中，从而第二服务器502可以在正常的工作状态下进一步执行与第二业务相关的处理操作，并实现类似于图2中所示的主用服务器206的功能。

然而，区别于图2所示的现有技术，在第二处理单元2104中，可以将接收到的第二备用数据存储至第一服务器402上的第二备用数据库，从而，如图5所示，在本发明实施例中，与第二主数据库对应的、功能上类似于图2中所示的备用服务器208和210的第二备用数据库可以位于第一服务器402上，从而免除了传统的具有主备功能的主从式架构中的备用服务器的需求，进而在保持现有的主备功能的基础上，可以达到降低对服务器的数量要求以及总体设备成本的技术效果。

在另一方面，本发明技术方案还可以在如图1所示的现有架构上实施，其中，至少可以将备用服务器108和110之一作为与第二业务对应的第二主用数据库的载体也即第二服务器502与执行第二业务的客户端连接，并将与第二主用数据库对应的第二备用数据库设置在主用服务器106上，从而，主用服务器106即可以视为上述第一服务器402，其上可以既存有与第一业务对应的第一主用数据库，又存有与第二业务对应的第二备用数据库。在上述场景下，整个服务器组同时处理的业务容量由第一业务增加为第一业务和第二业务，且作为第一服务器402的原主用服务器106面向客户端的写操作的处理压力仍然维持在处理第一业务的相关数据的标准上，而面向第二业务的相关数据的写操作的处理压力将由作为第二服务器502的原备用服务器108和110之一分担，从而可以达到在限制单一服务器的数据处理压力的基础上扩大写入数据处理容量的技术效果。

下面将通过下述实施例对本发明技术方案及其可选的实施方式进行更为详细的阐述。

可选地，如图25所示，在本发明实施例中，与第一处理单元2102耦合地，上述数据管理装置还可以包括：

1）第五处理单元2502，用于将第一备用数据存储至目标服务器上的第一备用数据库，其中，第一备用数据用于对第一主用数据进行备份，目标服务器包括第三服务器和/或第二服务器502。

其中，目标服务器仅表示用于存储第一备用数据的第一备用数据库所在的服务器，除此之外并无特别限定。通过第五处理单元2502，第一备用数据可以作为第一主用数据的备份存入上述目标服务器，二者在内容上保持一致，以达到针对第一业务的相关数据的主备功能设计要求。

在本发明的一些实施例中，如图5中用虚线示出的，第一备用数据库可以位于第一服务器402和第二服务器502外的第三服务器上。在上述场景下，该第三服务器可以视为起到与图1中所示的备用服务器106和108类似的作用。作为本发明可选的实施方式之一，上述方式依然可以达到降低对服务器的数量要求以及总体设备成本的技术效果。

在另一方面，如图7所示，在本发明的一些实施例中，第一备用数据库也可以位于上述第二主用数据库所在的第二服务器502。在上述场景下，第一服务器402和第二服务器502也可以视为对称地加载了以下功能模块：

1）第一处理单元2102，用于将接收到的第一主用数据存储至第一服务器402上的第一主用数据库；

2）第五处理单元2502，用于将第一备用数据存储至第二服务器502上的第一备用数据库；

3）第二处理单元2104，用于将接收到的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，对于第二服务器502而言，上述功能模块中的“第一”和“第二”可以互换。通过上述功能模块，可以在第一服务器402和第二服务器502之间形成互为主备的数据存储结构，具体地，可以如图7所示，其中，存储有第一主用数据的第一主用数据库和存储有第二备用数据的第二备用数据库均位于第一服务器402，而存储有第一备用数据的第一备用数据库和存储有第二主用数据的第二主用数据库均位于第二服务器502。

如图7所示，在上述场景下，第一服务器402和第二服务器502可以分别连接执行第一业务和第二业务的客户端，并且在正常的工作状态下，第一服务器402和第二服务器502可以分别用于对第一业务和第二业务的相关数据，也即第一主用数据和第二主用数据进行存储，以及对第一业务和第二业务的分别处理，从而可以实现对于整体的写入压力的分担，并且可以克服现有技术中当用于对全部业务进行主控处理的主用服务器出现故障时，由于要将全部业务的相关数据切换为由备用服务器提供，所导致的错误数据可能出现在全部业务范围的问题，进而达到分散风险的目的。

一般而言，作为本发明更为优选的一种实施方式，还可以通过类似的手段将服务器规模扩大到两台以上的多台服务器形成的服务器组，并可以通过在这一环境下的本发明技术方案的实施，实现面向多项业务的更为高效的数据管理。

例如，图9示出了由三台服务器所组成的本发明技术方案的一种可选的应用环境，其中，三台服务器中的每一台可以对称地加载以下功能模块：

1）第一处理单元2102，用于将接收到的第一主用数据存储至第一服务器402上的第一主用数据库；

2）第五处理单元2502，用于将第一备用数据存储至第三服务器902上的第一备用数据库；

3）第二处理单元2104，用于将接收到的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，对于第二服务器502而言，上述功能模块中的“第一”可以替换为“第二”，“第二”可以替换为“第三”，“第三”可以替换为“第一”；对于第三服务器902而言，上述功能模块中的“第一”可以替换为“第三”，“第二”可以替换为“第一”，“第三”可以替换为“第二”。

进一步地，在上述场景下，第一服务器402、第二服务器502和第三服务器902可以分别连接执行第一业务、第二业务和第三业务的客户端，并且在正常的工作状态下，第一至第三服务器902可以分别用于对第一至第三业务的相关数据，也即第一至第三主用数据进行存储，以及对第一至第三业务的分别处理，从而可以实现对于整体的写入压力的分担，并且可以克服现有技术中当用于对全部业务进行主控处理的主用服务器出现故障时，由于要将全部业务的相关数据切换为由备用服务器提供，所导致的错误数据可能出现在全部业务范围的问题，进而达到分散风险的目的。

在另一方面，如图11所示，在本发明的另一些实施例中，对于类似于图9中的由三台服务器组成的本发明技术方案的一种可选的应用环境，三台服务器中的每一台还可以对称地加载以下功能模块：

1）第一处理单元2102，用于将接收到的第一主用数据存储至第一服务器402上的第一主用数据库；

2）第五处理单元2502，用于将第一备用数据存储至第二服务器502和第三服务器902上的第一备用数据库；

3）第二处理单元2104，用于将接收到的第二备用数据存储至第一服务器402上的第二备用数据库。

其中，对于第二服务器502而言，上述功能模块中的“第一”可以替换为“第二”，“第二”可以替换为“第三”，“第三”可以替换为“第一”；对于第三服务器902而言，上述功能模块中的“第一”可以替换为“第三”，“第二”可以替换为“第一”，“第三”可以替换为“第二”。

在这一场景下，类似地，分别位于第一至第三服务器902上的第一至第三主用数据库可以分别用于存储第一至第三业务的相关数据，从而在第一至三服务器上实现对于第一至第三业务的分别处理，在此不作赘述。然而，与图9示出的本发明技术方案的实施方式形成区别的是，在本发明实施例中，利用类似的硬件条件，可以在实现主备功能的基础上，在主用数据库所在的服务器外，为每一主用数据库提供两个备用数据库，且上述两个备用数据库可以分别位于不同的服务器，从而可以避免主用数据库和备用数据库之一或者二者所在的服务器同时出现故障而造成的对应业务无法处理的问题，进而提高了整个数据管理系统的稳定性和可靠性。

通过上述实施例，对本发明技术方案作出了更为详细的阐述，当然，上述实施例作为示例提出，不应视为对本发明提出了任何不必要的限定。此外，应当理解，上述实施例中作为本发明技术方案在第二服务器502和/或第三服务器902上的类同的实施方式，仍应视为在本发明的保护范围之内。

在另一方面，特别值得注意的是，本发明对第一处理单元2102和第二处理单元2104的执行主体不作限定，其中，该主体可以为第一服务器402的本地数据管理，也可以为第一服务器402内部的其他进程，还可以为第一服务器402外部的处理设备，其中，该处理设备可以包括缓存或其他类型的存储器，从而可以先将接收的数据存放在存储器中，并在对上述接收的数据进行识别和筛选以后，再将其分配给用于处理不同业务的各服务器。

在上述场景下，如图22所示，作为一种可选的实施方式，与第一处理单元2102耦合地，上述数据管理装置可以包括：

1）第三处理单元2202，用于在第一服务器402的内部或外部对接收到的数据进行筛选，并将接收数据中的第一主用数据分配给第一服务器402处理，将接收数据中的第二主用数据分配给第二服务器502处理。

如图14和图15所示，在本发明的一些实施例中，可以先将接收到的数据存储在缓存1402中，进而可以在第三处理单元2202中对上述接收到的数据进行筛选，并根据其所对应的业务将接收到的数据分配给各服务器处理。更具体地，图14和图15示出了两种可选的实施方式，其中，缓存1402可以如图14所示的，设置于第一服务器402的内部，也可以如图15所示的，设置于第一服务器402和第二服务器502的外部，当然，还可以有其他的可行的实施方式，例如，缓存1402还可以设置于第二服务器502上，或者同时设置于服务器组中的每一服务器上，从而可以在不改变原有的主从式架构的硬件基础上实施本发明的技术方案。当然，以上只是一些示例，本发明对此不作限定。

在上述场景下，如图23所示，第三处理单元2202可以进一步包括：

1）判断模块2302，用于判断接收到的数据是否包含与第一业务对应的第一标识项或者与第二业务对应的第二标识项；其中，在接收到的数据包含与第一业务对应的第一标识项时，判断模块2302判断出接收到的数据为第一主用数据；在接收到的数据包含与第二业务对应的第二标识项时，判断模块2302判断出接收到的数据为第二主用数据。

其中，第一标识项和第二标识项可以分别作为第一业务和第二业务的相关数据识别标识，设置在相关数据内，例如，可以在客户端对发送的数据进行封装时，根据客户端执行的业务，将第一标识项或第二标识项添加至数据包中，从而在对该数据包进行接收时，可以识别出其所对应的业务。

一般而言，上述的第一标识项和第二标识项可以设置为与业务唯一对应的代码，该代码可以由特定的字符串形成，然而本发明对此不作任何限定，例如，第一标识项和第二标识项也可以通过通信领域中可行的其他识别方式来实现，在此不作累述。

特别地，在本发明的一些实施例中，第一标识项和第二标识项可以分别设置为第一服务器402和第二服务器502的网络地址，从而对该第一标识项和第二标识项的识别以及数据的分送也可以在交换机或网关进行。当然，此类实施方式也可以视为在第一服务器402与执行第一业务的客户端、以及第二服务器502与执行第二业务的客户端之间建立了连接，从而形成类似于前述实施例中已经描述的场景。

进一步地，如图24所示，在本发明实施例中，上述数据管理装置还可以包括：

1）第四处理单元2402，用于将包括第一业务和第二业务在内的多个业务与包括第一标识项和第二标识项在内的多个标识项之间的对应关系存储至第一服务器402的内部或外部，其中，多个业务与多个标识项一一对应。

一般而言，在本发明实施例中，上述业务与标识项之间的对应关系可以通过映射表来体现，例如实施例1中的表1所示，对于由第一服务器402和第二服务器502形成的本发明技术方案的应用环境，该映射表可以包括以下两种数据：

1）业务ID，表示与业务对应的标识项；

2）Master IP，表示用于执行对应业务的主用数据库所在的服务器的地址。

其中，Master1可以用于表示第一服务器402的地址，Master2可以用于表示第二服务器502的地址，且第一服务器402和第二服务器502可以分别对应接收第一业务和第二业务的相关数据，从而在本发明实施例中，可以通过对业务ID的识别，判断出将接收到的数据发送至哪一个服务器。例如，当接收到的数据包含S1时，可以将其识别为第一业务，并发送至与第一业务对应的第一服务器402的地址Master1。

当然，应当理解，本发明通过上述实施例给出了基于第一和第二服务器502以及第一和第二业务的示例，然而这并不意味着对本发明形成了限制，例如，上述实施方式还可以扩展到多台服务器形成的服务器组的应用环境下，例如，可以在第一服务器402的内部存储如实施例1中的表2所示的规模更大的映射表，以便将接收到的数据发送至用于执行对应业务的服务器。

当然，以上只是一种示例，上述多个业务与多个标识项之间的对应关系还可以通过为本领域技术人员所知的其他可行的方式建立，本发明在此不做累述。

下面将结合一个现实场景给出本发明的更为具体的实施例。如图29所示，这一场景展示了一个HDFS，其中，该系统可以至少包括：一个数据仓库服务器2902、一个名称节点服务器2904以及多个数据节点服务器2906、2908和2910。其中，数据仓库服务器2902可以表现为DSS和联机分析应用数据源的结构化数据环境，其上建立的数据仓库的通常可以用于为前端查询和分析提供查询和分析基础，名称节点服务器2904可以用于对平台中存储信息的元数据进行管理，以确保上述数据仓库中的数据完整性，其中，该元数据可以用于数据仓库和底层存储结构之间的解析，而数据节点服务器2906、2908和2910可以用于实际数据信息的存储，并直接与客户端程序进行交互以及数据传输。

一般而言，在上述场景下作出的主备冗余设计中，通常可以将数据节点服务器之一，例如数据节点服务器2906作为主用服务器，而将数据节点服务器2908和2910设置为备用服务器，从而客户端在对数据仓库中的数据进行访问时，可以将数据请求提交给数据仓库服务器2902，进而通过名称节点服务器2904找到实际存储该数据请求对应的数据记录的数据节点服务器2906，并从该数据节点服务器2906向该客户端返回该数据记录。

与此不同的是，如图30所示，在本发明实施例中，数据仓库服务器2902可以作为前述数据管理方法的执行主体，用于对从上述数据仓库中的所有数据记录中划分出的多个数据块，例如图29中所示的实际存储并冗余备份在数据节点服务器2906、2908和2910上的第一数据块、第二数据块和第三数据块进行管理，其中，第一数据块可以包括第一业务对应的相关数据记录，比如可以用于记录一款即时通讯产品的用户相关信息，第二数据块可以包括第二业务对应的相关数据记录，比如可以用于记录一款在线游戏产品的用户相关信息，第三数据块可以包括第三业务对应的相关数据记录，比如可以用于记录一款社交服务产品的用户相关信息，其中，特别地，上述三款产品可以共享同一用户管理平台，从而三款产品各自对应用户相关信息可以合并到一张大数据表中，在另一方面，也可以视为该大数据表被划分为第一数据块、第二数据块和第三数据块。

进一步地，在本发明实施例中，作为可以将数据节点服务器2906作为上述即时通讯产品对应的主用服务器以及上述在线游戏产品和社交服务产品的备用服务器，将数据节点服务器2908作为在线游戏产品对应的主用服务器以及即时通讯产品和社交服务产品的备用服务器，并将数据节点服务器2906作为社交服务产品对应的主用服务器以及即时通讯产品和在线游戏产品。其中，该存储结构可以反映在名称节点服务器2904中，从而客户端在对数据仓库中的数据进行访问时，可以将数据请求提交给数据仓库服务器2902，进而通过名称节点服务器2904找到实际存储该数据请求对应的数据记录的数据节点服务器，例如，请求在线游戏的用户相关信息的，可以访问数据节点服务器2908并返回对应的数据记录。

作为与这一架构对应的数据管理方式，通过位于数据仓库服务器2902的第一处理单元2102，可以将接收到的第一主用数据即上述即时通讯产品的用户相关信息录入第一数据块，并实际存储至第一服务器即数据节点服务器2906，并且通过位于数据仓库服务器2902的第二处理单元2104，将接收到的第二主用数据即上述在线游戏产品的用户相关信息并入第二数据块，并实际存储至该数据节点服务器2906，并进一步地在数据节点服务器2908和2910上执行类似的操作，从而实现上述的存储结构。进一步地，可以将上述实际存储信息记录到元数据中，以便名称节点服务器的管理。

在这一存储结构下，面向即时通讯产品、在线游戏产品和社交服务产品的三个不同业务的底层存储结构的数据读/写压力可以分摊到三个数据节点服务器上，然而对于上层的数据仓库而言，其查询和分析的对象仍然可以是上述用户管理平台的大数据表，从而达到了在分布式文件系统下实现主备架构、且降低单个数据节点服务器的数据处理压力的技术效果。

当然，以上只是一个具体应用示例，并不意味着对本发明构成了任何不必要的限定，例如，上述数据管理装置中的功能单元也可以不设置在数据仓库服务器2902上，而是位于名称节点服务器2904或者独立在数据仓库服务器2902外的一个客户端模块等。进而以上述具体实施例为例，其他符合本发明构思的等效方案或者明显变型，均应视为在本发明的保护范围之内。

下面将结合图26至图28对根据本发明实施例的数据管理装置中用于实施主备切换的功能模块进行描述。

在如图5或图7所示的实施环境中，可选地，如图26所示，在本发明实施例中，上述数据管理装置还可以包括：

1）第一判断单元2602，用于判断第一服务器402或第一主用数据库是否处于正常的工作状态；

2）第六处理单元2604，用于在第一服务器402或第一主用数据库未处于正常的工作状态时，将用于指示第一备用数据库由备用状态切换至主用状态的消息通知给目标服务器。

如前所述，目标服务器表示用于存储第一备用数据的第一备用数据库所在的服务器，且通过前述的第五处理单元2502，第一备用数据可以作为第一主用数据的备份存入上述目标服务器。

在上述场景下，可以通过第一判断单元2602判断第一服务器402或第一主用数据库是否处于正常的工作状态，其中，该正常的工作状态通常可以指第一服务器402的不报错的运行状态，或者第一主用数据库能够进行正常的读写操作的状态。与之相反，若第一服务器402在运行中出现错误报告，或者第一主用数据库无法进行正常的读写操作。当然，以上只是一种示例，本发明对此不作限定，例如，也可以将在第一主用数据库中检测到错误的数据记录作为第一主用数据库未处于正常的工作状态的判断标准，等。

一般而言，考虑到数据批量处理中可能出现的个例错误，可以为第一服务器402或第一主用数据库未处于正常的工作状态设定一个时间阈值，其中，若非正常状态持续时间超过该时间阈值，则判断出未处于正常的工作状态，从而可以通过第六处理单元2604通知第一备用数据库所在的目标服务器由备用状态切换至主用状态。

进一步地，在目标服务器包括多个服务器的场景下，例如图11所示的应用环境，可以通过竞争机制，选举出最终执行备用到主用的切换的目标服务器。其具体实现方式在现有技术中存在多种选择，本发明在此不作累述。

在另一方面，可选地，如图27所示，在本发明实施例中，第六处理单元2604可以进一步包括：

1）询问模块2702，用于将用于询问第一备用数据库是否准备完成的消息通知给目标服务器；

2）通知模块2704，用于在预定的时间内从目标服务器中的一个或多个接收到用于指示第一备用数据库准备完成的消息时，将用于指示第一备用数据库由备用状态切换至主用状态的消息通知给目标服务器中的一个或多个。

其中，在第六处理单元2604中，在通知目标服务器进行备用到主用的切换之前，可以先向目标服务器发送该目标服务器上的第一备用数据库是否准备完成的询问信息，进而可以通过询问模块2702对该目标服务器是否作出回应进行判断，其中，若在预定的时间内接收到用于指示第一备用数据库准备完成的消息，则可以判断出该目标服务器处于正常的备用状态，从而可以利用通知模块2704，将上述由备用到主用的切换指示信息通知给该目标服务器，反之，若未在预定的时间内从目标服务器接收到回应，或接收到的回应并非为预定的准备完成信息，则判断出目标服务器未处于正常的备用状态，从而可以将该目标服务器排除出第一主用数据库对应的备用列表，其中，该备用列表可以用于存放可用的第一备用数据库的位置信息，例如其所在的服务器地址。

在上述场景中，通过对目标服务器是否准备完成的确认，可以确保第一备用数据库由备用到主用的切换的可靠进行，从而提高了整个数据管理系统的稳定性。

在另一方面，在本发明实施例中，也可以由备用数据库所在的服务器向与之对应的主用数据库所在的服务器反馈该备用数据库是否准备完成的信息，例如，可选地，如图28所示，在第二处理单元2104之后，上述数据管理装置还可以包括：

1）第二判断单元2802，用于判断第一服务器402或第二备用数据库是否处于正常的工作状态；

2）第七处理单元2804，用于在第一服务器402或第二备用数据库未处于正常的工作状态时，将用于指示第二备用数据库未准备完成的消息通知给第二主用数据库所在的服务器，和/或，将第一服务器402的标识从备用列表中移除，其中，第二主用数据库记录有第二主用数据，备用列表中记录的标识所指示的服务器用于在第二主用数据库所在的服务器未处于正常的工作状态时，接收用于指示第二备用数据库由备用状态切换至主用状态的消息。

其中，可以通过第二判断单元2802对第一服务器402或位于第一服务器402上的第二备用数据库是否处于正常的工作状态进行判断，若未处于正常的工作状态，则在第七处理单元2804中，可以将用于指示第一服务器402或第二备用数据库未准备完成的信息通知给第二主用数据库所在的服务器。其中，在如图5或图7所示的应用环境中，与第二备用数据库对应的第二主用数据库可以位于第二服务器502上，从而，可以在判断出第一服务器402或第二备用数据库未处于正常的工作状态时，将该状态信息通知给第二服务器502，从而在第二服务器502或其上的第二主用数据库出现故障时，可以指示第一服务器402以外的存储有第二备用数据库的服务器进行备用到主用的切换，进而提高数据管理系统的可靠性。

当然，如上所述，也可以通过将第一服务器402的标识从备用列表中移除来实现在切换前对备用数据库的准备状态的确认。其中，上述备用列表可以存储在第一服务器402的内部或外部，或者服务器组以外的存储设备中，其中，该备用列表用于存放可用的备用数据库的位置信息，例如其所在的服务器地址，从而在主用数据库或其所在的服务器出现故障时，可以将用于指示主备切换的消息通知给备用列表中的服务器。

值得注意的是，在根据本发明实施例提供的数据管理装置中，上述功能模块中的一个或多个可以在现有的可编辑的数据管理平台上，例如Zookeeper等，利用其内设的功能或模块，通过程序或命令行的编写等可选的方式来实现，应当理解，此类实现方式仍应视为在本发明的保护范围之内。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的数据管理装置，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (16)

1.一种数据管理方法，其特征在于，包括：

将接收到的第一主用数据存储至第一服务器上的第一主用数据库，其中，所述第一主用数据为所述第一服务器直接或间接连接的一个或多个客户端上执行的第一业务的相关数据；

将接收到的第二备用数据存储至所述第一服务器上的第二备用数据库，其中，所述第二备用数据用于对第二主用数据进行备份，其中，所述第二主用数据为第二服务器直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

2.根据权利要求1所述的方法，其特征在于，在所述将接收到的第一主用数据存储至第一服务器上的第一主用数据库和所述将接收到的第二备用数据存储至所述第一服务器上的第二备用数据库中之前，还包括：

在所述第一服务器的内部或外部对接收到的数据进行筛选，并将所述接收数据中的所述第一主用数据分配给所述第一服务器处理，将所述接收数据中的所述第二主用数据分配给所述第二服务器处理。

3.根据权利要求2所述的方法，其特征在于，所述在所述第一服务器的内部或外部对接收到的数据进行筛选包括：

判断所述接收到的数据是否包含与所述第一业务对应的第一标识项或者与所述第二业务对应的第二标识项；

若所述接收到的数据包含与所述第一业务对应的第一标识项，则判断出将所述接收到的数据为所述第一主用数据；

若所述接收到的数据包含与所述第二业务对应的第二标识项，则判断出将所述接收到的数据为所述第二主用数据。

4.根据权利要求3所述的方法，其特征在于，在所述判断接收到的数据是否包含与所述第一业务对应的第一标识项或者与所述第二业务对应的第二标识项之前，还包括：

将包括所述第一业务和所述第二业务在内的多个业务与包括所述第一标识项和所述第二标识项在内的多个标识项之间的对应关系存储至所述第一服务器的内部或外部，其中，所述多个业务与所述多个标识项一一对应。

5.根据权利要求1至4中任一项所述的方法，其特征在于，在所述将接收到的第一主用数据存储至第一服务器上的第一主用数据库之后，还包括：

将第一备用数据存储至目标服务器上的第一备用数据库，其中，所述第一备用数据用于对所述第一主用数据进行备份，所述目标服务器包括第三服务器和/或所述第二服务器。

6.根据权利要求5所述的方法，其特征在于，在所述将第一备用数据存储至所述目标服务器上的第一备用数据库之后，还包括：

判断所述第一服务器或所述第一主用数据库是否处于正常的工作状态；

若所述第一服务器或所述第一主用数据库未处于正常的工作状态，则将用于指示所述第一备用数据库由备用状态切换至主用状态的消息通知给所述目标服务器。

7.根据权利要求6所述的方法，其特征在于，所述将用于指示所述第一备用数据库由备用状态切换至主用状态的消息通知给所述目标服务器包括：

将用于询问所述第一备用数据库是否准备完成的消息通知给所述目标服务器；

若在预定的时间内从所述目标服务器中的一个或多个接收到用于指示所述第一备用数据库准备完成的消息，则将用于指示所述第一备用数据库由备用状态切换至主用状态的消息通知给所述目标服务器中的所述一个或多个。

8.根据权利要求1至4中任一项所述的方法，其特征在于，在所述将接收到的第二备用数据存储至所述第一服务器上的第二备用数据库中之后，还包括：

判断所述第一服务器或所述第二备用数据库是否处于正常的工作状态；

若所述第一服务器或所述第二备用数据库未处于正常的工作状态，则将用于指示所述第二备用数据库未准备完成的消息通知给第二主用数据库所在的服务器，和/或，将所述第一服务器的标识从备用列表中移除，其中，所述第二主用数据库记录有所述第二主用数据，所述备用列表中记录的标识所指示的服务器用于在所述第二主用数据库所在的服务器未处于正常的工作状态时，接收用于指示所述第二备用数据库由备用状态切换至主用状态的消息。

9.一种数据管理装置，其特征在于，包括：

第一处理单元，用于将接收到的第一主用数据存储至第一服务器上的第一主用数据库，其中，所述第一主用数据为所述第一服务器直接或间接连接的一个或多个客户端上执行的第一业务的相关数据；

第二处理单元，用于将接收到的第二备用数据存储至所述第一服务器上的第二备用数据库，其中，所述第二备用数据用于对第二主用数据进行备份，其中，所述第二主用数据为第二服务器直接或间接连接的一个或多个客户端上执行的第二业务的相关数据。

10.根据权利要求9所述的装置，其特征在于，还包括：

第三处理单元，用于在所述第一服务器的内部或外部对接收到的数据进行筛选，并将所述接收数据中的所述第一主用数据分配给所述第一服务器处理，将所述接收数据中的所述第二主用数据分配给所述第二服务器处理。

11.根据权利要求10所述的装置，其特征在于，所述第三处理单元包括：

判断模块，用于判断所述接收到的数据是否包含与所述第一业务对应的第一标识项或者与所述第二业务对应的第二标识项；其中，

在所述接收到的数据包含与所述第一业务对应的第一标识项时，所述判断模块判断出所述接收到的数据为所述第一主用数据；

在所述接收到的数据包含与所述第二业务对应的第二标识项时，所述判断模块判断出所述接收到的数据为所述第二主用数据。

12.根据权利要求11所述的装置，其特征在于，还包括：

第四处理单元，用于将包括所述第一业务和所述第二业务在内的多个业务与包括所述第一标识项和所述第二标识项在内的多个标识项之间的对应关系存储至所述第一服务器的内部或外部，其中，所述多个业务与所述多个标识项一一对应。

13.根据权利要求9至12中任一项所述的装置，其特征在于，还包括：

第五处理单元，用于将第一备用数据存储至目标服务器上的第一备用数据库，其中，所述第一备用数据用于对所述第一主用数据进行备份，所述目标服务器包括第三服务器和/或所述第二服务器。

14.根据权利要求13所述的装置，其特征在于，还包括：

第一判断单元，用于判断所述第一服务器或所述第一主用数据库是否处于正常的工作状态；

第六处理单元，用于在所述第一服务器或所述第一主用数据库未处于正常的工作状态时，将用于指示所述第一备用数据库由备用状态切换至主用状态的消息通知给所述目标服务器。

15.根据权利要求14所述的装置，其特征在于，所述第六处理单元包括：

询问模块，用于将用于询问所述第一备用数据库是否准备完成的消息通知给所述目标服务器；

通知模块，用于在预定的时间内从所述目标服务器中的一个或多个接收到用于指示所述第一备用数据库准备完成的消息时，将用于指示所述第一备用数据库由备用状态切换至主用状态的消息通知给所述目标服务器中的所述一个或多个。

16.根据权利要求9至12中任一项所述的装置，其特征在于，还包括：

第二判断单元，用于判断所述第一服务器或所述第二备用数据库是否处于正常的工作状态；

第七处理单元，用于在所述第一服务器或所述第二备用数据库未处于正常的工作状态时，将用于指示所述第二备用数据库未准备完成的消息通知给第二主用数据库所在的服务器，和/或，将所述第一服务器的标识从备用列表中移除，其中，所述第二主用数据库记录有所述第二主用数据，所述备用列表中记录的标识所指示的服务器用于在所述第二主用数据库所在的服务器未处于正常的工作状态时，接收用于指示所述第二备用数据库由备用状态切换至主用状态的消息。