CN104156360B - 业务数据处理方法及系统 - Google Patents

Abstract

本申请提供一种业务数据处理方法及系统。该方法是使用数据库来处理业务数据，其中数据库包括主数据库和辅助数据库，所述方法包括：监控所述主数据库的状态信息；以及根据所述状态信息处理新业务数据，以使将所述新业务数据存储到所述主数据库或是所述辅助数据库中，其中所述辅助数据库处于运行状态。通过使用本申请的方案，能够提高系统的可用率，在系统停机维护或发生故障时能够快速地启用处于运行状态的辅助数据库来处理业务数据，从而实现了对业务数据的保护，加快了系统的应急响应速度。

Description

业务数据处理方法及系统

技术领域

本申请涉及数据处理技术领域，尤其涉及一种业务数据处理方法及系统。

背景技术

在当前的数据处理技术领域中即时处理业务数据的技术不断发展，通常要求相关的数据存储在一个数据库中。一般来说，例如以用户为维度来组织数据。当一个数据库由于软硬件方面发生异常而不能工作时，会影响到固定数量的业务不能正常进展。面对这样的问题，现有技术中往往采用以更小的维度将一个数据库的数据拆分到多个数据库，例如将一个数据库的数据拆分到10个数据库中来缩小影响范围。然而，即使拆分成10个数据库后，当其中一个数据库不可用时，也会影响到10%的用户的业务量，对于业务的进展来说仍然属于不可接受的水平。另外，PC服务器的可用率大约为99%，如果只依赖于一个硬件，那么单个用户的可用率只能达到99%，而无法达到业务需求的99.99%的水平。由此可知，针对将一个数据库拆分成多个数据库的方案，对于每一份来讲，业务还是依赖于一个单独的软硬件，对于这个单独的软硬件所支撑的业务数据还是缺少保护，并且需要投入更多的软硬件成本。例如要做到在软硬件方面发生故障时对业务的影响达到1%，就必须有真实的100套软硬件，这样会造成软硬件资源的浪费。

另外，当系统的软件或硬件需要升级时，往往要在一个较长的时间内进行维护，这时也会影响到用户的业务数据的存储。此外，当硬件或软件发生异常时，由于业务的需求而需要保证业务数据不能丢失，所以需要利用额外的时间来处理数据的准确性（比如从日志补录数据、冻结可能有数据丢失的用户信息等），会导致在较长时间内业务不可用，或者需要在很短的时间内完成业务恢复的操作。在这种情况下，通过数据库本身机制或者通过硬件的替换来解决单个数据库不可用的问题，一般大约需要十五分钟以上的时间。在考虑到处理数据发生异常而导致丢失的问题时，实时所需要恢复业务的时间可能会更长。

另外，在现有技术中，当系统的软硬件出现故障时通常采用HA切换方案，即将主数据库切换到与其对应的备份数据库（Failover）。实际上，HA切换方案只是针对服务器之间进行切换的状况，即当一台服务器不可用时，可以较快地切换到另一台服务器上。但是，如果存储业务数据的存储器发生了故障，则由于无法使用HA切换方案而导致存储器中的业务数据丢失。而且，对于依赖于软硬件层面的HA切换方案的业务系统来说，不仅成本高，而且切换的时间长达10分钟左右。

发明内容

本申请的主要目的在于提供一种业务数据处理方法及系统，以解决现有技术存在的系统的可用率低、系统由于停机维护或发生故障而造成的业务损失、以及系统的应急响应速度慢等问题，其中：

本申请的一个方面，提供一种业务数据处理方法。在该方法中，使用数据库处理业务数据，其中，所述数据库包括主数据库和辅助数据库，所述方法包括：监控所述主数据库的状态信息；以及根据所述状态信息处理新业务数据，以使将所述新业务数据存储到所述主数据库或是所述辅助数据库中，其中，所述辅助数据库处于运行状态。

另外，在所述方法中，在根据所述状态信息处理新业务数据的步骤中，当监控到所述状态信息为数据库停机维修信息或数据库发生故障信息时，将所述新业务数据存储到所述辅助数据库。

