数据写入方法、事务处理方法及装置与流程

本申请涉及数据库技术领域，特别涉及一种数据写入方法、事务处理方法及装置。

背景技术：

失效转移(failover)是一种常用的备份操作模式，该模式在业务系统包含主数据库和failover数据库的情况下，如果业务正常(非失效转移)时，业务系统使用主数据库进行业务数据的存储，而如果业务不正常(失效转移)时，由于主数据库不能使用，业务系统则会切换到上述failover数据库进行业务数据的存储，并在主数据恢复使用时，将上述failover数据库存储的业务数据回迁到所述主数据库中，上述方式可以确保业务系统在主数据库无法使用时仍然能够运行。

目前，通过计算机网络可以完成与终端上登录的账户对应的各种互联网事务。在一些具体的应用场景中，在完成上述互联网事务之前，计算机需要查询数据库中是否存在与当前账户对应的凭证数据。其中，该凭证数据作为所述账户进行上述互联网事务的凭证，一般可以在账户开户的过程中被写入到上述数据库中。在现有技术中，上述凭证数据一般可以在账户开户的过程中被写入到上述主数据库中，这样，在业务正常时，业务系统便可以通过查询该主数据库来进行上述互联网事务。

在上述现有技术中，由于只有主数据库中存储有与各个账户对应的凭证数据，在业务系统发生失效转移时，虽然业务系统可以切换到failover数据库进行业务数据的存储，但是因为业务系统并不能在失效转移时从上述主数据库中查询凭证数据(在查询不到凭证数据时，业务系统一般可以报告异常)，使得 业务系统在失效转移时无法完成与账户对应的互联网事务。

技术实现要素：

本申请实施例的目的是提供一种数据写入方法、事务处理方法及装置，用以解决上述现有技术中存在的问题。

为解决上述问题，本申请实施例提供数据写入方法、事务处理方法及装置通过如下技术方案来实现：

一种数据写入方法，包括：

第一服务器接收终端发送的将凭证数据写入数据库的确认指令；其中，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

第一服务器检查业务系统是否处于失效转移状态；

在业务系统未处于失效转移状态时，第一服务器将所述凭证数据写入第一数据库中；其中，所述第一数据库在业务系统未处于失效转移状态时被所述第一服务器查询；

在业务系统未处于失效转移状态时，第一服务器向第二服务器发送携带所述凭证数据的消息；其中，所述第二服务器用以在接收到所述消息后将所述凭证数据写入第二数据库中，所述第二数据库在业务系统处于失效转移状态时被所述第一服务器查询。

一种数据写入方法，包括：

第一服务器接收终端发送的将凭证数据写入数据库的确认指令；其中，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

第一服务器检查业务系统是否处于失效转移状态；

在业务系统未处于失效转移状态时，第一服务器将所述凭证数据写入第一数据库中；其中，所述第一数据库在业务系统未处于失效转移状态时被所述第一服务器查询；

在业务系统未处于失效转移状态时，第一服务器将所述凭证数据写入第二 数据库中；其中，所述第二数据库在业务系统处于失效转移状态时被所述第一服务器查询。

一种事务处理方法，包括：

第一服务器接收终端发送的与该终端上登录的账户对应的事务请求；

第一服务器检查业务系统是否处于失效转移状态；

在业务系统处于失效转移状态时，第一服务器查询第二数据库中是否存储有与所述账户对应的凭证数据；其中，所述第二数据库在业务系统处于失效转移状态时被所述第一服务器查询，并且所述第二数据库在业务系统不处于失效转移状态时被写入所述凭证数据，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

若在所述第二数据库中查询到所述凭证数据，第一服务器将与所述事务请求对应的业务数据写入failover数据库中；其中，所述failover数据库在业务系统处于失效转移状态时被第一服务器使用。

一种数据写入装置，包括：

指令接收单元，用于接收终端发送的将凭证数据写入数据库的确认指令；其中，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

检查单元，用于检查业务系统是否处于失效转移状态；

数据写入单元，用于在业务系统未处于失效转移状态时，将所述凭证数据写入第一数据库中；其中，所述第一数据库在业务系统未处于失效转移状态时被查询；

消息发送单元，用于在业务系统未处于失效转移状态时，向第二服务器发送携带所述凭证数据的消息；其中，所述第二服务器用以在接收到所述消息后将所述凭证数据写入第二数据库中，所述第二数据库在业务系统处于失效转移状态时被查询。

