CN107291726A - 信息核对方法及系统 - Google Patents

Abstract

本申请实施例公开了一种信息核对方法及系统，用以对主数据库、备份数据库中存储的凭证信息进行核对及校正。所述信息核对方法包括：判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致；所述第一数据库在业务系统未处于失效转移状态时被查询，所述第二数据库在业务系统处于失效转移状态时被查询，所述凭证信息是在终端上登录的账户进行预设互联网事务的凭证；若不一致，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

Description

信息核对方法及系统

技术领域

本申请涉及数据库技术领域，特别涉及一种信息核对方法及系统。

背景技术

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

目前，失效转移模式应用于诸多场景中，如：通过计算机网络完成与终端上登录的账户对应的各种互联网事务。在该应用场景中，一般在完成上述互联网事务之前，计算机需要查询数据库中是否存在与当前账户对应的凭证信息。其中，该凭证信息作为所述账户进行上述互联网事务的凭证，一般可以在账户开户的过程中被写入到数据库中。在较早的现有技术中，上述凭证信息一般可以在账户开户的过程中被写入到上述主数据库中，这样，在业务正常时，业务系统便可以通过查询该主数据库来进行上述互联网事务。然而，由于只有主数据库中存储有与各个账户对应的凭证信息，在业务系统发生失效转移时，虽然业务系统可以切换到failover数据库进行业务数据的存储，但是因为业务系统并不能在失效转移时从上述主数据库中查询凭证信息(在查询不到凭证信息时，业务系统一般可以报告异常)，使得业务系统在失效转移时无法完成与账户对应的互联网事务。

为解决上述问题，业务系统需要将上述主数据库中存储的凭证信息备份到另外一个可以在失效转移状态时被业务系统使用的备份数据库中(该备份数据库一般并非上述failover数据库)。这样，在处于失效转移状态时，业务系统可以通过查询上述备份数据库来确保与账户对应的互联网事务的执行。为确保互联网事务的安全性，上述主数据库中存储的凭证信息与上述备份数据库中存储的凭证信息必须具备完全一致性。然而，在实际运用过程中，由于各种因素(如：备份过程的网络故障或信息写入异常)的存在，难以避免上述主数据库中存储的凭证信息与上述备份数据库中存储的凭证信息存在不一致的情况，这样，势必会影响互联网事务的安全性。

可见，目前亟待提出一种对上述主数据库、备份数据库中存储的凭证信息进行核对的技术。

发明内容

本申请实施例的目的是提供一种信息核对方法及系统，用以解决上述现有技术中存在的问题。

为解决上述问题，本申请实施例提供的信息核对方法及系统通过如下技术方案来实现：

一种信息核对方法，包括：

判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致；所述第一数据库在业务系统未处于失效转移状态时被查询，所述第二数据库在业务系统处于失效转移状态时被查询，所述凭证信息是在终端上登录的账户进行预设互联网事务的凭证；

若不一致，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

一种信息核对系统，包括：

第一判断单元，用于判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致；所述第一数据库在业务系统未处于失效转移状态时被查询，所述第二数据库在业务系统处于失效转移状态时被查询，所述凭证信息是在终端上登录的账户进行预设互联网事务的凭证；

替换单元，用于在第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息不一致时，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

由以上本申请实施例提供的技术方案可见，通过判断在第二数据库(在业务系统处于失效转移状态时被查询)中的携带预设ID的凭证信息与第一数据库(在业务系统未处于失效转移时被查询)中的携带预设ID的凭证信息是否一致，在发现上述第一、第二数据库中携带相同的预设ID的凭证信息不一致时，将上述第二数据库的携带预设ID的凭证信息替换为上述第一数据库中的携带预设ID的凭证信息，从而使得第一数据库和第二数据库中的携带相同ID的凭证信息保持一致。通过上述过程，可以避免第一数据库和第二数据库中与同一预设ID对应的凭证信息出现不一致的情况，进而确保在业务系统处于失效转移状态(第一数据库不可用)时，业务系统能够通过查询上述第二数据库，得到准确的与账户对应的凭证信息，进而确保与账户对应的互联网事务的安全性。

附图说明

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

图1为本申请实施例提供的包含主数据库和faiover数据库的业务系统的架构示意图；

图2为本申请一实施例提供的用以实现信息核对的系统架构的示意图；

图3为本申请一实施例提供的信息核对方法的流程图；

图4为本申请另一实施例提供的信息核对方法的流程图；

