CN105677673A - 业务处理方法、装置及系统 - Google Patents

Abstract

本申请提供一种业务处理方法、装置及系统。方法包括：接收业务处理请求；当主数据库故障时，根据业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据，根据业务数据进行业务处理；其中，快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，第一时刻早于第二时刻，第二时刻是指从主数据库备份到备份数据库的最晚业务数据的产生时刻。本申请可以解决业务系统无法正常进行业务处理的问题，提高业务处理效率。

Description

业务处理方法、装置及系统

【技术领域】

本申请涉及互联网技术领域，尤其涉及一种业务处理方法、装置及系统。

【背景技术】

随着应用的发展，对业务系统可用性的要求越来越高。为了提高业务系统的可用性，需要将业务系统产生的业务数据存储到数据库中。但是，当数据库发生故障时，业务系统无法继续使用数据库中的业务数据，导致无法正常进行业务处理。

为了克服上述问题，现有技术一般采用数据库备份方案，当主数据库发生故障时，切换到备份数据库，由备份数据库接替主数据库继续向业务系统提供业务数据。该方案存在如下问题：从主数据库切换到备份数据库需要一定时间，通常在5分钟左右，在这段时间内，业务系统需要停止进行业务处理，导致业务处理效率较低。

【发明内容】

本申请的多个方面提供一种业务处理方法、装置及系统，用以解决业务系统无法正常进行业务处理的问题，提高业务处理效率。

本申请的一方面，提供一种业务处理方法，包括：

接收业务处理请求；

若主数据库故障，根据所述业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据，根据所述业务数据进行业务处理；

其中，所述快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到所述备份数据库的最晚业务数据的产生时刻。

本申请的另一方面，提供一种业务数据存储方法，包括：

接收数据存储指令；

根据所述数据存储指令，将当前待存储的业务数据存储到主数据库和处于可读状态的快照数据库中；

其中，所述快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到处于可读状态的备份数据库的最晚业务数据的产生时刻。

本申请的又一方面，提供一种业务处理装置，包括：

接收模块，用于接收业务处理请求；

读取模块，用于当主数据库故障时，根据所述业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据；

其中，所述快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到所述备份数据库的最晚业务数据的产生时刻；

业务处理模块，用于根据所述业务数据进行业务处理。

本申请的又一方面，提供一种业务数据存储装置，包括：

接收模块，用于接收数据存储指令；

存储模块，用于根据所述数据存储指令，将当前待存储的业务数据存储到主数据库和处于可读状态的快照数据库中；

其中，所述快照数据库用于存储在第一时刻之后到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到处于可读状态的备份数据库的最晚业务数据的产生时刻。

本申请的又一方面，提供一种业务处理系统，包括：业务处理装置、主数据库、备份数据库和快照数据库；其中，所述备份数据库和所述快照数据库均被配置为可读状态；

业务处理装置，用于接收业务处理请求，并在所述主数据库故障时，根据所述业务处理请求，从所述备份数据库和/或所述快照数据库中读取业务数据，根据所述业务数据进行业务处理；

所述主数据库被配置成存储所述业务数据；

所述备份数据库被配置成存储从所述主数据库备份过来的业务数据；

所述快照数据库被配置成存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到所述备份数据库的最晚业务数据的产生时刻。

在本申请中，将主数据库与处于可读状态的备份数据库和快照数据库相结合，通过备份数据库对主数据库中的业务数据进行备份，并通过快照数据库存储在早于从主数据库备份到备份数据库的最晚业务数据的产生时刻的第一时刻到当前时刻之间产生的业务数据，这部分业务数据包括主数据库中尚未备份到备份数据库中的业务数据，这样在有业务处理请求到来时，若主数据库发生故障，则可以不用等待备份数据库和快照数据库的启动，而是直接从备份数据库和快照数据库中获取到主数据库中存储的全部数据，实现对主数据库的完整替换，保证业务处理可以正常进行，解决了现有技术中由于备份数据库启动延时造成业务处理无法正常进行的问题，提高了业务处理效率。

【附图说明】

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例提供的业务处理方法的流程示意图；

图2为本申请一实施例提供的业务数据存储方法的流程示意图；