一种数据写入装置，包括：

指令接收单元，用于接收终端发送的将凭证数据写入数据库的确认指令； 其中，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

检查单元，用于检查业务系统是否处于失效转移状态；

第一写入单元，用于在业务系统未处于失效转移状态时，将所述凭证数据写入第一数据库中；其中，所述第一数据库在业务系统未处于失效转移状态时被查询；

第一写入单元，用于在业务系统未处于失效转移状态时，将所述凭证数据写入第二数据库中；其中，所述第二数据库在业务系统处于失效转移状态时被查询。

一种事务处理装置，包括：

请求接收单元，用于接收终端发送的与该终端上登录的账户对应的事务请求；

检查单元，用于检查业务系统是否处于失效转移状态；

查询单元，用于在业务系统处于失效转移状态时，查询第二数据库中是否存储有与所述账户对应的凭证数据；其中，所述第二数据库在业务系统处于失效转移状态时被查询，并且所述第二数据库在业务系统不处于失效转移状态时被写入所述凭证数据，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

业务数据写入单元，用于在所述第二数据库中查询到所述凭证数据时，将与所述事务请求对应的业务数据写入failover数据库中；其中，所述failover数据库在业务系统处于失效转移状态时被使用。

由以上本申请实施例提供的技术方案可见，在业务系统未处于失效转移状态时，通过第一服务器将所述凭证数据(所述账户进行预设互联网事务的凭证)写入到第一数据库中，于此同时，还将上述凭证数据写入到第二数据库中。其中，第一数据库在业务系统未处于失效转移状态时被查询，而第二数据库在业务系统处于失效转移状态时被查询。相比于现有技术，本申请实施例无论在业务系统未处于失效转移状态，还是在业务系统处于失效转移状态时，均可以通 过查询上述第一数据库或上述第二数据库是否存在与账户对应的凭证数据，从而完成与各账户对应的互联网事务。本申请实施例解决了现有技术无法在业务系统处于失效转移状态时完成互联网事务的问题。

附图说明

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

图1为本申请一实施例提供的示例性的系统架构示意图；

图2为本申请一实施例提供的数据写入方法的流程图；

图3为本申请一实施例中以第一服务器为主体的数据写入方法的流程图；

图4为本申请一实施例提供的事务处理方法的流程图；

图5为本申请一实施例提供的数据写入装置的模块示意图；

图6为本申请另一实施例提供的数据写入装置的模块示意图；

图7为本申请一实施例提供的事务处理装置的模块示意图。

具体实施方式

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

图1为本申请一实施例提供的包含主数据库和faiover数据库的业务系统的架构示意图。在本申请实施例中，该系统架构可以包括第一服务器100、第二服务器200、第一数据库10、failover数据库20、第二数据库30、终端300 及消息投递组件400。其中，第一服务器与终端300进行通信，用以进行与终端上登录的账户对应的互联网事务(如：账户内资金的转入或转出等)，所述终端上可以安装有与该第一服务器100对应的客户端应用。在失效转移(failover)模式中，上述第一数据库10(称为主数据库)可以使用时，上述failover数据库20并不被业务系统使用，而是作为备用数据库。本文中，在上述第一数据库10因某种因素(如数据库发生故障等)不可以使用时，将业务系统的状态称为失效转移(failover)状态，在业务系统处于失效转移状态时，业务系统可以切换到上述failover数据库20进行使用，以确保业务系统能够保持正常运行。其中，失效转移(failover)属于本领域技术人员所熟知的技术，不再对其进行细述。

在实现互联网事务的过程中，一般地，第一服务器100需要查询数据库中是否存在与终端300上登录的账户对应的凭证数据，该凭证数据可以作为上述账户进行互联网事务的凭证。若查询数据库中存在与账户对应的上述凭证数据，则表明当前互联网事务是合法的或安全的，进而执行该互联网事务的相关操作(如：将一定金额转入到指定账户中)；反之，如果查询数据库中不存在上述凭证数据，则表明当前互联网事务不是合法的或安全的，进而拒绝执行上述操作，并且可以向终端报告异常或提示当前账户没有相应的凭证数据。其中，一般地，上述与账户对应的凭证数据可以在账户开户的过程中，由用户通过终端300向上述第一服务器100发送确认指令(该指令可以是确认将上述凭证数据写入到数据库中)，从而由第一服务器100执行将该凭证数据写入数据库中的动作。