图5为本申请一实施例提供的信息核对系统的模块示意图；

图6为本申请另一实施例提供的信息核对系统的模块示意图。

具体实施方式

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

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

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

一般地，上述与账户对应的凭证信息被写入到上述第一数据库10中。这样在业务系统未处于失效转移状态时，第一服务器100可以通过查询上述第一数据库10中是否存在与账户对应的凭证信息，来判定与该账户对应的互联网事务是否合法或安全。然而，当业务系统处于失效转移状态时，上述第一数据库10并不能被业务系统所使用，即业务系统无法从该第一数据库10中查询到与账户对应的凭证信息，从而使得业务系统拒绝执行与账户对应的互联网事务(原因是查找不到凭证信息，而实际上，与账户对应的凭证信息已经存在于上述第一数据库10中，即当前互联网事务为合法或安全的)。为此，一般可以将上述第一数据库中的凭证信息进行备份，备份到上述第二数据库30中(下文将介绍未将凭证信息备份到上述failover数据库20中的原因)，该第二数据库30也可以是在业务系统处于失效转移状态时被业务系统查询。这样，可以确保在上述第一数据库10不可用时，业务系统可以通过查询上述第二数据库30中是否存在相应的凭证信息，进而确保业务系统在失效转移状态时能够正常运行。

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

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

本申请实施例中，第一服务器100可以在接收到终端300的确认指令后，将与账户对应的凭证信息写入上述第一数据库10中。在将凭证信息写入第一数据库10中之后，第一服务器100可以通过向第二服务器200发送携带上述凭证信息的消息，由第二服务器200在监听到上述消息后，将上述凭证信息备份到上述第二数据库30中，至此完成上述凭证信息的备份。当然，关于凭证信息的备份方式不限于上述方式。例如：可以由第一服务器同时将凭证信息写入到第一数据库和第二数据库中。另外，在上述图1中，第一服务器100和第二服务器200可以通过消息投递组件400来实现消息的传递，在其他实施例中，第一服务器100和第二服务器200之间可以直接传递消息。

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

在备份上述凭证信息的过程中，可能会因为某些因数，导致上述第一数据库10和上述第二数据库30中的凭证信息出现不一致的情况。例如：将某凭证信息写入上述第一数据库成功，但是在将该凭证信息写入上述第二数据库的过程中出现网络异常，这样就会导致不一致。在业务系统运行过程中，如果上述第一数据库10和第二数据库30中的凭证信息存在不一致，则可能导致在业务系统处于失效转移时，业务系统无法从上述第二数据库30中准确查询到与账户对应的凭证信息(例如：原本应该存在的凭证信息没有被查询到)，进而导致业务系统无法正常完成互联网事务。

鉴于上述问题，本申请将介绍一种信息核对方法，以对上述第一数据库10和上述第二数据库30中的凭证信息进行核对，并将存在不一致的凭证信息进行校正，以确保上述第一数据库和第二数据库中的凭证信息相一致。

图2为本申请一实施例提供的用以实现信息核对的系统架构的示意图。本申请实施例中，该系统架构在上述图1所示的业务系统架构的基础上，还可以包括数据仓库40，该数据仓库(Data Warehouse)40用以定期或不定期对通过抽取上述第一数据库10和上述第二数据库30中的凭证信息并进行装载，通过对抽取的信息进行比对，来找出上述第一数据库10和上述第二数据库30中的凭证信息存在差异的情况，并记录存在差异的凭证信息的ID(该ID可以是数据库为每个凭证信息设定的唯一ID)，最终形成包含所有存在差异的凭证信息的ID的文件。随后，数据仓库40将得到的文件发送给第一服务器100进行解析，第一服务器100向第二服务器200发送包含上述ID的消息，以通过该第二服务器200来校正存在差异的凭证信息(本申请实施例以第一数据库中的凭证信息为基准)。值得说明的是，图2所示的仅是本申请一示例性的系统架构，在其他可行的替代实施例中，该系统架构并不受限于此。例如，可以不设置上述数据仓库，而是通过第一服务器100来对第一、第二数据库中的信息进行核对并确定差异；或，第一服务器100发送给第二服务器200的消息可以不通过消息投递组件400发送；或，由第一服务器直接根据确定的差异对第二数据库中的凭证信息进行校正；等等。

图3为本申请一实施例提供的信息核对方法的流程(基于上述图2的系统架构)，包括如下步骤：