图3为本申请一实施例提供的业务处理装置的结构示意图；

图4为本申请一实施例提供的业务数据存储装置的结构示意图；

图5为本申请一实施例提供的业务处理系统的结构示意图；

图6为本申请另一实施例提供的业务处理系统的结构示意图。

【具体实施方式】

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

图1为本申请一实施例提供的业务处理方法的流程示意图。如图1所示，该方法包括：

101、接收业务处理请求。

102、当主数据库故障时，根据上述业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据，根据业务数据进行业务处理；其中，快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，第一时刻早于第二时刻，第二时刻是指从主数据库备份到备份数据库的最晚业务数据的产生时刻。

本实施例提供一种业务处理方法，可由业务处理装置来执行。业务处理装置可以是各种需要使用数据库中存储的业务数据开展业务的业务系统，例如淘宝系统、支付宝系统、腾讯业务系统等等。

现有技术中，当主数据库故障后，需要启用备份数据库，主备切换过程如下：

1、检查备份数据库的状态是否处于可启用为主数据库的状态；

2、激活备份数据库；

3、切换备份数据库为主数据库；

4、修改域名，把原来绑定给主数据库的域名绑定到新的主数据库；

5、检查业务是否正常。

在上述主备切换过程中，步骤1-3一般需要5分钟左右。在这段时间内，业务系统需要停止进行业务处理，导致业务处理效率较低。

针对现有技术中在主数据库故障时，由主数据库切换到备份数据库过程中无法正常进行业务处理的问题，本实施例提供一种改进的备份数据库，即处于可读状态的备份数据库，也就是说，本实施例中的备份数据库不仅可以用于备份主数据库中的业务数据，而且是一直处于可读状态的。基于本实施例提供的处于可读状态的备份数据库，当主数据库发生故障需要切换到备份数据库时，不需要等待备份数据库的启动，可以直接使用备份数据库(这里的使用主要是指可以直接从备份数据库中读取业务数据)，也就是说，主数据库可以直接切换到备份数据库，不存在时间延迟，因此在主备数据库切换过程中可以继续进行业务处理，不需要停止业务处理。

在一可选实施方式中，本实施例提供的处于可读状态的备份数据库可以是读写分离应用中的读库，这里的读库是指只有在数据库同步过程中允许写入数据，在其他应用场景中只允许往外读数据的数据库。

进一步，考虑到主数据库向备份数据库备份数据一般存在延迟，也就是说，主数据库和备份数据库所存储的业务数据并不完全相同，而是存在一定差异，例如备份数据库中存储的业务数据比主数据库中存储的业务数据可能要少1分钟左右的数据。值得说明的是，主数据库和备份数据库所存储的业务数据之间的差异视不同应用场景会有所不同。

在面临上述问题的情况下，在主数据库故障后，若直接使用备份数据库中的业务数据，有可能会因为业务数据的不完整导致业务处理失败。针对该问题，本实施例进一步提供一种新的快照数据库，该快照数据库处于可读状态，用以克服启动时延的问题，并且被配置成存储第一时刻到当前时刻之间产生的业务数据，这里的第一时刻早于或等于第二时刻，第二时刻是指从主数据库备份到备份数据库中的最晚业务数据的产生时刻。简单来说，主数据库中尚未备份到备份数据库中的业务数据可以在该快照数据库获取到。

值得说明的是，快照数据库实际上也是一数据库，只是存储的业务数据相对较少。

基于上述可知，在使用主数据库和快照数据库之前，还需要根据数据存储请求，向主数据库和快照数据库中存储业务数据。例如，向主数据库和快照数据库中存储业务数据的执行主体可以是业务处理装置，也可以是不同于业务处理装置的其他装置。在本申请各实施例中，以向主数据库和快照数据库中存储业务数据的执行主体是业务处理装置为例进行说明，则当有数据存储请求到来时，业务处理装置接收数据存储请求，根据数据存储请求，将当前待存储的业务数据存储到主数据库中，并将待存储的业务数据存储到快照数据库中。值得说明的是，快照数据库只需存储从第一时刻到当前时刻之间产生的业务数据。另外，主数据库还会按照预设的备份机制，将主数据库中的业务数据发送到备份数据库中进行备份。