现有技术中，上述与账户对应的凭证信息被写入到上述第一数据库10中。这样在业务系统未处于失效转移状态时，第一服务器100可以通过查询上述第一数据库10中是否存在与账户对应的凭证信息，来判定与该账户对应的互联网事务是否合法或安全。然而，当业务系统处于失效转移状态时，上述第一数据库10并不能被业务系统所使用，即业务系统无法从该第一数据库10中查询 到与账户对应的凭证信息，从而使得业务系统拒绝执行与账户对应的互联网事务(原因是查找不到凭证信息，而实际上，与账户对应的凭证信息已经存在于上述第一数据库10中，即当前互联网事务为合法或安全的)。

没有将上述凭证信息写入上述failover数据库20的原因主要包括：

上述failover数据库20在业务系统处于失效转移状态(上述第一数据库10不可用)时，被业务系统使用，从而业务系统可以将失效转移状态发生的互联网事务对应的业务数据存放到该failover数据库20中。在第一数据库10恢复可用状态时，第一服务器100一般可以将存放于failover数据库20中的业务数据回迁到上述第一数据库10中，以确保上述第一数据库10(主库)中的业务数据的完整性。鉴于这一情况，如果将凭证信息备份到在上述failover数据库中，则当第一数据库10恢复可用时，势必需将存放于failover数据库20中的业务数据和凭证信息一并回迁到上述第一数据库10中，显然，将业务数据进行回迁是合理的，而将凭证信息进行回迁是不合理的。

鉴于现有技术中存在的上述问题，本申请实施例提供下述的数据写入方法，通过将凭证数据同时写入到上述第一数据库10和上述第二数据库30中，使得业务系统在处于失效转移状态(第一数据库不可用)时，可以通过查询上述第二数据库中是否存在与账户对应的凭证数据，来确保互联网事务能够正常进行。

值得说明的是，上述第一服务器100和第二服务器200可以是包含多个服务器的服务器集群，上述提及的各个数据库也可以是任意形式的数据库，本申请并不作限制。上述终端300可以是手机或电脑等。上述服务器与终端之间、上述服务器与数据库之间、上述服务器与服务器之间可以通过任意形式的网络进行通信。另外，上述图1所示的仅是本申请一种示例性的系统架构，在具体实现过程中，可以对上述系统架构进行变化。例如，第一服务器100和第二服务器200之间不通过消息投递组件来传递消息；或，省略上述第二服务器200，通过上述第一服务器100来执行向第二数据库30写入凭证数据的操作。

图2为本申请一实施例提供的数据写入方法的流程，包括：

s101：终端发送将凭证数据写入数据库的确认指令。

其中，所述凭证数据为在所述终端上登录的账户进行预设互联网事务的凭证。在一些应用场景中，上述账户在开户的过程中需要与某金融机构(如第三方支付平台、基金平台等)进行签约，签约的过程会产生签约数据，这些签约数据会被写入到数据库中，则在该类场景中，该签约数据便是上述凭证数据。当然，上述凭证数据并不限定为签约数据，在其他场景中，该凭证数据还可以是任意一种可以作为互联网事务的凭证的数据。比如，为不同的账户开设不同的权限，在进行预设互联网事务时，需要查询数据库，以得到与该账户对应的权限数据，从而确定当前账户是否具备进行预设互联网事务的权限。

一般地，在终端请求进行互联网事务(如资金转入、转出)时，若上述第一服务器查询数据库中存在与当前账户对应的凭证数据，表明与当前账户对应的互联网事务为合法的或安全的，则可以进一步执行上述互联网事务。反之，若在数据库中没有查询到凭证数据，则表明当前互联网事务不合法或不安全，则拒绝执行上述互联网事务。另外，在没有查询到凭证数据之后，第一服务器可以向终端推送用以提示用户没有查询到凭证数据的消息，并通知用户触发将该账户的凭证数据写入数据库的动作，用户可以通过终端向服务器发送上述确认指令的方式来确认将上述凭证数据写入数据库。

s102：第一服务器接收上述确认指令。

以资金类交易场景为例，第一服务器在接收到上述确认指令后，表明用户同意与某金融机构拟签订的合约中的相关条款，确认与该金融机构进行签约并生成签约数据。