S101：数据仓库判断第二数据库中是否存在携带预设ID的凭证信息。若存在，则进入步骤S102；若不存在，进入步骤S103。

上述预设ID为任意一个数据库为凭证信息设定的ID，例如：0103。其中，数据仓库可以按照一定的顺序(例如：从0001～9999)逐一确定需要判断的预设ID，并判断第一数据库中是否存在携带该预设ID的凭证信息。

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

以签约场景为例，上述签约信息可以包含一个或多个参数，例如：签约协议号、账户ID、机构号(如金融机构)、状态、基金交易号、产品码等。其中，状态可以通过“0”或“1”来表示。其中，上述凭证信息的状态可以包括初始状态和成功状态。按照一般的流程，用户与金融机构的签约过程是双方签约过程，需要用户方和金融机构方分别进行签约确认的动作，其中，用户通过终端向第一服务器发送确认指令便是代表用户方的签约确认，而此时上述凭证信息虽然已经在数据库端被创建，但是由于其只是用户方的单方确认，所以其状态为初始状态(并未成功)；在创建上述初始状态的凭证信息后，一段时间内金融机构方会就上述签约过程进行签约确认(一般也可以向第一服务器发送确认指令)，此刻上述凭证信息的状态会由初始状态变更为成功状态。

在将凭证信息写入到数据库的过程中，存在一些可能导致第二数据库与第一数据库中的凭证信息不一致的因数，这些因数例如是：向第二服务器投递消息失败，或者向第二服务器投递的消息乱序；或业务操作导致签约信息的状态改变，但是并没有将第二数据库中的签约信息的状态进行变更等。

其中，若以第一数据库中的凭证信息为基准，第二数据库中的凭证信息不一致的情况主要分为如下几种：

①第一数据库中存在携带预设ID的凭证信息，在第二数据库中并没有存在携带上述预设ID该凭证信息；

②第一数据库中存在携带预设ID的凭证信息，在第二数据库中也存在携带预设ID的凭证信息，但是第二数据库中存在的该凭证信息与第一数据库存在的凭证信息的不一致(例如：凭证信息的状态不同)。举例来说，在签约的场景中，签约信息存在状态的变更，在第一数据库中存在的携带某个ID的签约信息的状态变更后，第二数据库存在的携带该ID的签约信息并没有做变更。

③第二数据库中存在携带预设ID的凭证信息，在第一数据库中并没有携带上述预设ID的凭证信息。

一般地，上述情况①和②发生的可能性可以大于上述情况③。如上所述，无论在上述第一数据库中，还是在上述第二数据库中，每个凭证信息均可以对应于一个ID。以签约信息为例，该ID可以是每个签约信息的签约号。根据上述凭证信息的ID，可以逐一找到存在于第一数据库中的但不存在于第二数据库中的凭证信息的ID(情况①)，并将该ID确定为差异ID。

S102：数据仓库判断所述第二数据库中的携带所述预设ID的凭证信息与所述第一数据库中的携带所述预设ID的凭证信息是否一致。若不一致，则进入步骤S103。若一致，表明第一数据库和第二数据库中关于该预设ID的凭证信息不存在差异，则继续进行下一个ID的凭证信息的核对。

S103：数据仓库将预设ID确定为差异ID。

如上所述，通过该步骤S102和步骤S103，可以基于上述第一、第二数据库中，找到携带相同ID的但是存在差异的凭证信息(情况②)，并将凭证信息的ID确定为差异ID。其中，数据仓库可以预先将第一数据库、第二数据库中存储的凭证信息分别进行抽取，并加载到该数据仓库中，随后，该数据仓库可以根据每个凭证信息的ID对上述第一、第二数据库中的凭证信息进行逐一比对，以确定上述差异ID。关于数据仓库技术，本文不再予以赘述。

S104：数据仓库生成包含所述差异ID的文件。

通过逐一对上述第一数据库和上述第二数据库中的凭证信息进行比对，可以得到所有存在差异的凭证信息的ID，并形成包含这些ID的文件。本申请并不对该文件的形式和类型进行限定。以签约数据为例，若通过上述判断步骤，可以确定n个存在差异的签约号(上述ID)，则形成包含这n个签约号的文件。

S105：数据仓库向上述第一服务器发送所述文件。

S106：第一服务器接收文件并对所述文件进行解析，得到所述差异ID。