值得说明的是，数据存储请求可以直接携带有待存储的业务数据，则业务处理装置从数据存储请求中获取待存储的业务数据，将其存储到主数据库和快照数据库中。或者，数据存储请求可以携带待存储的业务数据的路径信息，这样业务处理装置可以从该路径信息所指示的文件中获取待存储的业务数据，并将其存储到主数据库和快照数据库中。

在实际应用中，主数据库在未发生故障的情况下，会不停的向备份数据库备份业务数据，也就意味着第二时刻是不断变化的，相应的，第一时刻也会根据第二时刻的变化而变化。对快照数据库来说，若要成功存储从第一时刻到当前时刻之间产生的业务数据，需要确定第一时刻。为了便于快照数据库确定第一时刻，可以采用统计等方法预先获取主数据库和备份数据库之间的备份时延，该备份时延是指产生主数据库中尚未备份到备份数据库中的业务数据所需的最大时长。基于此，可以预先设定一时间长度(简称为预设时长)，该预设时长大于该备份时延，即大于产生主数据库中尚未备份到备份数据库中的业务数据所需的最大时长，进而确定第一时刻是与当前时刻相距该预设时长的时刻。举例说明，在一种业务场景中，主数据库与备份数据库中最多相差1分钟左右的业务数据，则可以设定备份时延为1分钟，并设定预设时长为5分钟，也就是说，快照数据库需要存储当前时刻以及当前时刻之前5分钟内产生的业务数据，这部分业务数据包括主数据库中尚未备份到备份数据库中的1分钟左右的业务数据。

对于快照数据库来说，可以将快照数据库中产生时刻距离当前时刻的时间间隔大于预设时长(例如5分钟)的业务数据删除，以便于存储最新产生的业务数据。或者，也可以为快照数据库设定与预设时长内产生的业务数据相对应的存储容量，并采用类似“先入先出”式的存储方式，这样当有新的业务数据到达时，旧的业务数据就会被挤出，使得快照数据库中永远存储产生时刻与当前时刻的间隔小于或等于预设时长的业务数据。

本实施例通过将主数据库与处于可读状态的备份数据库和快照数据库相结合，通过备份数据库对主数据库中的业务数据进行备份，并通过快照数据库存储主数据库中尚未备份到备份数据库中的那部分业务数据，这部分业务数据也就是在早于从主数据库备份到备份数据库的最晚业务数据的产生时刻的第一时刻到当前时刻产生的业务数据。这样，当业务处理装置接收到业务处理请求时，可以从业务处理请求中获取用于标识业务处理所需的业务数据的数据标识；若主数据库未发生故障，则根据该数据标识从主数据库中获取业务处理所需的业务数据，进而进行业务处理；若主数据库发生故障，则根据该数据标识，直接从处于可读状态的备份数据库和/或快照数据库中读取业务处理所需的业务数据，进而进行业务处理。

在一可选实施方式中，业务处理装置可以判断快照数据库中是否有数据；若快照数据库中没有数据，意味着从第一时刻到当前时刻这段时间内未产生新的业务数据，也就意味着备份数据库中业务数据与主数据库中的业务数据是一致的，因此可以直接用备份数据库接替主数据库，于是根据上述业务处理请求从备份数据库中读取业务处理所需的业务数据；若快照数据库中有数据，意味着从第一时刻到当前时刻这段时间内产生了新的业务数据，也就意味着备份数据库和快照数据库中的业务数据结合起来才和主数据库中的业务数据是一致的，但是由于业务处理所需的业务数据可能有各种情况，所以可以根据业务处理请求从快照数据库和/或备份数据库中读取业务数据。

例如，一种判断快照数据库中是否有数据的实施方式包括：业务处理装置可以直接对快照数据库进行读取操作，若读取到业务数据，则确定快照数据库中有数据；若未读取到数据，则确定快照数据库中没有数据。或者，快照数据库也可以设置一数据标记，通过该数据标记来标识是否有数据，例如有数据时，可以将该数据标记设置为1，没有数据时，可以将该数据标记设置为0。基于此，另一种判断快照数据库中是否有数据的实施方式包括：业务处理装置可以读取快照数据库中的数据标记，通过该数据标记的取值来判断快照数据库中是否有数据。例如，若数据标记为1，说明快照数据库中有数据；若数据标记为0，说明快照数据库中没有数据。