另外，在所述方法中，在根据所述状态信息处理新业务数据的步骤中，当监控到所述状态信息不是数据库停机维修信息或数据库发生故障信息时，将所述新业务数据存储到所述主数据库。

另外，在所述方法中，所述主数据库和所述辅助数据库分别具有一个或多个，其中，多个所述主数据库能共享一个所述辅助数据库。

另外，在所述方法中，还包括：根据数据相关性来处理旧业务数据，以使将旧业务数据存储到所述主数据库或是所述辅助数据库。

另外，在所述方法中，所述数据相关性是使用业务编号所含有的预定标识对数据进行定位的特性。

另外，在所述方法中，所述预定标识包括分表标识和/或分库标识。

另外，在所述方法中，所述分库标识通过划分业务序号的方式来实现。

另外，在所述方法中，所述主数据库和所述辅助数据库被设置在同一机房或不同的机房。

本申请的另一方面，提供一种业务数据处理系统。在该系统中，使用数据库处理业务数据，其中，所述数据库包括主数据库和辅助数据库，所述系统包括：监控装置，被配置成监控所述主数据库的状态信息；以及处理装置，被配置成根据所述状态信息处理新业务数据，以使将所述新业务数据存储到所述主数据库或是所述辅助数据库，其中，所述辅助数据库处于运行状态。

另外，在所述系统中，当所述监控装置监控到所述状态信息为数据库停机维修信息或数据库发生故障信息时，所述处理装置将所述新业务数据存储到所述辅助数据库。

另外，在所述系统中，当所述监控装置监控到所述状态信息不是数据库停机维修信息或数据库发生故障信息时，所述处理装置将所述新业务数据存储到所述主数据库。

另外，在所述系统中，所述主数据库和所述辅助数据库分别具有一个或多个，其中，多个所述主数据库能共享一个所述辅助数据库。

另外，在所述系统中，所述处理装置还根据数据相关性来处理旧业务数据，以使将所述旧业务数据存储到所述主数据库或是所述辅助数据库。

另外，在所述系统中，所述数据相关性是使用业务编号所含有的预定标识对数据进行定位的特性。

另外，在所述系统中，所述预定标识包括分表标识和/或分库标识。

另外，在所述系统中，所述分库标识通过划分业务序号的方式来实现。

另外，在所述系统中，所述主数据库和所述辅助数据库被设置在同一机房或不同的机房。

与现有技术相比，根据本申请的技术方案，能够在业务系统的软硬件方面发生故障或系统维护时能够使用运行状态下的辅助数据库来快速地处理业务数据，从而能够提高系统的可用率，减少系统由于停机维护或发生故障而造成的业务损失，以及加快系统的应急响应速度。

附图说明

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

图1是本申请涉及的业务数据处理方法的示意流程图；

图2A和图2B是本申请涉及的附加有特定标识的业务编号的格式的示意图；

图3是本申请的业务系统的一具体实例的结构示意图；

图4是应用了图3所示的业务系统的业务数据处理的流程图；

图5是本申请涉及的常用的一个辅助数据库的跨机房结构的示意图；

图6是本申请涉及的采用两个辅助数据库的跨机房结构的示意图；

图7是本申请涉及的业务数据处理系统的结构示意图。

具体实施方式

本申请的主要思想在于，主要采用了在业务数据系统中引入辅助数据库（以下，也称为“secondary库”）的手段，即在业务系统的软硬件方面发生故障时能够使用运行状态下的辅助数据库来快速地处理业务数据，以解决业务系统运行的三大难题：系统的可用率低、系统由于停机维护或发生故障而造成的业务损失、以及系统的应急响应速度慢。

为使本申请的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本申请作进一步地详细说明。

本申请提供了一种业务数据处理方法。由于业务数据具有与一项业务有关的业务数据之间存在关联性的特点，所以可以从业务数据的数据相关性的角度来考虑业务数据处理的方法。下面，对业务数据的数据相关性进行说明。

〔关于业务数据的数据相关性〕

