一时刻，可以采用统计等方法预先获取主数据库和备份数据库之间的备份时延，该备份时延是指产生主数据库中尚未备份到备份数据库中的业务数据所需的最大时长。基于此，可以预先设定一时间长度(简称为预设时长)，该预设时长大于该备份时延，即大于产生主数据库中尚未备份到备份数据库中的业务数据所需的最大时长，进而确定第一时刻是与当前时刻相距该预设时长的时刻。举例说明，在一种业务场景中，主数据库与备份数据库中最多相差I分钟左右的业务数据，则可以设定备份时延为I分钟，并设定预设时长为5分钟，也就是说，可以判断用户在当前时刻以及当前时刻之前5分钟内是否执行过改动主数据库的操作。
[0036]在一可选实施方式中，若上述判断结果为是，即用户在第一时刻到当前时刻之间执行过改动主数据库的操作，例如，用户可以通过客户端、用户终端、不同于本实施例业务处理装置的其他业务处理装置，或者通过本实施例的业务处理装置执行改动主数据库的操作，用户改动主数据库的操作可以包括向主数据库中写入新的业务数据、修改主数据库中的业务数据等，用户改动主数据库的操作有可能影响用户当前请求的业务处理，为了避免出现错误处理，则可以丢弃用户当前的业务处理请求。通过该丢弃操作，不仅可以防止对当前用户进行错误的业务处理，而且还可以促使该用户重新发送业务处理请求，使得该业务处理可以在主数据库恢复后被执行，保证成功执行该用户的业务处理。
[0037]在一可选实施方式中，上述判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作的实施方式，包括:
[0038]判断用户的标识信息是否出现在黑名单中；
[0039]若判断结果为是，确定用户在第一时刻到当前时刻之间执行过改动主数据库的操作；
[0040]若判断结果为否，确定用户在第一时刻到当前时刻之间未执行过改动主数据库的操作。
[0041]在该实施方式中，黑名单中存储有在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识。
[0042]进一步，主数据库故障后，当前备份数据库中的业务数据不可信，因此不能从备份数据库中获取改动过主数据库的用户标识，例如可以从上层业务系统去获取。基于此，判断用户的标识信息是否出现在黑名单中之前，包括:
[0043]在确定主数据库故障之后，向上层业务系统发送获取请求；
[0044]接收上层业务系统返回的在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识；
[0045]将在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识加入黑名单。
[0046]在该上述实施方式中，获取请求用于向上层业务系统请求在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识。上层业务系统可以通过查找日志文件，获取在第一时刻到当前时刻之间改动过主数据库的用户的标识。
[0047]例如:一笔支付业务，首先用户下单并进行支付，则会在订单系统的订单数据库和账务系统的账务数据库中分别产生业务数据，其中订单数据库中的业务数据主要是订单号、订单提交时间、所购买商品信息以及金额(即所购买商品的价格)等；账务数据库中存储的是用户的账户信息，例如支付前账户余额是1000，支付后账户余额是800。对于订单数据库和账务数据库均包括主数据库和备份数据库。假设账户数据库中的主数据库在将最新账户余额即800备份到账户数据库中的备份数据库之前发生故障，则业务处理装置可以从订单系统获取该用户在距离当前时刻10分钟之内改动过账户数据库中的主数据库，并将该用户的标识加入黑名单中。该举例中，以距离当前时刻10分钟之内作为第一时刻到当前时刻之间。这里的订单系统即为上层业务系统。假设，用户此时发出一请求查询账户余额的业务处理请求，则由于该用户的标识信息在黑名单中，即用户在举例当前时刻10分钟之内改动过账户数据库中的主数据库，账户数据库的主数据库尚未将余额800这一信息备份到备份数据库中，因此若基于账户数据库中的备份数据库将获取到余额1000，这是错误的，所以为避免错误的业务处理，需要将用户的业务处理请求丢弃。
[0048]在另一可选实施方式中，上述判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作的实施方式，包括:
[0049]向上层业务系统发送查询请求，以请求上层业务系统查询用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作；
[0050]根据上层业务系统返回的查询结果判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作。
[0051]若上层业务系统返回的查询结果为是，意味着用户在第一时刻到当前时刻之间执行过改动主数据库的操作；若上层业务系统返回的查询结果为否，意味着用户未在第一时刻到当前时刻之间执行过改动主数据库的操作。
[0052]在一可选实施方式中，业务处理装置在接收到业务处理请求后，可以将业务处理请求存储到失效切换(failover)数据库中，以及在获取到业务数据时，可以将业务数据存储到失效切换数据库中；其中，失效切换数据库的作用是保证业务处理装置正常进行业务处理。基于此，业务处理装置从failover数据库中读取业务处理请求和业务数据；再根据业务处理请求和业务数据进行业务处理，并将业务处理产生的新业务数据存储到备份数据库中。值得说明的，业务处理请求除了包括数据标识之外，进一步还可以包括如何进行业务处理，例如可以指示对业务数据的处理操作。
[0053]由上述可见，本实施例通过判断当前请求业务处理的用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作，第一时刻早于或等于从主数据库备份到备份数据库中的最晚业务数据的产生时刻，要是没有执行过，说明主数据库中尚未备份到备份数据库中的业务数据与该用户当前请求的业务处理无关，即使备份数据库中不存在这段时间产生的业务数据也不会影响用户当前请求的业务处理，于是根据业务处理请求从备份数据库中读取当前业务处理所需的业务数据，并根据所读取的业务数据进行业务处理，不用因为主备数据库切换而停止，提高了业务处理效率。
[0054]需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
[0055]在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
[0056]图2为本申请另一实施例提供的业务处理装置的结构示意图。如图2所示，该装置包括:接收模块21、判断模块22和业务处理模块23。
[0057]接收模块21，用于接收用户的业务处理请求。
[0058]判断模块22，用于在主数据库故障时，判断用户是否在第一时刻到当前时刻之间执行过改动主数据库的操作；第一时刻早于或等于从主数据库备份到处于可读状态的备份数据库中的最晚业务数据的产生时刻。
[0059]业务处理模块23，与判断模块22和接收模块21连接，用于在判断模块22的判断结果为否时，根据接收模块21接收的业务处理请求，从备份数据库中读取业务数据，并根据业务数据进行业务处理。
[0060]在一可选实施方式中，业务处理模块23还用于，在判断模块22的判断结果为是时，丢弃业务处理请求。
[0061]在一可选实施方式中，判断模块22具体可用于:
[0062]判断用户的标识信息是否出现在黑名单中；
[0063]若判断结果为是，确定用户在第一时刻到当前时刻之间执行过改动主数据库的操作；
[0064]若判断结果为否，确定用户在第一时刻到当前时刻之间未执行过改动主数据库的操作。
[0065]在一可选实施方式中，业务处理装置还包括:生成模块，用于在确定主数据库故障之后，向上层业务系统发送获取请求；接收上层业务系统返回的在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识；将在第一时刻到当前时刻之间执行过改动主数据库的操作的用户标识加入黑名单。生成模块与判断模块22连接，用于向判断模块22提供黑名单。
[0066]在一可选实施方式中，判断模块22具体可用于