例如，在快照数据库中有数据的情况下，业务处理装置可以根据业务处理请求，对快照数据库进行读取操作；若从快照数据库中读取到业务处理请求对应的业务数据，则结束读取操作，直接根据读取的业务数据进行业务处理；若未从快照数据库中读取到业务处理请求对应的业务数据，则根据业务处理请求从备份数据库中读取业务数据，并根据读取的业务数据进行业务处理；若从快照数据库中读取到业务数据的部分数据，则根据业务处理请求继续从备份数据库中读取业务数据的其余部分，进而根据读取到的全部业务数据进行业务处理。

其中，业务处理请求中可以包括数据标识，该数据标识用于标识进行业务处理所需的业务数据，例如可以是时间戳或ID等信息。

在一可选实施方式中，业务处理装置在接收到业务处理请求后，可以将业务处理请求存储到失效切换(failover)数据库中，以及在获取到业务数据时，可以将业务数据存储到失效切换数据库中；其中，失效切换数据库的作用是保证业务处理装置正常进行业务处理。基于此，业务处理装置从failover数据库中读取业务处理请求和业务数据；再根据业务处理请求和业务数据进行业务处理，并将业务处理产生的新业务数据存储到快照数据库中。值得说明的，新的业务数据可以从快照数据库中及时备份到备份数据库中，以防止丢失新的业务数据。另外，业务处理请求除了包括数据标识之外，进一步还可以包括如何进行业务处理，例如可以指示对业务数据的处理操作。

经上述分析可知，本实施例将主数据库与处于可读状态的备份数据库和快照数据库相结合，通过备份数据库对主数据库中的业务数据进行备份，并通过快照数据库存储在早于从主数据库备份到备份数据库的最晚业务数据的产生时刻的第一时刻到当前时刻产生的业务数据，这部分业务数据包括主数据库中尚未备份到备份数据库中的业务数据，这样在有业务处理请求到来时，若主数据库发生故障，则可以不用等待备份数据库和快照数据库的启动，而是直接从备份数据库和快照数据库中获取到主数据库中存储的全部数据，实现对主数据库的完整替换，保证业务处理可以正常进行，解决了现有技术中由于备份数据库启动延时造成业务处理无法正常进行的问题，提高了业务处理效率，进而提升系统性能和用户体验。

为便于更加清楚的展现本实施例的技术效果，从以下几个方面将本实施例提供的方法与现有技术进行比较：

图2为本申请一实施例提供的业务数据存储方法的流程示意图。如图2所示，该方法包括：

201、接收数据存储指令。

202、根据上述数据存储指令，将当前待存储的业务数据存储到主数据库和处于可读状态的快照数据库中，其中，快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，第一时刻早于或等于第二时刻，第二时刻是指从主数据库备份到处于可读状态的备份数据库的最晚业务数据的产生时刻。

本实施例提供的业务数据存储方法可由业务数据存储装置来执行，该业务数据存储装置可以是任何需要存储数据到数据库的装置，例如可以是淘宝业务系统、支付宝系统或腾讯系统中的服务器等。

本实施例提供的业务数据存储方法可与上述业务处理方法配合使用，具体流程和有关各数据库的描述可参见前述实施例，在此不再赘述。

本实施例提供的方法，通过将主数据库与处于可读状态的备份数据库和快照数据库相结合，通过备份数据库对主数据库中的业务数据进行备份，并通过快照数据库存储在早于从主数据库备份到备份数据库的最晚业务数据的产生时刻的第一时刻到当前时刻之间产生的业务数据，这部分业务数据包括主数据库中尚未备份到备份数据库中的业务数据，这样在有业务处理请求到来时，若主数据库发生故障，则可以不用等待备份数据库和快照数据库的启动，而是直接从备份数据库和快照数据库中获取到主数据库中存储的全部数据，实现对主数据库的完整替换，保证业务处理可以正常进行，解决了现有技术中由于备份数据库启动延时造成业务处理无法正常进行的问题，提高了业务处理效率。

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

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