在业务系统中往往需要依据数据的相关性来组织各种业务数据。这里的数据的相关性是指一项业务涉及的大量数据之间存在着一定的关联性，例如一项业务可以以业务编号为中心来组织数据。业务系统可以包括多个用作数据库的计算节点。在这种情况下，为了快速地对业务数据进行定位，以使得提高业务数据的相关性以及尽可能缩短将业务数据存入到相应的数据库（例如本申请涉及的主数据库或辅助数据库）的时间，本申请采用了例如在业务编号中增加用于数据定位的标识位的业务数据定位方法。下面，以在业务系统中所有业务的相关数据均以业务编号为中心进行组织为例，对本申请涉及的业务数据定位方法进行详细说明。

为了将一项业务的相关数据都存入一个数据库中，通常在一项业务的所有处理环节中需要使用该项业务的业务编号来组织业务数据。在现有技术中，一项业务的业务编号通常是系统随机分配的，而业务系统存在多个数据库，因而，当存储某一项业务的业务数据时，就需要依次在每个数据库中查询该项业务的业务编号，直到查询到该业务编号后存储所述业务数据。在这种方式下，存储业务数据就需要较长的时间，也就是说业务数据的定位时间过长。另外，有时在不同数据库之间还存在业务编号重复的问题，有可能导致业务数据的定位发生错误。

针对现有技术中存在的上述问题，本申请采用了在业务编号中设置有分表、分库等特定标识的方法。具体来说，特定标识是用于准确地识别数据存储路径的标识位，分表标识用于区别一个数据库的数据被拆分成多份的情况，分库标识用于标识业务数据是记录在主数据库上还是记录在辅助数据库上。

图2A和图2B示出了本申请涉及的附加有特定标识的业务编号的示例。图2A表示使用了分表、分库标识的业务编号的示例，而图2B表示仅使用分表标识的业务编号的示例。

具体来说，如图2A所示，业务编号可以包括日期、特定标识以及业务序号。其中，日期表示业务数据的记录的时间，特定标识表示用于准确地识别数据存储路径的标识位，其包括分表标识和分库标识。业务序号表示业务系统随机产生而分配的序号。下面举例来说明增加了特定标识的业务编号。

假定分表标识是用于区分一个数据库的数据被拆分成10份后的标识，其用符号01～10来表示，而分库标识是用于区分各主数据库及各辅助数据库的标识，用符号P1～P3来表示三个主数据库，用符号S1来表示辅助数据库。在这种情况下，一项业务的业务编号例如是2001012209P21111。这表示随机序号为1111的这项业务的业务数据于2001年1月22日被存储在第09号的P2主数据库中。那么，由于在该项业务的其他相关联的业务数据中也包含分表分库标识09P2，所以每次处理该项业务的业务数据时都基于分表分库标识09P2而将该项业务的所有数据均存储在第09号的P2主数据库中。可见，分表分库标识等预定标识能够确保业务处理中的相关数据都直接存放在同一个数据库中。在上述例子中，示出了业务序号为四位的情况，但本申请不限于此，可以设定为任意位数的序号。

在图2A所示的例子中示出了将分表、分库标识作为特定标识的情况，但本申请不限于此，也可以例如如图2B所示那样仅用分表标识来作为特定标识。

如图2B所示，业务编号包括日期、分表标识以及业务序号。由于该业务编号中没有使用分库标识，所以可以使用业务序号来区分主数据库与辅助数据库，例如可以将大于800000000的业务序号设为主数据库（Primary库），将等于或小于800000000的业务序号设为辅助数据库（Secondary库）。

在假定分表标识用符号01～10来表示，以800000000为基准来区分一个主数据库和一个辅助数据库时，一项业务的业务编号例如是2001012209800000010。这表示随机序号为800000010的这项业务的业务数据于2001年1月22日被存储在第09号的主数据库中。那么，由于在该项业务的其他相关联的业务数据中也包含分表标识09，所以每次处理该项业务的业务数据时都基于分表标识09而将该项业务的所有数据均存储在第09号的主数据库中。可见，分表标识等预定标识能够确保业务处理中的相关数据都直接存放在同一个数据库中。

通过采用分表、分库等标识的方法，有效地解决了不同数据库之间业务编号重复的问题，并且可以根据业务编号快速地进行数据的准确定位，简单地提高了数据相关性的问题，缩短了存入业务数据的时间。

