CN105677675B - 业务处理方法及装置 - Google Patents

Abstract

本申请提供一种业务处理方法及装置。方法包括：接收用户的业务处理请求；若主数据库故障，判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作；第一时刻早于或等于从主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻；若判断结果为否，则根据业务处理请求，从备份数据库中读取业务数据，并根据业务数据进行业务处理。本申请可以一定程度的解决业务系统无法正常进行业务处理的问题，提高业务处理效率。

Description

业务处理方法及装置

【技术领域】

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

【背景技术】

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

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

【发明内容】

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

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

接收用户的业务处理请求；

若主数据库故障，判断所述用户是否在第一时刻到当前时刻之间执行过改动所述主数据库的操作；所述第一时刻早于或等于从所述主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻；

若判断结果为否，则根据所述业务处理请求，从所述备份数据库中读取业务数据，并根据所述业务数据进行业务处理。

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

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

判断模块，用于在主数据库故障时，判断所述用户是否在第一时刻到当前时刻之间执行过改动所述主数据库的操作；所述第一时刻早于或等于从所述主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻；

业务处理模块，用于在所述判断模块的判断结果为否时，根据所述业务处理请求，从所述备份数据库中读取业务数据，并根据所述业务数据进行业务处理。

在本申请中，接收用户的业务处理请求，若发现主数据库故障，则判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作，第一时刻早于或等于从主数据库备份到备份数据库中的最晚业务数据的产生时刻，由此可见，本申请通过判断当前请求业务处理的用户是否在备份数据库中最晚业务数据产生时刻之后执行过改动主数据库的操作，要是没有执行过，说明主数据库中尚未备份到备份数据库中的业务数据与该用户当前请求的业务处理无关，即使备份数据库中不存在这段时间产生的业务数据也不会影响用户当前请求的业务处理，于是根据业务处理请求从备份数据库中读取当前业务处理所需的业务数据，并根据所读取的业务数据进行业务处理，不用因为主备数据库切换而停止，提高了业务处理效率。

【附图说明】

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

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

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

【具体实施方式】

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

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

101、接收用户的业务处理请求。

102、若主数据库故障，则判断上述用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作，第一时刻早于或等于从主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻。若判断结果为否，即上述用户在第一时刻到当前时刻之间未执行过改动主数据库的操作，则执行步骤103；反之，可以结束操作。

103、根据上述业务处理请求，从备份数据库中读取业务处理所需的业务数据，并根据该业务数据进行业务处理。

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

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

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

2、激活备份数据库；

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

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

5、检查业务是否正常。

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

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

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

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

在面临上述问题的情况下，在主数据库故障后，若直接使用备份数据库中的业务数据，有可能会因为业务数据的不完整导致业务处理失败。针对该问题，本实施例进一步提供一种解决方案，具体的，在接收用户的业务处理请求之后，判断当前请求业务处理的用户是否在第一时刻到当前时刻之间执行过改动所述主数据库的操作，第一时刻早于或等于从主数据库备份到备份数据库中的最晚业务数据的产生时刻，要是没有执行过，说明主数据库在故障之前尚未备份到备份数据库中的业务数据与该用户当前请求的业务处理无关，也就是说该用户请求的业务处理不会用到主数据库在故障之前尚未备份到备份数据库中的业务数据，即使备份数据库中不存在这段时间产生的业务数据也不会影响用户当前请求的业务处理，于是根据业务处理请求从备份数据库中读取当前业务处理所需的业务数据，并根据所读取的业务数据进行业务处理，不用因为主备数据库切换而停止，提高了业务处理效率。其中，业务处理请求中可以包括数据标识，该数据标识用于标识进行业务处理所需的业务数据，例如可以是时间戳或ID等信息。

值得说明的是，用户可以通过其客户端或用户终端等向业务处理装置发送业务处理请求。

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

在一可选实施方式中，若上述判断结果为是，即用户在第一时刻到当前时刻之间执行过改动主数据库的操作，例如，用户可以通过客户端、用户终端、不同于本实施例业务处理装置的其他业务处理装置，或者通过本实施例的业务处理装置执行改动主数据库的操作，用户改动主数据库的操作可以包括向主数据库中写入新的业务数据、修改主数据库中的业务数据等，用户改动主数据库的操作有可能影响用户当前请求的业务处理，为了避免出现错误处理，则可以丢弃用户当前的业务处理请求。通过该丢弃操作，不仅可以防止对当前用户进行错误的业务处理，而且还可以促使该用户重新发送业务处理请求，使得该业务处理可以在主数据库恢复后被执行，保证成功执行该用户的业务处理。