图3为本申请一实施例提供的业务处理装置的结构示意图。如图3所示，该装置包括：接收模块31、读取模块32和业务处理模块33。

接收模块31，用于接收业务处理请求。

读取模块32，与接收模块31连接，用于当主数据库故障时，根据接收模块31接收的业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据；

其中，快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，第一时刻早于第二时刻，第二时刻是指从主数据库备份到备份数据库的最晚业务数据的产生时刻。

业务处理模块33，与读取模块32连接，用于根据读取模块32读取的业务数据进行业务处理。

在一可选实施方式中，读取模块32具体可用于：

若快照数据库中有数据，则根据业务处理请求从快照数据库和/或备份数据库中读取业务数据；

若快照数据库中没有数据，则根据业务处理请求从备份数据库中读取业务数据。

在一可选实施方式中，读取模块32用于根据业务处理请求从快照数据库和备份数据库中读取业务数据，具体包括：

根据业务处理请求，对快照数据库进行读取操作；

若未从快照数据库中读取到业务数据，根据业务处理请求从备份数据库中读取业务数据；

若从快照数据库中读取到业务数据的部分数据，则根据业务处理请求从备份数据库中读取业务数据的其余部分。

在一可选实施方式中，接收模块31还用于，将业务处理请求存储到主数据库对应的失效切换数据库中；读取模块32还用于，将业务数据存储到主数据库对应的失效切换数据库中。基于此，业务处理模块33具体可用于：从失效切换数据库中读取业务处理请求和业务数据；根据业务处理请求和业务数据进行业务处理，并将业务处理产生的新业务数据存储到快照数据库中。

在一可选实施方式中，接收模块31还用于，在接收业务处理请求之前，接收数据存储请求，并根据数据存储请求，将当前待存储的业务数据存储到主数据库和快照数据库中。

在一可选实施方式中，第一时刻是与当前时刻相距预设时长的时刻，所述预设时长大于产生所述主数据库中尚未备份到所述备份数据库中的业务数据所需的最大时长。

本实施例提供的业务处理装置，将主数据库与处于可读状态的备份数据库和快照数据库相结合，通过备份数据库对主数据库中的业务数据进行备份，并通过快照数据库存储在早于从主数据库备份到备份数据库的最晚业务数据的产生时刻的第一时刻到当前时刻之间产生的业务数据，这部分业务数据包括主数据库中尚未备份到备份数据库中的业务数据，这样在有业务处理请求到来时，若主数据库发生故障，则可以不用等待备份数据库和快照数据库的启动，而是直接从备份数据库和快照数据库中获取到主数据库中存储的全部数据，实现对主数据库的完整替换，保证业务处理可以正常进行，解决了现有技术中由于备份数据库启动延时造成业务处理无法正常进行的问题，提高了业务处理效率。

图4为本申请一实施例提供的业务数据存储装置的结构示意图。如图4所示，该装置包括：接收模块41和存储模块42。

接收模块41，用于接收数据存储指令。

存储模块42，与接收模块41连接，用于根据接收模块41接收的数据存储指令，将当前待存储的业务数据存储到主数据库和处于可读状态的快照数据库中。

其中，快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，第一时刻早于或等于第二时刻，第二时刻是指从主数据库备份到处于可读状态的备份数据库的最晚业务数据的产生时刻。

在一可选实施方式中，第一时刻是与当前时刻相距预设时长的时刻，所述预设时长大于产生所述主数据库中尚未备份到所述备份数据库中的业务数据所需的最大时长。

本实施例提供的业务数据存储装置，通过将主数据库与处于可读状态的备份数据库和快照数据库相结合，通过备份数据库对主数据库中的业务数据进行备份，并通过快照数据库存储在早于从主数据库备份到备份数据库的最晚业务数据的产生时刻的第一时刻到当前时刻之间产生的业务数据，这部分业务数据包括主数据库中尚未备份到备份数据库中的业务数据，这样在有业务处理请求到来时，若主数据库发生故障，则可以不用等待备份数据库和快照数据库的启动，而是直接从备份数据库和快照数据库中获取到主数据库中存储的全部数据，实现对主数据库的完整替换，保证业务处理可以正常进行，解决了现有技术中由于备份数据库启动延时造成业务处理无法正常进行的问题，提高了业务处理效率。