如上所述，本申请具体说明了在业务编号中增加预定标识的业务数据定位方法，但本申请不限于此，只要是能达到快速定位业务数据的目的的方法即可。

〔业务数据处理方法〕

图1是本申请涉及的业务数据处理方法的示意流程图。在本申请中，主要使用主数据库和辅助数据库来处理业务数据。主数据库和辅助数据库可以分别具有一个或多个，多个主数据库能共享一个辅助数据库。并且，主数据库和辅助数据库均处于运行状态。

本申请涉及的辅助数据库（Secondary库）与现有技术中的备份数据库（failover）不同。在现有技术中，备份数据库是指在主数据库发生故障时而被启动的处于待机或休眠等非运行状态下的另一数据库，而另一数据库中同步有主数据库的数据。在备份数据库被启动的过程中，备份数据库从非运行状态转移到运行状态需要一定的时间。而在本申请中，辅助数据库在正常情况下为空，不需要将主数据库的业务数据迁移到辅助数据库中，且辅助数据库与主数据库一样地处于运行状态，可以瞬时地对辅助数据库进行读写。

下面，详细说明业务数据处理的流程。

在步骤S101中，监控主数据库的状态信息。也就是说，监控主数据库是否可用。主数据库不可用的情况包括在软硬件方面发生故障或者主数据库停机维修等情况。实际上，就是要根据主数据库的状态来决定是否启用辅助数据库。

接着，在步骤S102中，根据主数据库的状态信息来处理新业务数据，以使将新业务数据存储到主数据库或是辅助数据库中。换句话说，在一项业务创建时，需要检测主数据库是否可用，在主数据库可用的情况下将业务数据写入主数据库；而在主数据库不可用的情况下，启用辅助数据库而将新业务数据存入到辅助数据库，以保证新业务可以持续创建成功。即，如果在步骤S101中监控到主数据库不可用，则将新业务数据存储到辅助数据库中；如果监控到主数据库可用，则将新业务数据存储到主数据库中。更具体来说，当监控到主数据库的状态信息是数据库停机维修信息或数据库发生故障信息等时，将新业务数据存储到辅助数据库。而当监控到主数据库的状态信息不是数据库停机维修信息或数据库发生故障信息等时，将新业务数据存储到主数据库。这里所说的新业务数据是指一项新业务的初始数据。与之相对，后述的旧业务数据是指一项旧业务的除初始数据以外的业务数据。

由于主数据库和辅助数据库同时处于运行状态中，所以即使在主数据库不可用时，也能够以最快的速度启用辅助数据库来代替主数据库而执行存储新业务数据的任务。这样，能够节省启动备份数据库所需的时间，并且尽量不间断地处理新业务数据，以使得用户不会感受到由于数据库不可用而导致的业务中断。

接着，在步骤S103中，根据业务数据的数据相关性来处理旧业务数据，以使将旧业务数据存储到主数据库或是辅助数据库。这里的数据相关性是使用业务编号所含有的预定标识对业务数据进行定位的特性。如上所述，预定标识是指在业务编号中能用以区分业务数据的定位目标的信息，它可以包括分表标识和/或分库标识等。实际上，在执行步骤S102之后，依然需要使用备份数据库等手段对已不可用的主数据库进行修复或者维护等处理，使得能够继续处理旧业务的后续的业务数据。即，当旧业务的初始数据被存储在主数据库中时，就将旧业务的后续业务数据存入主数据库，而当旧业务的初始数据被存储在辅助数据库中时，就将旧业务的后续业务数据存入辅助数据库。换句话说，当要推进业务数据时，由于业务数据之间具有相关性，即业务员编号中的预定标识表明了这项业务创建时初始数据是存入主数据库还是存入辅助数据库，因而可以准确地推进业务，将这项业务的后续数据都写入到业务创建时所在的数据库，这样保证了数据的相关性。