s103：在业务系统未处于失效转移状态时，第一服务器将初始状态的凭证数据写入第一数据库中。

如上所述，第一数据库是(业务系统的主数据库)在非失效转移时被业务系统使用的。所以，在账户开户时，需要将该账户对应的凭证数据写入到该第 一数据库中，以便在进行与某账户对应的互联网事务时，可以通过查询该第一数据库中是否存在与该账户对应的凭证数据，来确定当前互联网事务是否合法或安全。

本申请实施例中，上述凭证数据可以包括初始状态和成功状态。按照一般的流程，用户与金融机构的签约(即签订合约)过程是双方签约过程，需要用户方和金融机构方分别进行签约确认的动作，其中，用户通过终端向第一服务器发送确认指令便是代表用户方的签约确认，而此时上述凭证数据虽然已经在数据库端被创建，但是由于只是用户方的单方确认合约，所以上述签约数据的状态为初始状态。在创建上述初始状态的凭证数据之后，金融机构方可以就上述签约过程进行确认，以对已被上述用户方确认后的签约数据进行确认，一般在金融机构方确认后，第一服务器可以接收到来自于金融机构方的确认指令，此时，上述凭证数据的状态可以由初始状态变更为成功状态。值得一提的是，本申请并不对上述签约数据的签约对象(如上述用户和金融机构)进行限定，例如，可以用户和金融机构签约、或金融机构与金融机构签约等，签约对象可以大于两个。

s104：在业务系统未处于失效转移状态时，第一服务器向第二服务器发送携带初始状态的凭证数据的消息；所述第二数据库在业务系统处于失效转移状态时被查询。

本申请实施例中，第一服务器是业务系统的核心，其需要进行凭证数据的查询、互联网事务的业务数据的存储和变更及失效转移的控制等事务，本身该第一服务器的负荷较大，为减小第一服务器的负荷，通过第二服务器来将上述凭证数据写入到第二数据库中。其中，第一服务器可以通过向第二服务器发送携带初始状态的凭证数据的消息，来触发将上述凭证数据写入到第二数据库的动作。值得一提的是，以签约场景为例，上述消息中可以携带签约数据的一个或多个参数，这些参数可以例如是：签约协议号、账户id、机构号(如金融机构)、状态(如初始状态、成功状态)、基金交易号、产品码等。其中，状态可 以通过“0”或“1”来表示。

为确保上述凭证数据被写入第一数据库的同时，也一定能够被写入到第二数据库中，以保证第一数据库和第二数据库中的凭证数据的一致性，本申请实施例中，上述消息可以为事务型消息。所述事务型消息是指：当投递方发出消息后，需要获取监听方的回执消息，若接收到表示数据写入成功的回执消息后，停止向监听方发送上述事务型消息；若接收到表示数据写入失败的回执消息，则需要重新向上述监听方发送事务型消息，直至接收到表示数据写入成功的回执消息。上述投递方可以为第一服务器，上述监听方可以为第二服务器。本申请实施例中，若第一服务器接收到第二服务器返回的表示数据写入失败的回执消息，为了确保写入第一数据库中的凭证数据，与向第二服务器发送的消息中携带的凭证数据相一致，第一服务器可以对接收到回执消息之前的操作进行回滚。可以看出，若向第二服务器发送的是事务型消息，则能够确保第一服务器(投递方)发送的消息被第二服务器(订阅方)成功接收到，并由该第二服务器成功将凭证数据写入到第二数据库中。

参图1所示，本申请实施例中，可以通过消息投递组件400来确保第一服务器100发送的事务型消息能够被第二服务器200监听到，并由第二服务器200将凭证数据写入到第二数据库30中。其中，所述消息投递组件400用以配置与所述第一服务器100发送的事务型消息对应的第一类型标识，及与所述第二服务器200接收的事务型消息对应的第二类型标识，所述第一类型标识与所述第二类型标识一致。其中，上述第一、第二类型标识可以是能够被唯一定位消息来源的标识：topic/eventcode，主要用以区分各种消息的类型，以避免被其他消息来源所干扰。其中，topic可以代表一个消息的大类，eventcode可以代表一个消息的子类。