图5为本申请一实施例提供的业务处理系统的结构示意图。如图5所示，该系统包括：业务处理装置51、主数据库52、备份数据库53和快照数据库54。其中，备份数据库53和快照数据库54均被配置为可读状态。

业务处理装置51，用于接收业务处理请求，并在主数据库52故障时，根据业务处理请求，从备份数据库53和/或快照数据库54中读取业务数据，根据业务数据进行业务处理。

主数据库52被配置成存储业务数据；

备份数据库53被配置成存储从主数据库52备份过来的业务数据；

快照数据库54被配置成存储在第一时刻到当前时刻之间产生的业务数据，第一时刻早于第二时刻，第二时刻是指从主数据库52备份到备份数据库53的最晚业务数据的产生时刻。

进一步，如图6所示，该系统还包括的失效切换(failover)数据库55。具体的，业务处理装置51接收到业务处理请求之后，将业务处理请求存储到主数据库对应的失效切换数据库55中，并在读取业务数据之后，先将业务数据存储到失效切换数据库55中；当进行业务处理时，从失效切换数据库55中读取业务处理请求和业务数据；根据业务处理请求和业务数据进行业务处理，并将业务处理产生的新业务数据存储到快照数据库中。

在一可选实施方式中，第一时刻是与当前时刻相距预设时长的时刻，所述预设时长大于产生所述主数据库中尚未备份到所述备份数据库中的业务数据所需的最大时长。

本实施例提供的业务处理系统，将主数据库与处于可读状态的备份数据库和快照数据库相结合，通过备份数据库对主数据库中的业务数据进行备份，并通过快照数据库存储在早于从主数据库备份到备份数据库的最晚业务数据的产生时刻的第一时刻到当前时刻产生之间的业务数据，这部分业务数据包括主数据库中尚未备份到备份数据库中的业务数据，这样在有业务处理请求到来时，若主数据库发生故障，则业务处理装置可以不用等待备份数据库和快照数据库的启动，而是直接从备份数据库和快照数据库中获取到主数据库中存储的全部数据，实现对主数据库的完整替换，保证业务处理可以正常进行，解决了现有技术中由于备份数据库启动延时造成业务处理无法正常进行的问题，提高了业务处理效率。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (16)

1.一种业务处理方法，其特征在于，包括：

接收业务处理请求；

若主数据库故障，根据所述业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据，根据所述业务数据进行业务处理；

其中，所述快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到所述备份数据库的最晚业务数据的产生时刻。

2.根据权利要求1所述的方法，其特征在于，所述根据所述业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据，包括：

若所述快照数据库中有数据，则根据所述业务处理请求从所述快照数据库和/或所述备份数据库中读取所述业务数据；

若所述快照数据库中没有数据，则根据所述业务处理请求从所述备份数据库中读取所述业务数据。

3.根据权利要求2所述的方法，其特征在于，所述根据所述业务处理请求从所述快照数据库和所述备份数据库中读取所述业务数据，包括：

根据所述业务处理请求，对所述快照数据库进行读取操作；

若未从所述快照数据库中读取到所述业务数据，根据所述业务处理请求从所述备份数据库中读取所述业务数据；

若从所述快照数据库中读取到所述业务数据的部分数据，则根据所述业务处理请求从所述备份数据库中读取所述业务数据的其余部分。

4.根据权利要求1所述的方法，其特征在于，所述根据所述业务数据进行业务处理之前，还包括：

将所述业务处理请求和所述业务数据存储到所述主数据库对应的失效切换数据库中；

所述根据所述业务数据进行业务处理，包括：

从所述失效切换数据库中读取所述业务处理请求和所述业务数据；

根据所述业务数据和所述业务处理请求进行业务处理，并将业务处理产生的新业务数据存储到所述快照数据库中。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述接收业务处理请求之前，还包括：