由此，完成业务数据的处理。由以上描述可知，由于业务编号中具有分库和/和分表标识等预定标识，所以根据业务数据的业务编号就能对业务数据进行定位。换句话说，在主数据库不可用时，将新业务的相关业务数据存入辅助数据库中，而在主数据库被修复后，根据业务编号中的预定标识将旧业务数据存入相应的数据库中，即：旧业务的初始数据位于主数据库就将该业务的后续数据存入主数据库中，而旧业务的初始数据位于辅助数据库就将该业务的后续数据存入辅助数据库中。并且，将新业务数据依然存入主数据库中。通过采用辅助数据库，能够及时处理在主数据库不可用后至其被修复之前这段期间内的新业务，从而能够提高业务系统的可用率，减少由系统发生异常而造成的损失。另外，由于主数据库和辅助数据库可以分别具有一个或多个，且多个主数据库能共享一个辅助数据库，所以能够节省业务系统的能源，降低成本。

〔实施例〕

下面，举例说明业务数据处理的流程。

图3是本申请的业务系统的一具体实例的结构示意图，图4是应用了图3所示的业务系统的业务数据处理的流程图。如图3所示，业务系统可以包括控制器、应用模块A、应用模块B、人工指令模块、自动检测模块、以及Primary1库、Primary2库、secondary库这三个数据库。具体来说，控制器是用于根据各数据库的状态变化向各应用模块发送状态变更信息的设备。应用模块A和应用模块B是根据来自控制器的数据库状态变更信息来决定将业务数据存入哪个数据库的设备。人工指令模块是用于在对数据库进行停机维护或自动检测模块不工作时人工发起Failover操作的设备。自动检测模块是用于自动检测各数据库的状态即各数据库是否可用的设备。并且，从人工指令模块发出的信息优先级高于从自动检测模块发出的信息的优先级。Primary1库、Primary2库是用于在正常运行时存储业务数据的主数据库。secondary库是用于在Primary1库和/或Primary2库不工作时取代处于不工作状态的Primary1库和/或Primary2库来存储业务数据的辅助数据库。

下面，结合图3和图4来说明业务数据的处理流程。

首先，在步骤S401中，自动检测模块对各数据库的状态进行检测，并将检测结果发送到控制器。另一方面，在自动检测模块发生故障而不工作或数据库需要停机维护时人工指令模块被启动，人工指令模块将各数据库的状态信息发送到控制器。

例如，假设在Primary1库不可用时，自动检测模块就会检测出Primary1库不可用、Primary2库可用这样的状态信息，并将该信息发送给控制器。另外，假设自动检测模块未发生故障且需要对Primary1库进行停机维护，或者自动检测模块发生故障而不工作、操作人员发现需要对Primary1库进行停机维护时，人工指令模块也向控制器发送Primary1库不可用、Primary2库可用这样的状态信息。

接着，在步骤S402中，控制器根据来自自动检测模块或人工指令模块的各数据库的状态信息向应用模块A和应用模块B发送各数据库的状态变更信息。

以上述例子来说明，当控制器接收到Primary1库不可用、Primary2库可用这样的状态信息后，向应用模块A和应用模块B分别发送从Primary1库切换到secondary库这样的状态变更信息。从Primary1库切换到secondary库即是停止使用Primary1库、启用secondary库的意思。

接着，在步骤S403中，应用模块A和应用模块B根据接收到的各数据库的状态变更信息来决定将业务数据发送到哪个数据库中。

以上述例子来说明，当应用模块A和应用模块B均接收到从Primary1库切换到secondary库这样的状态变更信息后，应用模块A和应用模块B分别将本来要存入Primary1库新业务的初始数据以及后续数据发送到secondary库，将要存入Primary2库新业务的所有数据和旧业务的所有数据继续发送到Primary2库。

由此，结束一次完整的业务数据的处理过程。在上述例子中，仅说明了根据从Primary1库切换到secondary库这样的状态变更信息控制业务数据存入哪个数据库的情况，但本申请不限于此，在Primary1库被修复以后，还会根据从secondary库切换到Primary1库这样的状态变更信息控制业务数据存入哪个数据库，其中，之前存入secondary库中的旧业务的后续数据依然被存入到secondary库。