在上述实施例中，第一服务器100将事务型消息发送给消息投递组件400，当消息被消息投递组件400接收到之后，第一服务器100便不需要关心事务型消息能不能被第二服务器200监听到。接下来，消息投递组件400可以通过向 第二服务器200发送携带上述凭证数据的事务型消息，并且要求第二服务器200发送回执消息，若消息投递组件400未接收第二服务器200发送的表示数据被成功写入的回执消息，消息投递组件400可以重新向第二服务器200发送携带所述凭证数据的事务型消息，直至接收到表示凭证数据被成功写入的回执消息。也就是说，通过该消息投递组件400可以确保上述凭证数据被成功写入第二数据库中。另外，第一服务器100将事务型消息发送给消息投递组件400之后，也可以要求消息投递组件400返回回执消息，消息投递组件400返回的回执消息可以包括：表示消息接收成功的回执消息和表示消息接收失败的回执消息，在第一服务器100接收到表示消息接收成功的回执消息之后，便停止向上述消息投递组件400发送事务型消息，反之，则会重新向上述消息投递组件400发送上述事务型消息。当然，如上所述，第一服务器100可以直接向第二服务器200发送上述事务型消息，并要求第二服务器200向第一服务器100返回相应的回执消息，本申请并对此进行限定。

s105：若第二服务器监听到上述消息，则将初始状态的凭证数据写入到第二数据库中。

s106：第一服务器接收确认将上述凭证数据的状态变更为成功的指令。

如前所述，在资金类交易场景中，上述凭证数据可以是用户方和金融机构方之间的签约数据，在用户方对上述凭证数据确认之后，可以由金融机构方再对上述凭证数据进行确认，在金融机构方确认之后，第一服务器可以接收到将上述凭证数据的状态变更为成功状态的指令。

s107：在业务系统未处于失效转移状态时，第一服务器将写入第一数据库中的凭证数据的状态变更为成功状态。

s108：在业务系统未处于失效转移状态时，第一服务器向第二服务器发送用于将上述凭证数据的状态变更为成功状态的变更消息。

s109：第二服务器在监听到所述变更消息时，将写入第二数据库中的凭证数据的状态变更为成功状态。

通过上述过程，本申请实施例在业务系统未处于失效转移状态时，通过第一服务器将所述凭证数据(所述账户进行预设互联网事务的凭证)写入到第一数据库中，于此同时，还可以通过第一服务器向第二服务器发送消息的方式，来由第二服务器将上述凭证数据写入到第二数据库中。其中，第一数据库是第一服务器在业务系统未处于失效转移状态时查询的，而第二数据库是第一服务器在业务系统处于失效转移状态时查询的。相比于现有技术，无论在业务系统是否处于失效转移状态时，上述第一服务器均可以通过查询第一数据库或第二数据库中是否存在与账户对应的凭证数据，来判定与账户对应的互联网事务的合法性或安全性，进而在确定互联网事务合法或安全时完成上述互联网事务，从而解决了现有技术中无法在业务系统处于失效转移状态时，正常完成与各账户对应的互联网事务的问题。

本申请实施例中，可以在将凭证数据(初始状态或成功状态)写入第一数据库之后，再通过消息的方式将上述凭证数据写入第二数据库。当然，将相同的凭证数据分别写入第一数据库、第二数据库之间可以不存在先后次序，可以先向第二数据库写入凭证数据，后向第一数据库写入同样的凭证数据。抑或，同时执行将凭证数据写入第一、第二数据库中的动作，本申请对此不作限定。

值得述及的是，在上述实施例中，上述凭证数据可以包括初始状态和成功状态，这样需要在第一数据库和第二数据库分别先创建初始状态的凭证数据，并在后续将上述凭证数据的初始状态变更为成功状态，可以看出，上述过程包含两次数据写入动作。当然，在替代的实施例中，上述第一数据库和第二数据库可以只进行一次写入数据的动作，即，在凭证数据为初始状态时，不进行数据写入动作，当上述凭证数据的状态由初始状态变更为成功状态时，才将凭证数据写入到上述第一数据库和第二数据库中。或者，上述凭证数据在用户方确认之后，便是成功状态，则可以在用户方发送确认指令后，直接将成功状态的凭证数据写入上述第一数据库和第二数据库中。关于上述凭证数据的状态的写入过程，存在多种可以实现的实施例，本申请并不作一一列举。