本申请实施例中，在解析的过程中，可以考虑到各种异常数据，如：签约号格式不符合要求，签约号为空，文件为空，等等。对于上述异常数据，可以在解析过程中忽略该异常数据对应的差异ID，将正常数据对应的差异ID全部解析出来，这样，由于文件中含有多条签约信息，即使其中一个或多个差异ID解析错误，也不会影响其它差异ID的解析。

S107：第一服务器逐一生成携带上述差异ID的消息。

其中，若上述文件中包含的差异ID的个数n，则逐一生成n条携带单个差异ID的消息。当然，在其他可行的实施例中，生成的消息中可以包含两个或两个以上的差异ID。

S108：第一服务器将所述携带每个差异ID的消息逐一向监听服务器(即上述第二服务器)发送。

本申请实施例中，一般地，第一服务器可以是业务系统的核心，其需要进行凭证信息的查询、互联网事务的业务数据的存储和变更及失效转移的控制等事务，本身该第一服务器的负荷较大，为减小第一服务器的负荷，一般可以通过上述监听服务器(后督系统)来执行将上述凭证信息写入到第二数据库、或对第二数据库中存储的凭证信息进行替换的操作。

本申请实施例中，第一服务器向上述监听服务器发送的消息可以是事务型消息。如上图2所述，可以通过消息投递组件400将来自于第一服务器100的事务型消息投递到第二服务器200上。所述事务型消息是指：当投递方发出消息后需要获取监听方的回执消息，并根据回执消息的内容，确定是否需要向监听方再次发送上述事务型消息。其中，上述投递方可以为第一服务器，上述监听方可以为第二服务器。若发送的是事务型消息，能够确保第一服务器(投递方)发送的消息被第二服务器(订阅方)接收，并由该第二服务器将凭证信息写入到第二数据库中。其中，所述消息投递组件400可以用以配置与所述第一服务器100发送的事务型消息对应的第一类型标识及与所述第二服务器200接收的事务型消息对应的第二类型标识，所述第一类型标识与所述第二类型标识一致。其中，上述第一、第二类型标识可以是能够被唯一定位消息来源的标识：Topic/EventCode，主要用以区分各种消息的类型，以避免被其他消息来源所干扰。其中，Topic可以代表一个消息的大类，EventCode可以代表一个消息的子类。

本申请实施例中，在向监听服务器发送携带所述预设ID的事务型消息之后，所述方法还可以包括如下步骤：

在接收到来自于监听服务器的表示信息写入失败、或信息替换失败的回执消息时，向监听服务器重新发送所述事务型消息。

在接收到来自于第二服务器的表示信息写入成功、或信息替换成功的回执消息时，停止向监听服务器发送所述事务型消息。

其中，针对上述情况①，若监听服务器将携带预设ID的凭证信息成功写入到第二数据库中，可以向第一服务器返回表示信息写入成功的回执消息。反之，若监听服务器写入信息失败，则可以向第一服务器返回表示信息写入失败的回执消息。这样，第一服务器在收到上述表示信息写入失败的回执消息之后，会重新向上述监听服务器发送上述事务型消息(以使监听服务器重新执行信息写入动作)，直至收到表示信息写入成功的回执消息，通过上述事务型消息，可以确保凭证信息能够被成功写入第二数据库中。

同理，针对上述情况②，上述回执消息可以分为表示信息替换失败的回执消息，以及表示信息替换失败的回执消息。第一服务器在收到上述表示信息替换失败的回执消息之后，会重新向上述监听服务器发送上述事务型消息(以使监听服务器重新执行信息变更动作)，直至收到表示信息替换成功的回执消息，通过上述事务型消息，可以确保第二数据库中错误的凭证信息能够被成功替换。

本申请实施例中，第一服务器可以向消息投递组件发送携带所述预设ID的事务型消息；其中，所述消息投递组件用以将来自于第一服务器的事务型消息向监听服务器发送，直至该消息投递组件接收到来自于监听服务器的表示信息写入成功或信息替换成功的回执消息。

其中，第一服务器100将上述消息发送给消息投递组件400，当消息被消息投递组件400成功接收到之后，第一服务器100便不需要关心后续消息能不能成功被第二服务器200监听到，并由第二服务器200将相应的凭证信息写入(或变更)到第二数据库中。也就是，通过该消息投递组件400可以确保差异ID对应的凭证信息被成功写入或替换到上述第二数据库中。