以上，具体说明了具有两个主数据库共享一个辅助数据库的例子，但本申请不限于此，也可以是多个主数据库共享一个或多个辅助数据库。

另外，主数据库和辅助数据库可以被设置在同一机房中。但是，为了避免系统由断电等外界原因造成的系统损失，可以将主数据库和辅助数据库设置在不同的机房（有时将此称作“跨机房”）中，可以根据业务的需求及可接受的成本，灵活定制一个secondary库或多个secondary库的结构，确保业务的连续性。图5示出了常用的一个secondary库的跨机房结构。即，将Primary库设置在机房1中，将secondary库设置在机房2中。当然，也可以根据需求，扩展到两个secondary库的跨机房结构。图6示出了采用两个secondary库的跨机房结构。即，将Primary库设置在机房1中，将一个secondary库设置在机房2中，将另一个secondary库设置在机房3中。

本申请采用的辅助数据库可以通过服务器、磁盘阵列等来实现。辅助数据库可以使用与主数据库同样的硬件，以保证单机的可靠性。特别是，在用服务器构成主数据库、用磁盘阵列构成辅助数据库的情况下，有效地解决了HA切换方案不能解决的问题，即磁盘发生故障导致数据丢失这样的问题。另外，由于辅助数据库在正常情况下是没有业务的，所以多个主数据库可以共享一个辅助数据库，有效地降低了系统总体的成本。并且，通过可以将辅助数据库和主数据库布署在不同的机房，实现了跨机房结构的系统可用性保护。另外，本申请的主数据库和辅助数据库依然采用软硬件层面的HA切换方案来实现保护。进而，为了进一步加强数据保护，也可以先对业务数据进行一定的多份分拆处理，然后采用本申请的方案来实现进一步的数据保护。

通过采用本申请的业务数据处理方法，可以良好地解决可用率、停机维护以及系统应急响应问题。即：

可用率问题：有效地利用业务数据的相关性，将一个数据库扩展到多个数据库，从而解决业务对单个数据库的依赖问题。当一个数据库不可用时，可以将新业务快速引入到另一个可用的辅助数据库中。一个数据库的可用率是99%，两个数据库同时不可用的概率只有（0.01*0.01=0.0001），因而可用率可以达到99.99%。在采用图6所示的跨机房结构的情况下，理论上可用率可达到6个9（1－0.01*0.01*0.01=0.999999）的系统可用率，而投入的成本依然可控。

停机维护问题：当需要对系统的软硬件进行维护时，也可以主动将业务从一个数据库切换到另一个辅助数据库，完成维护操作后，再择机切回，从而解决业务系统停机维护影响业务的问题。

应急响应问题：当发生硬件异常时，可以快速地将新业务存入另一个可用的辅助数据库上，使得新业务不受影响，从而在充分长的时间内处理故障，避免由于在发生故障时考虑不周引起的其他问题，很大程度上也减少了应急响应的次数。

〔业务数据处理系统〕

图7是本申请涉及的业务数据处理系统的结构示意图。如图7所示，业务数据处理系统可以包括监控装置701和处理装置702。在业务数据处理系统中，使用主数据库和辅助数据库处理业务数据。当然，主数据库和辅助数据库可以分别具有一个或多个，多个主数据库能共享一个辅助数据库。并且，主数据库和辅助数据库均处于运行状态。

监控装置701是用于监控主数据库的状态信息的设备。

处理装置702是用于根据主数据库的状态信息来处理新业务数据以使将新业务数据存储到主数据库或是辅助数据库的设备。

具体来说，当监控装置701监控到状态信息为数据库停机维修信息或数据库发生故障信息时，处理装置702将新业务数据存储到辅助数据库。而当监控装置701监控到状态信息不是数据库停机维修信息或数据库发生故障信息时，处理装置702将新业务数据存储到主数据库。

此外，处理装置702还根据数据相关性来处理旧业务数据，以使将旧业务数据存储到主数据库或是辅助数据库。所述的数据相关性是使用业务编号所含有的预定标识对数据进行定位的特性。所述预定标识包括分表标识和/或分库标识。所述分库标识通过划分业务序号的方式来实现。

上述的主数据库和辅助数据库可以被设置在同一机房或不同的机房。