在实际业务过程中，可能会出现消息投递组件发送的消息多次投递消息的问题。为解决上述问题，本申请实施例中将消息投递组件投递的消息以签约协议号和状态进行唯一性的验证，这样，如果同样的签约协议号和同样状态的消息被消息投递组件发送两次(第二服务器也会相应监听到两次)，第一次监听到消息后，上述凭证数据成功落地到第二数据库中，第二次监听到同样的消息，则第二服务器可以通过查询第二数据库中是否存在所需写入的凭证数据，若存在，则忽略本次消息并向上述消息投递组件返回代表消息处理成功的回执消息(避免再次投递)。

此外，在实际业务过程中，可能会出现消息投递组件发送的消息乱序的问题。为解决上述问题，本申请实施例中，因为第二服务器一般需要监听两次来自第二服务器的消息，一次是创建初始状态的凭证数据，另一次是将初始状态的凭证数据变更为成功状态。通常，按照正常的流程，第一服务器先发送写入初始状态的凭证数据的消息，后发送变更成功状态的消息，但是，如果网络出现延迟或其它情况，则有可能会出现变更成功状态的消息先于写入初始状态的凭证数据的消息被第二服务器监听到，这样便是消息乱序情况，如果不解决这一问题，则会导致上述凭证数据的成功状态被初始状态覆盖。鉴于上述情况，消息投递组件在接收到携带初始状态的凭证数据的消息时，可以判断第二数据库中的凭证数据的状态，如果第二数据库中的凭证数据的状态已经是成功状态，则可以忽略状态更新，并向消息投递组件返回消息处理成功的回执消息，从而有效解决消息乱序问题。

本申请实施例中，所述第一数据库为oracle数据库，所述第二数据库为mysql数据库。其中，第一数据库由于是主数据库，存储有业务数据和凭证数据，采用oracle数据库可以使得数据的安全性更高。mysql数据库相较于oracle数据库，成本较低，由于上述第二数据库只是在业务系统发生失效转移时才会使用，并且该第二数据库中只是存储静态的凭证数据，故采取mysql数据库更为合适。

值得一提的是，在上述实施例提供的数据写入方法中，描述的是在账户开户过程中将与该账户对应的凭证数据写入数据库的过程。然而，对于已经完成开户并将相应的凭证数据写入到第一数据库中的账户，由于这些账户已经存在凭证数据，并不需要再次通过上述数据写入方法进行凭证数据的写入动作。鉴于上述原因，本申请实施例中，在非失效转移时，第一服务器可以将原本存储于上述第一数据库(主数据库)中的各个已开户的账户的凭证数据备份到该第二数据库中即可，从而确保第一数据库和第二数据库的凭证数据一致。

图3为本申请一实施例中以第一服务器为主体的数据写入方法的流程，与上述图2对应，可以参照上述图2的实施例中的具体内容。该数据写入方法可以包括：

s201：第一服务器接收终端发送的将凭证数据写入数据库的确认指令；其中，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证。

在资金类交易的场景中，上述凭证数据可以为与各账户对应的签约数据。如前所述，该签约数据可以是用户和金融机构、或金融机构与金融机构之间进行签约动作而生成的数据。在将生成的签约数据写入到数据库中后，该签约数据可以作为确定与账户对应的预设互联网事务(如：资金转入或转出)是否合法或安全的凭证。

s202：第一服务器检查业务系统是否处于失效转移状态。

如前所述，第一服务器可以通过检查失效转移标志来确定当前业务系统的状态。例如，若失效转移标志为1，则表示当前业务系统处于失效转移状态；若失效转移状态为0，则表示当前业务系统未处于失效转移状态(或处于正常状态)。

s203：在业务系统未处于失效转移状态时，第一服务器将所述凭证数据写入第一数据库中；其中，所述第一数据库在业务系统未处于失效转移状态时被所述第一服务器查询。

该步骤s203可以参照上述步骤s103的内容，本文不再予以赘述。

s204：在业务系统未处于失效转移状态时，第一服务器向第二服务器发送携带所述凭证数据的消息；其中，所述第二服务器用以在接收到所述消息后将所述凭证数据写入第二数据库中，所述第二数据库在业务系统处于失效转移状态时被所述第一服务器查询。

该步骤s204可以参照上述步骤s104的内容，本文不再予以赘述。

通过上述图3提供的实施例，业务系统可以在处于失效转移状态时，通过查询上述第二数据库中是否存在与账户对应的凭证数据，来判定与该账户对应的互联网事务是否合法或安全，并在合法或安全时完成该互联网事务。