S109：第二服务器(监听服务器)在监听到上述消息时，将第一数据库中的携带上述预设ID的凭证信息写入第二数据库中(对应于上述情况①)；或将所述第二数据库中的携带预设ID的凭证信息替换为上述第一数据库中的携带该预设ID的凭证信息(对应于上述情况②)。

在该步骤S109中，可以通过第二服务器监听消息(如事务型消息)的方式来执行差异修正动作。如前所述，对于上述情况①，可以通过从第一数据库(主数据库)读取该差异ID对应的凭证信息，并写入到上述第二数据库(备份数据库)中。对于上述情况②，可以通过从第一数据库读取该差异ID对应的凭证信息，将原本存在于第二数据库中的与该差异ID对应的凭证信息进行删除，再将从第一数据库读取该差异ID对应的凭证信息写入到第二数据库中。

对于上述情况③，所述方法还包括如下步骤：若第二数据库中存在携带预设ID的凭证信息，判断第一数据库中是否存在携带该预设ID的凭证信息；若不存在，将第二数据库中存在的携带该预设ID的凭证信息进行删除。

至此，完成对凭证信息的核对及信息修正，从而确保第二数据库中的携带预设ID的凭证信息与第一数据库中的携带预设ID的凭证信息的一致性。

本申请实施例中，所述第一数据库为Oracle数据库，所述第二数据库为MySQL数据库。其中，第一数据库由于是主数据库，存储有业务数据和凭证信息，采用Oracle数据库可以使得数据的安全性更高。MySQL数据库相较于Oracle数据库，成本较低，由于上述第二数据库只是在业务系统发生失效转移时才会使用，并且该第二数据库中只是存储静态的凭证信息，故采取MySQL数据库更为合适。本申请实施例中，在将上述凭证信息写入上述第一数据库和第二数据库中后，还可以将上述凭证信息存放于缓存中(可以保存一段预设时间)，这样，在后续查询凭证信息的过程中，第一服务器可以优先通过查询缓存来获取相应的凭证信息，如果缓存中没有，再去查询第一数据库或第二数据库。

值得提及的是，本申请还包括多种可行的替代实施例。举例而言，通过第一服务器确定上述差异ID并对差异ID对应的凭证信息进行替换或写入。抑或，不通过发送事务型消息的方式进行第二数据库中存在差异的凭证信息的替换或写入，而是通过第一服务器直接执行对第二数据库中存在差异的凭证信息的替换或写入动作。抑或，可以不生成包含一个或多个差异ID的上述文件，而是在确定每个差异ID后，便随即执行与该差异ID对应的信息写入或替换动作；等等。本文不一一列举。

由以上本申请实施例提供的技术方案可见，通过判断在第二数据库(在业务系统处于失效转移状态时被查询)中的携带预设ID的凭证信息与第一数据库(在业务系统未处于失效转移时被查询)中的携带预设ID的凭证信息是否一致，在发现上述第一、第二数据库中携带相同的预设ID的凭证信息不一致时，将上述第二数据库的携带预设ID的凭证信息替换为上述第一数据库中的携带预设ID的凭证信息，从而使得第一数据库和第二数据库中的携带相同ID的凭证信息保持一致。通过上述过程，可以避免第一数据库和第二数据库中与同一预设ID对应的凭证信息出现不一致的情况，进而确保在业务系统处于失效转移状态(第一数据库不可用)时，业务系统能够通过查询上述第二数据库，得到准确的与账户对应的凭证信息，进而确保与账户对应的互联网事务的安全性。

图4为本申请一实施例提供的信息核对方法的流程。值得述及的是，图4所示的信息核对方法的执行主体可以是上述第一服务器、或数据仓库、或包含上述第一服务器和上述数据仓库的系统，本申请并不作限制。在本申请实施例中，该信息核对方法可以包括如下步骤：

S201：判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致；所述第一数据库在业务系统未处于失效转移状态时被查询，所述第二数据库在业务系统处于失效转移状态时被查询，所述凭证信息是在终端上登录的账户进行预设互联网事务的凭证。

如前所述，在步骤S201中，可以逐一针对第一数据库和第二数据库中存储的携带相同预设ID的凭证信息进行核对(所述核对即判断携带相同ID的凭证信息是否一致)。例如，假设第一数据库和第二数据库中分别存在预设ID：000～999的1000个凭证信息，那么在信息核对的过程中，按照预设ID依次进行核对，即从预设ID：000开始进行核对，预设ID：000核对完之后，开始核对预设ID：001，以此类推。