本申请的系统700所包括的各个模块的具体实施与本申请的方法中的步骤的具体实施可以是相对应的，为了不模糊本申请，在此省略对各个模块的具体细节描述。

本申请主要采用了在业务数据系统中引入辅助数据库的手段，在业务系统的软硬件方面发生故障或进行系统维护时能够使用运行状态下的辅助数据库来快速地处理业务数据，以解决业务系统运行的三大难题：系统的可用率低、系统由于停机维护或发生故障而造成的业务损失、以及系统的应急响应速度慢。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

应当注意，本申请的实施方式可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器（固件）的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。

应当注意，尽管在上文详细描述中提及了设备的若干模块或子模块，但是这种划分仅仅并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

Claims (16)

1.一种业务数据处理方法，使用数据库处理业务数据，其中，所述数据库包括主数据库和辅助数据库，所述方法包括：

监控所述主数据库的状态信息；

根据所述状态信息处理新业务数据，以使将所述新业务数据存储到所述主数据库或是所述辅助数据库中；以及

根据数据相关性来处理旧业务数据，以使将旧业务数据存储到所述主数据库或是所述辅助数据库，所述旧业务是指业务的除初始数据以外的业务数据；

其中，所述辅助数据库处于运行状态。

2.根据权利要求1所述的方法，其中，在根据所述状态信息处理新业务数据的步骤中，当监控到所述状态信息为数据库停机维修信息或数据库发生故障信息时，将所述新业务数据存储到所述辅助数据库。

3.根据权利要求2所述的方法，其中，在根据所述状态信息处理新业务数据的步骤中，当监控到所述状态信息不是数据库停机维修信息或数据库发生故障信息时，将所述新业务数据存储到所述主数据库。

4.根据权利要求1～3中任意一项所述的方法，其中，所述主数据库和所述辅助数据库分别具有一个或多个，其中，多个所述主数据库能共享一个所述辅助数据库。

5.根据权利要求1-3中任意一项所述的方法，其中，所述数据相关性是使用业务编号所含有的预定标识对数据进行定位的特性。

6.根据权利要求5所述的方法，其中，所述预定标识包括分表标识和/或分库标识。

7.根据权利要求6所述的方法，其中，所述分库标识通过划分业务序号的方式来实现。

8.根据权利要求1～3中任意一项所述的方法，其中，所述主数据库和所述辅助数据库被设置在同一机房或不同的机房。

9.一种业务数据处理系统，其使用数据库处理业务数据，其中，所述数据库包括主数据库和辅助数据库，所述系统包括：

监控装置，被配置成监控所述主数据库的状态信息；以及

处理装置，被配置成根据所述状态信息处理新业务数据，以使将所述新业务数据存储到所述主数据库或是所述辅助数据库；

所述处理装置还根据数据相关性来处理旧业务数据，以使将所述旧业务数据存储到所述主数据库或是所述辅助数据库，所述旧业务是指业务的除初始数据以外的业务数据；

所述辅助数据库处于运行状态。

10.根据权利要求9所述的系统，其中，当所述监控装置监控到所述状态信息为数据库停机维修信息或数据库发生故障信息时，所述处理装置将所述新业务数据存储到所述辅助数据库。

11.根据权利要求10所述的系统，其中，当所述监控装置监控到所述状态信息不是数据库停机维修信息或数据库发生故障信息时，所述处理装置将所述新业务数据存储到所述主数据库。

12.根据权利要求9～11中任意一项所述的系统，其中，所述主数据库和所述辅助数据库分别具有一个或多个，其中，多个所述主数据库能共享一个所述辅助数据库。

13.根据权利要求9～11中任意一项所述的系统，其中，所述数据相关性是使用业务编号所含有的预定标识对数据进行定位的特性。

14.根据权利要求13所述的系统，其中，所述预定标识包括分表标识和/或分库标识。

15.根据权利要求14所述的系统，其中，所述分库标识通过划分业务序号的方式来实现。

16.根据权利要求9～11中任意一项所述的系统，其中，所述主数据库和所述辅助数据库被设置在同一机房或不同的机房。