接收数据存储请求；

根据所述数据存储请求，将当前待存储的业务数据存储到所述主数据库和所述快照数据库中。

6.根据权利要求1-4任一项所述的方法，其特征在于，还包括：

将所述快照数据库中产生时刻等于或早于所述第二时刻的业务数据删除。

7.根据权利要求1-4任一项所述的方法，其特征在于，所述第一时刻是与当前时刻相距预设时长的时刻，所述预设时长大于产生所述主数据库中尚未备份到所述备份数据库中的业务数据所需的最大时长。

8.一种业务数据存储方法，其特征在于，包括：

接收数据存储指令；

根据所述数据存储指令，将当前待存储的业务数据存储到主数据库和处于可读状态的快照数据库中；

其中，所述快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到处于可读状态的备份数据库的最晚业务数据的产生时刻。

9.根据权利要求8所述的方法，其特征在于，所述第一时刻是与当前时刻相距预设时长的时刻，所述预设时长大于产生所述主数据库中尚未备份到所述备份数据库中的业务数据所需的最大时长。

10.一种业务处理装置，其特征在于，包括：

接收模块，用于接收业务处理请求；

读取模块，用于当主数据库故障时，根据所述业务处理请求，从处于可读状态的备份数据库和/或处于可读状态的快照数据库中读取业务数据；

其中，所述快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到所述备份数据库的最晚业务数据的产生时刻；

业务处理模块，用于根据所述业务数据进行业务处理。

11.根据权利要求10所述的装置，其特征在于，所述读取模块具体用于：

若所述快照数据库中有数据，则根据所述业务处理请求从所述快照数据库和/或所述备份数据库中读取所述业务数据；

若所述快照数据库中没有数据，则根据所述业务处理请求从所述备份数据库中读取所述业务数据。

12.根据权利要求11所述的装置，其特征在于，所述读取模块用于根据所述业务处理请求从所述快照数据库和所述备份数据库中读取所述业务数据，具体包括：

根据所述业务处理请求，对所述快照数据库进行读取操作；

若未从所述快照数据库中读取到所述业务数据，根据所述业务处理请求从所述备份数据库中读取所述业务数据；

若从所述快照数据库中读取到所述业务数据的部分数据，则根据所述业务处理请求从所述备份数据库中读取所述业务数据的其余部分。

13.根据权利要求10所述的装置，其特征在于，

所述接收模块还用于，将所述业务处理请求存储到所述主数据库对应的失效切换数据库中；

所述读取模块还用于，将所述业务数据存储到所述失效切换数据库中；

所述业务处理模块具体用于：

从所述失效切换数据库中读取所述业务处理请求和所述业务数据；

根据所述业务数据和所述业务处理请求进行业务处理，并将业务处理产生的新业务数据存储到所述快照数据库中。

14.根据权利要求10-13任一项所述的装置，其特征在于，

所述接收模块还用于，在接收所述业务处理请求之前，接收数据存储请求，并根据所述数据存储请求，将当前待存储的业务数据存储到所述主数据库和所述快照数据库中。

15.一种业务数据存储装置，其特征在于，包括：

接收模块，用于接收数据存储指令；

存储模块，用于根据所述数据存储指令，将当前待存储的业务数据存储到主数据库和处于可读状态的快照数据库中；

其中，所述快照数据库用于存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到处于可读状态的备份数据库的最晚业务数据的产生时刻。

16.一种业务处理系统，其特征在于，包括：业务处理装置、主数据库、备份数据库和快照数据库；其中，所述备份数据库和所述快照数据库均被配置为可读状态；

业务处理装置，用于接收业务处理请求，并在所述主数据库故障时，根据所述业务处理请求，从所述备份数据库和/或所述快照数据库中读取业务数据，根据所述业务数据进行业务处理；

所述主数据库被配置成存储所述业务数据；

所述备份数据库被配置成存储从所述主数据库备份过来的业务数据；

所述快照数据库被配置成存储在第一时刻到当前时刻之间产生的业务数据，所述第一时刻早于或等于第二时刻，所述第二时刻是指从所述主数据库备份到所述备份数据库的最晚业务数据的产生时刻。