值得一提的是，在本申请替换的实施例中，上述步骤s204可以通过下述过程来实现：在业务系统未处于失效转移状态时，第一服务器将所述凭证数据写入第二数据库中。

另外，本申请实施例中，在将上述凭证数据写入上述第一数据库和第二数据库后，还可以将上述凭证数据存放于缓存中(可以保存一段预设时长)，这样，在后续查询凭证数据的过程中，第一服务器可以优先通过查询缓存来获取相应的凭证数据，如果缓存中没有上述凭证数据，再查询第一数据库或第二数据库。

接下来，介绍一种使用上述第一数据库和第二数据库来实现账户的互联网事务的事务处理方法。

图4为本申请一实施例提供的事务处理方法的流程，包括：

s301：终端向第一服务器发送与终端上登录的账户对应的事务请求。该事务请求用以请求实现与账户对应的预设互联网事务。

在上述资金类交易的场景中，账户需要在开户的过程中，将签约数据存储于数据库中。上述预设互联网事务可以是针对该账户进行的金额转入/转出事务。

s302：第一服务器在接收到终端发送的请求之后，第一服务器查询缓存中是否存在与账户对应的凭证数据。

s303：在业务系统处于失效转移状态时，第一服务器查询第二数据库中是否有与账户对应的签约数据。若查询到签约数据，则进入步骤s305；若没有查询到签约数据，则判定当前事务请求对应的预设互联网事务不合法或不安全，并拒绝执行该预设互联网事务。

s304：在业务系统未处于失效转移状态时，第一服务器查询第一数据库中是否存在与账户对应的签约数据。若查询到所述签约数据，进入步骤s306；若没有查询到签约数据，则判定当前事务请求对应的预设互联网事务不合法或不安全，并拒绝执行该预设互联网事务。

s305：第一服务器在业务系统处于失效转移状态时，将与预设互联网事务对应的业务数据写入到failover数据库中。

s306：第一服务器在业务系统未处于失效转移状态时，将与预设互联网事务对应的业务数据写入到第一数据库中。

通过上述过程，第一服务器在进行账户的预设互联网事务的过程中，可以先通过查询缓存(该缓存可以是位于数据库上一层的数据存储单元)来查找是否存在与账户对应的签约数据。在从缓存中没有查找到相应的签约数据后，可以通过判断当前业务系统是否处于失效转移状态，在处于失效转移状态时，则查询第二数据库中是否有签约数据，在未处于失效转移状态时，则查询第一数据库中是否有签约数据，从而可以保证业务系统无论是否处于失效转移状态，都可以查询到与账户对应的签约数据，并依据查询结果来判定预设互联网事务是否合法或安全，进而完成账户的预设互联网事务。

另外，在业务系统处于失效转移状态时，则可以将预设互联网事务的业务数据(如转入金额，转入时间，转入账号等数据)写入到failover数据库，并在上述第一数据库恢复可用后，可以将failover数据库中临时存放的业务数据回迁到上述第一数据库，以确保第一数据库中存储的业务数据的完整性。

接下来，将介绍一种数据写入装置及事务处理装置，其中，该数据写入装置及事务处理装置与上述数据写入方法及事务处理方法对应，上述装置包含的 单元与上述方法中包含的步骤所实现的功能类似，故上述装置可以参照上述方法中的具体内容，本文不再予以赘述。另外，上述装置可以是通过软件、硬件或软硬件结合的方式来实现。

图5为本申请一实施例提供的数据写入装置的模块示意图。本申请实施例中，一种数据写入装置，包括：

指令接收单元101，用于接收终端发送的将凭证数据写入数据库的确认指令；其中，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证。

检查单元102，用于检查业务系统是否处于失效转移状态。

数据写入单元102，用于在业务系统未处于失效转移状态时，将所述凭证数据写入第一数据库中；所述第一数据库在业务系统未处于失效转移状态时被查询。

消息发送单元103，用于在业务系统未处于失效转移状态时，向第二服务器发送携带所述凭证数据的消息；所述第二服务器用以在接收到所述消息后将所述凭证数据写入第二数据库中，所述第二数据库在业务系统处于失效转移状态时被查询。