S202：若不一致，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

如前所述，在信息核对的过程中，若发现第一、第二数据库中携带相同的预设ID的凭证信息不一致，则可以将第一数据库中的携带预设ID的凭证信息为基准，将第二数据库中的携带该预设ID的凭证信息替换成上述第一数据库中的携带预设ID的凭证信息，从而确保两个数据库中携带相同预设ID的凭证信息一致。

如前所述，为应对上述情况①，在本申请实施例中，在上述步骤S201之前，所述方法还可以包括：

判断第二数据库中是否存在携带预设ID(例如：000)的凭证信息。其中，一般在第一数据库中可以存在携带该预设ID的凭证信息。

若第二数据库中存在携带预设ID的凭证信息，进入步骤S201。

若第二数据库中不存在携带预设ID的凭证信息，将第一数据库中的携带所述预设ID的凭证信息写入第二数据库中。如上所述，可以通过发送事务型消息的方式写入该凭证信息，以确保第一、第二数据库中凭证信息的一致性。

本实施例中，通过上述信息核对方法，可以避免第一数据库和第二数据库中与预设ID的对应的凭证信息存在不一致的情况，进而确保在业务系统处于失效转移状态(第一数据库不可用)时，业务系统能够通过查询上述第二数据库，得到准确的与账户对应的凭证信息，进而确保与账户对应的互联网事务的安全性。

在利用签约信息进行资金类交易的场景中，通过上述信息核对方法，可以确保在业务系统处于失效转移状态(第一数据库不可用)时，业务系统能够通过查询上述第二数据库(备库)，得到与第一数据库(主库)一致的签约信息，进而确保与账户对应的资金类交易事务(资金转入、转出等)的安全性。

与上述方法的流程相对应，本申请实施例还提供了一种信息核对系统。该系统可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为逻辑意义上的装置，是通过服务器的CPU(Central Process Unit，中央处理器)将对应的计算机程序指令读取到内存中运行形成的。接下来，将基于上述各方法实施例的内容，介绍一种信息核对系统。

图5为本申请一实施例中信息核对系统的模块示意图。本实施例中，该系统中各单元的功能可以与上述信息核对方法的各步骤中的功能对应，具体内容可以参照上述方法实施例。所述信息核对系统包括：

第一判断单元101，用于判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致；所述第一数据库在业务系统未处于失效转移状态时被查询，所述第二数据库在业务系统处于失效转移状态时被查询，所述凭证信息是在终端上登录的账户进行预设互联网事务的凭证；

替换单元102，用于在第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息不一致时，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

本申请一实施例中，上述系统还可以包括：

第二判断单元，用于判断第二数据库中是否存在携带预设ID的凭证信息。

则所述第一判断单元101具体用于：

若第二数据库中存在携带预设ID的凭证信息，判断所述第二数据库中的携带所述预设ID的凭证信息与所述第一数据库中的携带所述预设ID的凭证信息是否一致。

则所述系统还包括：

写入单元，用于在第二数据库中不存在携带预设ID的凭证信息时，将第一数据库中的携带所述预设ID的凭证信息写入第二数据库中。

本申请实施例中，通过上述信息核对系统，可以找出上述第二数据库与上述第一数据库中的凭证信息存在差异的情况，并且，一般以第一数据库中的凭证信息为准，对第二数据库中存在差异的凭证信息进行修正(重新写入或替换)。本申请实施例通过上述信息核对系统，可以确保在业务系统处于失效转移状态时，业务系统能够通过查询上述第二数据库，得到与第一数据库一致的凭证信息，进而确保与账户对应的互联网事务的安全性。

图6为本申请另一实施例中信息核对系统的模块示意图。本实施例中，该系统中各单元的功能可以与上述信息核对方法的各步骤中的功能对应，具体内容可以参照上述方法实施例。所述信息核对系统可以包括第一判断单元201、第二判断单元202、差异ID确定单元203、文件生成单元204、文件解析单元205、消息生成单元206、消息发送单元207、消息监听单元208、写入单元209及替换单元210。其中，本实施例中，所述第一判断单元201、第二判断单元202、差异ID确定单元203、文件生成单元204可以是上述数据仓库40所包含的功能单元，所述文件解析单元205、消息生成单元206、消息发送单元207可以是上述第一服务器100所包含的功能单元，所述消息监听单元208、写入单元209及替换单元210可以是上述第二服务器200所包含的功能单元。