在一可选实施方式中，上述判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作的实施方式，包括：

判断用户的标识信息是否出现在黑名单中；

若判断结果为是，确定用户在第一时刻到当前时刻之间执行过改动主数据库的操作；

若判断结果为否，确定用户在第一时刻到当前时刻之间未执行过改动主数据库的操作。

在该实施方式中，黑名单中存储有在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识。

进一步，主数据库故障后，当前备份数据库中的业务数据不可信，因此不能从备份数据库中获取改动过主数据库的用户标识，例如可以从上层业务系统去获取。基于此，判断用户的标识信息是否出现在黑名单中之前，包括：

在确定主数据库故障之后，向上层业务系统发送获取请求；

接收上层业务系统返回的在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识；

将在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识加入黑名单。

在该上述实施方式中，获取请求用于向上层业务系统请求在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识。上层业务系统可以通过查找日志文件，获取在第一时刻到当前时刻之间改动过主数据库的用户的标识。

例如：一笔支付业务，首先用户下单并进行支付，则会在订单系统的订单数据库和账务系统的账务数据库中分别产生业务数据，其中订单数据库中的业务数据主要是订单号、订单提交时间、所购买商品信息以及金额(即所购买商品的价格)等；账务数据库中存储的是用户的账户信息，例如支付前账户余额是1000，支付后账户余额是800。对于订单数据库和账务数据库均包括主数据库和备份数据库。假设账户数据库中的主数据库在将最新账户余额即800备份到账户数据库中的备份数据库之前发生故障，则业务处理装置可以从订单系统获取该用户在距离当前时刻10分钟之内改动过账户数据库中的主数据库，并将该用户的标识加入黑名单中。该举例中，以距离当前时刻10分钟之内作为第一时刻到当前时刻之间。这里的订单系统即为上层业务系统。假设，用户此时发出一请求查询账户余额的业务处理请求，则由于该用户的标识信息在黑名单中，即用户在举例当前时刻10分钟之内改动过账户数据库中的主数据库，账户数据库的主数据库尚未将余额800这一信息备份到备份数据库中，因此若基于账户数据库中的备份数据库将获取到余额1000，这是错误的，所以为避免错误的业务处理，需要将用户的业务处理请求丢弃。

在另一可选实施方式中，上述判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作的实施方式，包括：

向上层业务系统发送查询请求，以请求上层业务系统查询用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作；

根据上层业务系统返回的查询结果判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作。

若上层业务系统返回的查询结果为是，意味着用户在第一时刻到当前时刻之间执行过改动主数据库的操作；若上层业务系统返回的查询结果为否，意味着用户未在第一时刻到当前时刻之间执行过改动主数据库的操作。

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

由上述可见，本实施例通过判断当前请求业务处理的用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作，第一时刻早于或等于从主数据库备份到备份数据库中的最晚业务数据的产生时刻，要是没有执行过，说明主数据库中尚未备份到备份数据库中的业务数据与该用户当前请求的业务处理无关，即使备份数据库中不存在这段时间产生的业务数据也不会影响用户当前请求的业务处理，于是根据业务处理请求从备份数据库中读取当前业务处理所需的业务数据，并根据所读取的业务数据进行业务处理，不用因为主备数据库切换而停止，提高了业务处理效率。

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

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

图2为本申请另一实施例提供的业务处理装置的结构示意图。如图2所示，该装置包括：接收模块21、判断模块22和业务处理模块23。

接收模块21，用于接收用户的业务处理请求。

判断模块22，用于在主数据库故障时，判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作；第一时刻早于或等于从主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻。

业务处理模块23，与判断模块22和接收模块21连接，用于在判断模块22的判断结果为否时，根据接收模块21接收的业务处理请求，从备份数据库中读取业务数据，并根据业务数据进行业务处理。