通过上述数据写入装置，无论在非失效转移状态时，还是在失效转移状态时，均可以通过查询第一数据库或第二数据库是否存在与账户对应的凭证数据，来判定当前互联网事务是否合法或安全，进而在合法或安全的前提下完成与各账户对应的互联网事务，从而解决了现有技术中无法在业务系统处于失效转移状态时，完成与各账户对应的互联网事务的问题。

本申请实施例中，所述装置还包括：

备份单元，用于在非失效转移时，将存储于第一数据库中的凭证数据备份到第二数据库中。通过该备份单元，可以将已开户的账户对应的凭证数据备份到第二数据库中，从而使得第一数据库和第二数据库中的凭证数据相一致。

本申请实施例中，所述消息发送单元103可以具体用于：

向第二服务器发送携带所述凭证数据的事务型消息；

则所述装置还可以用于：

在接收到来自于第二服务器的表示数据写入失败的回执消息时，重新向第二服务器发送所述事务型消息；

在第一服务器接收到来自于第二服务器的表示数据写入成功的回执消息时，停止向第二服务器发送所述事务型消息。

通过上述事务型消息，可以确保上述凭证数据能够被成功写入到上述第二数据库中。

本申请实施例中，所述消息发送单元103还可以具体用于：

向消息投递组件发送携带所述凭证数据的事务型消息；其中，所述消息投递组件用以将所述事务型消息向第二服务器发送，直至该消息投递组件接收到来自于第二服务器的表示数据写入成功的回执消息；

则所述装置还可以用于：

在接收到来自于消息投递组件的表示消息接收失败的回执消息时，重新向消息投递组件发送携带所述凭证数据的事务型消息；

在接收到来自于消息投递组件的表示消息接收成功的回执消息时，停止向消息投递组件发送携带所述凭证数据的事务型消息。

本申请一实施例中，所述数据写入单元102可以具体用于：

将初始状态的凭证数据写入所述第一数据库中，并在所述凭证数据的状态变更为成功状态时，将所述第一数据库中的凭证数据的状态进行变更。

另一实施例中，所述数据写入单元102可以具体用于：将成功状态的凭证数据写入所述第一数据库中；

本申请一实施例中，所述消息发送单元103可以具体用于：

向第二服务器发送携带初始状态的凭证数据的消息，并在所述凭证数据的状态变更为成功状态时，向第二服务器发送状态变更消息；其中，所述第二服务器用以在监听到所述状态变更消息后，将所述第二数据库中的凭证数据的状 态变更为成功状态。

另一实施例中，所述消息发送单元103可以具体用于：

向第二服务器发送携带成功状态的凭证数据的消息。

图6为本申请另一实施例提供的数据写入装置的模块示意图。本申请实施例中，一种数据写入装置，包括：

指令接收单元201，用于接收终端发送的将凭证数据写入数据库的确认指令；其中，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

检查单元202，用于检查业务系统是否处于失效转移状态；

第一写入单元203，用于在业务系统未处于失效转移状态时，将所述凭证数据写入第一数据库中；所述第一数据库在业务系统未处于失效转移状态时被查询；

第一写入单元204，用于在业务系统未处于失效转移状态时，将所述凭证数据写入第二数据库中；所述第二数据库在业务系统处于失效转移状态时被查询。

图7为本申请一实施例提供的事务处理装置的模块示意图。本申请实施例中，一种事务处理装置，包括：

请求接收单元301，用于接收终端发送的与该终端上登录的账户对应的事务请求；

检查单元302，用于检查业务系统是否处于失效转移状态；

查询单元303，用于在业务系统处于失效转移状态时，查询第二数据库中是否存储有与所述账户对应的凭证数据；其中，所述第二数据库在业务系统处于失效转移状态时被查询，并且所述第二数据库在业务系统不处于失效转移状态时被写入所述凭证数据，所述凭证数据是在所述终端上登录的账户进行预设互联网事务的凭证；

业务数据写入单元304，用于在所述第二数据库中查询到所述凭证数据时， 将与所述事务请求对应的业务数据写入failover数据库中；其中，所述failover数据库在业务系统处于失效转移状态时被使用。

通过上述实施例提供的事务处理装置，可以使得业务系统无论是否处于失效转移状态，都可以通过查询第一数据库或第二数据库中是否存在与账户对应的签约数据，并依据查询结果来判定当前互联网事务是否合法或安全，并在合法和安全的前提下完成账户的互联网事务。解决了现有技术无法在业务系统处于失效转移状态正常进行互联网事务的问题。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个 流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。