其中，所述第一判断单元201用于判断第二数据库中是否存在携带预设ID的凭证信息；所述第二数据库在业务系统处于失效转移状态时被查询。

所述写入单元209用于在所述第二数据库中不存在携带所述预设ID的凭证信息时，将第一数据库中的携带所述预设ID的凭证信息写入所述第二数据库中；所述第一数据库在业务系统未处于失效转移状态时被查询。

所述第二判断单元202用于在所述第二数据库中存在携带所述预设ID的凭证信息时，判断所述第二数据库中的携带所述预设ID的凭证信息与所述第一数据库中的携带所述预设ID的凭证信息是否一致。

所述替换单元210用于在所述第二数据库中的携带所述预设ID的凭证信息与所述第一数据库中的携带所述预设ID的凭证信息不一致时，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

所述消息发送单元208用于在第二数据库中不存在携带所述预设ID的凭证信息时，向监听服务器发送携带所述预设ID的消息；其中，所述监听服务器用以在监听到携带所述预设ID的消息后，将第一数据库中存在的携带所述预设ID的凭证信息写入所述第二数据库中。

上述消息发送单元208还用于：

在所述第二数据库中存在的携带所述预设ID的凭证信息与所述第一数据库中存在的携带所述预设ID的凭证信息不一致时，向监听服务器发送携带所述预设ID的消息；其中，所述监听服务器用以在监听到携带所述预设ID的消息后，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

所述差异ID确定单元203用于在所述第二数据库中不存在携带预设ID的凭证信息时，或在所述第二数据库中存在的携带所述预设ID的凭证信息与所述第一数据库中存在的携带所述预设ID的凭证信息不一致时，将所述预设ID确定为差异ID。

所述文件生成单元204用于生成包含所述差异ID的文件。

所述文件解析单元205用于对生成的所述文件进行解析，获得所述文件包含的差异ID。

所述消息生成单元206用于逐一生成携带每个差异ID的消息。

本申请实施例中，通过上述信息核对系统，可以找出上述第二数据库与上述第一数据库中的凭证信息存在差异的情况，并且，一般以第一数据库中的凭证信息为准，对第二数据库中存在差异的凭证信息进行修正(重新写入或替换)。本申请实施例通过上述信息核对系统，可以确保在业务系统处于失效转移状态时，业务系统能够通过查询上述第二数据库，得到与第一数据库一致的凭证信息，进而确保与账户对应的互联网事务的安全性。

本申请实施例中，所述消息发送单元207可以具体用于向监听服务器逐一发送携带每个差异ID的消息。

本申请实施例中，所述消息发送单元207具体用于向监听服务器发送携带所述预设ID的事务型消息。

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

通过消息投递组件向监听服务器发送携带所述预设ID的事务型消息。如上所述，通过发送事务型消息，可以确保差异ID对应的凭证信息能够被写入到第二数据库中，或第二数据库中原先存在的错误凭证信息能够被修正。

本申请实施例中，所述系统还可以包括：

第三判断单元，用于在第二数据库中存在携带预设ID的凭证信息时，判断第一数据库中是否存在携带该预设ID的凭证信息；

删除单元，用于在第一数据库中不存在携带预设ID的凭证信息时，将第二数据库中存在的携带该预设ID的凭证信息进行删除。

通过上述第三判断单元和删除单元，可以针对上述情况③进行凭证信息的修正。

同样地，本申请的系统还包括多种可行的替代实施例。举例而言，省去上述文件解析单元205、消息生成单元206、消息发送单元207、消息监听单元208，通过第一服务器确定上述差异ID并对差异ID对应的凭证信息进行替换或写入(第一服务器100包含写入单元209和替代单元210)；不通过发送事务型消息的方式进行第二数据库中存在差异的凭证信息的替换或写入，而是通过第一服务器直接执行对第二数据库中存在差异的凭证信息的替换或写入动作；可以不生成包含一个或多个差异ID的上述文件(省去上述差异ID确定单元203和文件生成单元204)，而是在确定每个差异ID后，随即执行与该差异ID对应的信息写入或替换动作；等等。本文不一一列举。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (12)

1.一种信息核对方法，其特征在于，包括：

判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致；所述第一数据库在业务系统未处于失效转移状态时被查询，所述第二数据库在业务系统处于失效转移状态时被查询，所述凭证信息是在终端上登录的账户进行预设互联网事务的凭证；

若不一致，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