在一可选实施方式中，业务处理模块23还用于，在判断模块22的判断结果为是时，丢弃业务处理请求。

在一可选实施方式中，判断模块22具体可用于：

判断用户的标识信息是否出现在黑名单中；

若判断结果为是，确定用户在第一时刻到当前时刻之间执行过改动主数据库的操作；

若判断结果为否，确定用户在第一时刻到当前时刻之间未执行过改动主数据库的操作。

在一可选实施方式中，业务处理装置还包括：生成模块，用于在确定主数据库故障之后，向上层业务系统发送获取请求；接收上层业务系统返回的在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识；将在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识加入黑名单。生成模块与判断模块22连接，用于向判断模块22提供黑名单。

在一可选实施方式中，判断模块22具体可用于：

向上层业务系统发送查询请求，以请求上层业务系统查询用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作；

根据上层业务系统返回的查询结果判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作。

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

本实施例提供的业务处理装置，接收用户的业务处理请求，若发现主数据库故障，则判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作，第一时刻早于或等于从主数据库备份到备份数据库中的最晚业务数据的产生时刻，要是没有执行过，说明主数据库中尚未备份到备份数据库中的业务数据与该用户当前请求的业务处理无关，即使备份数据库中不存在这段时间产生的业务数据也不会影响用户当前请求的业务处理，于是根据业务处理请求从备份数据库中读取当前业务处理所需的业务数据，并根据所读取的业务数据进行业务处理，不用因为主备数据库切换而停止，提高了业务处理效率。

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

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

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

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

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

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

Claims (12)

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

接收用户的业务处理请求；

若主数据库故障，判断所述用户是否在第一时刻到当前时刻之间执行过改动所述主数据库的操作；所述第一时刻早于或等于从所述主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻；

若判断结果为否，则根据所述业务处理请求，从所述备份数据库中读取业务数据，并根据所述业务数据进行业务处理。

2.根据权利要求1所述的方法，其特征在于，还包括：

若判断结果为是，则丢弃所述业务处理请求。

3.根据权利要求1所述的方法，其特征在于，所述判断所述用户是否在第一时刻到当前时刻之间执行过改动所述主数据库的操作，包括：

判断所述用户的标识信息是否出现在黑名单中；

若判断结果为是，确定所述用户在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作；

若判断结果为否，确定所述用户在所述第一时刻到当前时刻之间未执行过改动所述主数据库的操作。

4.根据权利要求3所述的方法，其特征在于，所述判断所述用户的标识信息是否出现在黑名单中之前，包括：

在确定所述主数据库故障之后，向上层业务系统发送获取请求；

接收所述上层业务系统返回的在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作的用户标识；

将在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作的用户标识加入所述黑名单。

5.根据权利要求1所述的方法，其特征在于，所述判断所述用户是否在第一时刻到当前时刻之间执行过改动所述主数据库的操作，包括：

向上层业务系统发送查询请求，以请求所述上层业务系统查询所述用户是否在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作；

根据所述上层业务系统返回的查询结果判断所述用户是否在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作。

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

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

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

判断模块，用于在主数据库故障时，判断所述用户是否在第一时刻到当前时刻之间执行过改动所述主数据库的操作；所述第一时刻早于或等于从所述主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻；

业务处理模块，用于在所述判断模块的判断结果为否时，根据所述业务处理请求，从所述备份数据库中读取业务数据，并根据所述业务数据进行业务处理。

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

所述业务处理模块还用于，在所述判断模块的判断结果为是时，丢弃所述业务处理请求。

9.根据权利要求7所述的装置，其特征在于，所述判断模块具体用于：

判断所述用户的标识信息是否出现在黑名单中；

若判断结果为是，确定所述用户在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作；

若判断结果为否，确定所述用户在所述第一时刻到当前时刻之间未执行过改动所述主数据库的操作。

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

生成模块，用于在确定所述主数据库故障之后，向上层业务系统发送获取请求；接收所述上层业务系统返回的在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作的用户标识；将在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作的用户标识加入所述黑名单。

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

向上层业务系统发送查询请求，以请求所述上层业务系统查询所述用户是否在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作；

根据所述上层业务系统返回的查询结果判断所述用户是否在所述第一时刻到当前时刻之间执行过改动所述主数据库的操作。

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