2.如权利要求1所述的方法，其特征在于，在判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致之前，所述方法还包括：

判断第二数据库中是否存在携带预设ID的凭证信息；

则判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致，具体包括：

若第二数据库中存在携带预设ID的凭证信息，判断所述第二数据库中的携带所述预设ID的凭证信息与所述第一数据库中的携带所述预设ID的凭证信息是否一致。

3.如权利要求2所述的方法，其特征在于，判断第二数据库中是否存在携带预设ID的凭证信息之后，所述方法还包括：

若第二数据库中不存在携带预设ID的凭证信息，将第一数据库中的携带所述预设ID的凭证信息写入第二数据库中。

4.如权利要求1所述的方法，其特征在于，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息，具体包括：

向监听服务器发送携带所述预设ID的事务型消息；其中，所述监听服务器用以在监听到所述事务型消息后，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息；

则向监听服务器发送携带所述预设ID的事务型消息之后，所述方法还包括：

在接收到来自于监听服务器的表示信息替换失败的回执消息时，向监听服务器重新发送所述事务型消息；

在接收到来自于监听服务器的表示信息替换成功的回执消息时，停止向监听服务器发送所述事务型消息。

5.如权利要求4所述的方法，其特征在于，在判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致之后，所述方法还包括：

若所述第二数据库中的携带预设ID的凭证信息与所述第一数据库中的携带预设ID的凭证信息不一致，将所述预设ID确定为差异ID；

生成包含所述差异ID的文件；

则向监听服务器发送携带所述预设ID的事务型消息之前，所述方法还包括：

对生成的所述文件进行解析，获得所述文件包含的差异ID；

逐一生成携带所述差异ID的事务型消息。

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

若第二数据库中存在携带预设ID的凭证信息，判断第一数据库中是否存在携带该预设ID的凭证信息；

若不存在，将第二数据库中存在的携带该预设ID的凭证信息进行删除。

7.一种信息核对系统，其特征在于，包括：

第一判断单元，用于判断第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息是否一致；所述第一数据库在业务系统未处于失效转移状态时被查询，所述第二数据库在业务系统处于失效转移状态时被查询，所述凭证信息是在终端上登录的账户进行预设互联网事务的凭证；

替换单元，用于在第一数据库中的携带预设ID的凭证信息与第二数据库中的携带预设ID的凭证信息不一致时，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息。

8.如权利要求7所述的系统，其特征在于，所述系统还包括：

第二判断单元，用于判断第二数据库中是否存在携带预设ID的凭证信息；

则所述第一判断单元具体用于：

若第二数据库中存在携带预设ID的凭证信息，判断所述第二数据库中的携带所述预设ID的凭证信息与所述第一数据库中的携带所述预设ID的凭证信息是否一致。

9.如权利要求8所述的系统，其特征在于，所述系统还包括：

写入单元，用于在第二数据库中不存在携带预设ID的凭证信息时，将第一数据库中的携带所述预设ID的凭证信息写入第二数据库中。

10.如权利要求7所述的系统，其特征在于，所述替换单元具体用于：

向监听服务器发送携带所述预设ID的事务型消息；其中，所述监听服务器用以在监听到所述事务型消息后，将所述第二数据库中的携带所述预设ID的凭证信息替换为所述第一数据库中的携带所述预设ID的凭证信息；

则所述系统还用于：

在接收到来自于监听服务器的表示信息替换失败的回执消息时，向监听服务器重新发送所述事务型消息；

在接收到来自于监听服务器的表示信息替换成功的回执消息时，停止向监听服务器发送所述事务型消息。

11.如权利要求10所述的系统，其特征在于，所述系统还包括：

差异ID确定单元，用于在所述第二数据库中的携带预设ID的凭证信息与所述第一数据库中的携带预设ID的凭证信息不一致时，将所述预设ID确定为差异ID；

文件生成单元，用于生成包含所述差异ID的文件；

文件解析单元，用于对生成的所述文件进行解析，获得所述文件包含的差异ID；

消息生成单元，用于逐一生成携带所述差异ID的事务型消息。

12.如权利要求7所述的系统，其特征在于，所述系统还包括：

第三判断单元，用于在第二数据库中存在携带预设ID的凭证信息时，判断第一数据库中是否存在携带该预设ID的凭证信息；

删除单元，用于在第一数据库中不存在携带该预设ID的凭证信息时，将第二数据库中存在的携带该预设ID的凭证信息进行删除。