CN110765091B - 对账方法和系统 - Google Patents

Abstract

本申请涉及大数据技术领域，提供了一种对账方法和系统。其中的方法包括：业务系统服务器将增量业务数据发送至分布式数据库服务器；分布式数据库服务器将接收到的增量业务数据存储至分布式数据库的分布式存储节点；数据处理服务器轮询分布式存储节点并通过调用预先封装的数据处理层从分布式存储节点中获取增量业务数据并发送至分布式消息队列服务器；支付系统服务器将增量支付数据发送至分布式消息队列服务器；对账系统服务器在监听到当前流处理窗口内分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，获取该目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

Description

对账方法和系统

技术领域

本申请涉及计算机技术领域，特别是涉及一种对账方法和系统。

背景技术

随着互联网的迅速发展，越来越多的人在理财平台上进行理财，例如购买基金、股票等，由于涉及到金钱交易，理财平台的后台经常要进行资金对账。

传统技术中，通常都是通过T+1的方式批处理对业务系统及支付系统的数据进行对账，对账时效性差，无法及时发现各个系统之间的数据不一致问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够及时发现各个系统之间的数据不一致问题的对账方法和系统。

一种对账方法，包括：

业务系统服务器实时扫描业务系统数据库的第一日志文件，对所述第一日志文件进行解析，得到增量业务数据，将所述增量业务数据发送至分布式数据库服务器；

所述分布式数据库服务器将接收到的所述增量业务数据存储至分布式数据库的分布式存储节点；

数据处理服务器轮询所述分布式存储节点并通过调用预先封装的数据处理层从所述分布式存储节点中获取增量业务数据，将获取到的所述增量业务数据发送至分布式消息队列服务器；其中，所述数据处理层根据预设的数据处理逻辑进行封装得到；

支付系统服务器实时扫描支付系统数据库的第二日志文件，对所述第二日志文件进行解析，得到增量支付数据，将所述增量支付数据发送至所述分布式消息队列服务器；

对账系统服务器监听当前流处理窗口内所述分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从所述分布式消息队列服务器中获取所述目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

在其中一个实施例中，所述数据处理服务器轮询所述分布式存储节点并通过调用预先封装的数据处理层从所述分布式存储节点中获取增量业务数据，将获取到的所述增量业务数据发送至分布式消息队列服务器，包括：

所述数据处理服务器获取预先创建的主键信息表；所述主键信息表用于存储从分布式存储节点中抽取并且成功发送至分布式消息队列的增量业务数据的主键；

所述数据处理服务器将所述主键信息表中的主键与所述分布式存储节点中的目标数据表的主键进行比对，将比对不一致的主键确定为第一目标主键；

所述数据处理服务器从所述分布式存储节点中抽取与所述第一目标主键对应的增量业务数据，对抽取的增量业务数据进行清洗和转换，并发送至所述分布式消息队列服务器中；

所述数据处理服务器获取发送成功的增量业务数据对应的第二目标主键，将所述第二目标主键回写至所述主键信息表中，以对所述主键信息表进行更新。

在其中一个实施例中，所述从所述分布式消息队列服务器中获取所述目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作，包括：

所述对账系统服务器获取目标业务数据表对应的唯一键配置信息，所述唯一键配置信息中包括至少一个目标字段；

所述对账系统服务器将所述目标增量业务数据中所述目标字段对应的字段值与对账数据库中所述目标字段对应的字段值进行比对；

当存在比对一致的字段值时，所述对账系统服务器将比对一致的字段值对应的数据从所述目标增量业务数据中过滤掉，将剩下的目标增量业务数据加载至所述对账数据库中；

当不存在比对一致的字段值时，所述对账系统服务器将所有目标增量业务数据加载至所述对账数据库中。

在其中一个实施例中，所述方法还包括：

所述数据处理服务器获取目标配置文件；

所述数据处理服务器对所述目标配置文件进行解析，得到可执行代码文件；

所述数据处理服务器根据所述可执行代码文件更新所述预先封装的数据处理层。

在其中一个实施例中，当所述当前对账类型为预设对账类型时，所述按照当前对账类型对应的预设对账逻辑执行对账操作，包括：

对账系统服务器将获取的所述目标增量业务数据及目标增量支付数据分别保存在内存中的两个临时数据表中；

对账系统服务器将两个临时数据表进行关联操作，对关联成功的目标增量业务数据及目标增量支付数据进行核对，若核对成功，则判定为对账成功；若核对不成功，则判定为对账失败。

在其中一个实施例中，所述按照当前对账类型对应的预设对账逻辑执行对账操作，还包括：

对账系统服务器在所述对账数据库中对对账失败的目标增量业务数据及目标增量支付数据设置预设状态标记；所述预设状态标记为用于表征对账失败的对账状态；

对账系统服务器按照预设时间间隔扫描所述对账数据库，获取所述对账数据库中所述预设状态标记对应的目标增量业务数据及目标增量支付数据，根据所述预设状态标记对应的目标增量业务数据及目标增量支付数据再次执行对账操作。

在其中一个实施例中，所述方法还包括：

对账系统服务器对对账数据库中数据的对账状态进行监控，当监控到对账状态为预设状态的持续时间超过预设阈值的数据时，生成警告信息并发送至运维终端，所述预设状态包括未对账和对账失败。

一种对账系统，所述系统包括业务系统服务器、分布式数据库服务器、数据处理服务器、支付系统服务器及对账系统服务器；其中：

业务系统服务器用于实时扫描业务系统数据库的第一日志文件，对所述第一日志文件进行解析，得到增量业务数据，将所述增量业务数据发送至分布式数据库服务器；

所述分布式数据库服务器用于将接收到的所述增量业务数据存储至分布式数据库的分布式存储节点；

数据处理服务器用于轮询所述分布式存储节点并通过调用预先封装的数据处理层从所述分布式存储节点中获取增量业务数据，将获取到的所述增量业务数据发送至分布式消息队列服务器；其中，所述数据处理层根据预设的数据处理逻辑进行封装得到；

支付系统服务器用于实时扫描支付系统数据库的第二日志文件，对所述第二日志文件进行解析，得到增量支付数据，将所述增量支付数据发送至所述分布式消息队列服务器；

对账系统服务器用于监听当前流处理窗口内所述分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从所述分布式消息队列服务器中获取所述目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

在其中一个实施例中，所述数据处理服务器还用于获取预先创建的主键信息表；所述主键信息表用于存储从分布式存储节点中抽取并且成功发送至分布式消息队列的增量业务数据的主键；将所述主键信息表中的主键与所述分布式存储节点中的目标数据表的主键进行比对，将比对不一致的主键确定为第一目标主键；从所述分布式存储节点中抽取与所述第一目标主键对应的增量业务数据，对抽取的增量业务数据进行清洗和转换，并发送至所述分布式消息队列服务器中；获取发送成功的增量业务数据对应的第二目标主键，将所述第二目标主键回写至所述主键信息表中，以对所述主键信息表进行更新。

在其中一个实施例中，所述对账系统服务器还用于获取目标业务数据表对应的唯一键配置信息，所述唯一键配置信息中包括至少一个目标字段；将所述目标增量业务数据中所述目标字段对应的字段值与对账数据库中所述目标字段对应的字段值进行比对；当存在比对一致的字段值时，将比对一致的字段值对应的数据从所述目标增量业务数据中过滤掉，将剩下的目标增量业务数据加载至所述对账数据库中；当不存在比对一致的字段值时，将所有目标增量业务数据加载至所述对账数据库中。

上述对账方法和系统，由于业务系统服务器以及支付系统服务器都是实时扫描数据库日志，当有增量数据写入时，能够实时发送到分布式消息队列服务器，并且对账系统服务器通过流处理地方式从分布式消息队列服务器中获取数据进行对账，从而实现了对账实时化，能够及时发现对账不一致的问题，减少资金损失。进一步，由于将与上游业务系统相关的数据处理逻辑封装在数据处理层，并通过分布式消息队列与对账逻辑隔离，使得对账逻辑与上游业务逻辑松耦合，保证了对账逻辑的一致性，在各个业务场景下可以通用一套对账逻辑，不需要重复开发，大大降低了开发成本。

附图说明

图1为一个实施例中对账方法的应用场景图；

图2为一个实施例中对账方法的流程示意图；

图3为一个实施例中步骤206的流程示意图；

图4为一个实施例中执行对账操作的流程示意图；

图5为一个实施例中对账系统的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的对账方法，可以应用于如图1所示的应用环境中。在该应用环境中，对账方法应用于如图1所示的对账系统中，该对账系统包括业务系统服务器102、分布式数据库服务器104、数据处理服务器106、支付系统服务器108、分布式消息队列服务器110及对账系统服务器112。其中，业务系统服务器可以从业务数据库获取增量业务数据，并发送至分布式数据库服务器，分布式数据库服务器可以将增量业务数据存储至分布式数据库各分布式存储节点中，数据处理服务器轮询分布式存储节点并通过调用预先封装的数据处理层从分布式存储节点中获取增量业务数据，将获取到的增量业务数据发送至分布式消息队列服务器，支付系统服务器可以从支付系统数据库中获取增量支付数据并发送至分布式消息队列服务器，最后对账系统服务器监听当前流处理窗口内分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从分布式消息队列服务器中获取目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

其中，图1中各个服务器可以通过网络进行通信，图1中各个服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种对账方法，包括以下步骤：

步骤202，业务系统服务器实时扫描业务系统数据库的第一日志文件，对第一日志文件进行解析，得到增量业务数据，将增量业务数据发送至分布式数据库服务器。

具体地，业务系统服务器指的是业务系统对应的服务器，业务系统服务器上设置有业务系统数据库，业务系统数据库用于存储各涉及金钱交易的业务场景下的业务数据，例如可以是基金交易数据、股票交易数据等。业务系统服务器可以为一个或多个，不同的业务系统对应不同的业务系统服务器。

第一日志文件指的是业务系统数据库发生增量数据变化时产生的日志文件，通过解析第一日志文件，可以得到增量业务数据。增量业务数据指的是业务系统数据库中当前增加的业务数据记录，增量业务数据可以是一条数据记录或者多条数据记录。在一个实施例中，增量业务数据中包括订单编号、交易金额、收款方、付款方、交易时间等字段。

业务系统服务器在得到增量业务数据后，将增量业务数据发送至分布式数据库服务器。由于业务系统服务器是实时扫描第一日志文件的，因此，业务系统数据库的数据可以实时同步到分布式数据库服务器中。

步骤204，分布式数据库服务器将接收到的增量业务数据存储至分布式数据库的分布式存储节点。

其中，分布式数据库服务器指的是设置了分布式数据库的服务器。

具体地，分布式数据库服务器在接收到业务系统服务器发送的增量业务数据后，可以将增量业务数据存储至分布式数据库的分布式存储节点，通过将上游的业务系统数据库的数据实时同步到分布式数据库中，一方面后续抽取数据进行对账时，无需入侵上游业务系统数据库，可以避免上游业务数据库的数据库结构；另一方面，当上游系统存在多个业务系统数据库时，通过将数据实时同步到分布式数据库，后续在抽取数据时，可以统一进行抽取，提高对账效率。

步骤206，数据处理服务器轮询分布式存储节点并通过调用预先封装的数据处理层从分布式存储节点中获取增量业务数据，将获取到的增量业务数据发送至分布式消息队列服务器。

其中，数据处理服务器指的是用于调用预先封装的数据处理层以执行数据处理操作的服务器，数据处理层根据预设的数据处理逻辑进行封装得到，数据处理逻辑指的是对分布式数据库中的数据进行处理的程序逻辑。在一个实施例中，数据处理逻辑包括ETL（Extract-Transform-Load）逻辑，即数据清洗、抽取及转换逻辑。抽取指的是从分布式数据库中导出数据，清洗指的是过滤掉不符合要求的数据，包括不完整的数据、错误的数据、重复的数据；转换包括数据格式、数据粒度等维度的转换，以及一些商务规则的计算。可以理解的是，数据处理逻辑是对业务系统的数据进行处理，因此，数据处理逻辑与业务系统服务器的实现细节相关，在不同的业务场景下，需要配置不同的数据处理逻辑。

具体地，数据处理服务器可以按照预设的时间间隔不断轮询分布式存储节点，当查询到任意一个分布式存储节点存在增量业务数据时，调用预先封装的数据处理层从该分布式节点中抽取增量业务数据，对抽取的增量业务数据进行清洗换等数据处理操作，然后发送至分布式消息队列服务器。分布式消息队列服务器指的是设置了分布式消息队列的服务器。其中，预设的时间间隔可根据需要进行设定，预设时间间隔越小，数据处理服务器从分布式存储节点中获取数据的时效性越好，对账的时效性也越好，因此，为确保能够准实时对账，通常将预设的时间间隔设置为一个比较小的时间间隔，例如设置为3分钟或5分钟。

进一步，分布式消息队列服务器在存储增量业务数据时，可根据每条数据中的业务类型标识确定对应的消息类型（topic），将数据存储至该消息类型对应的消息队列中，每一个消息类型对应一个对账类型，对账类型例如可以包括一对一对账及一对二对账，一对一对账的业务类型例如是购买基金、股票等业务，对账系统服务器从分布式消息队列中获取数据时，可以根据topic来确定当前对账类型，并按照当前对账类型对应的预设对账逻辑执行对账操作。

步骤208，支付系统服务器实时扫描支付系统数据库的第二日志文件，对第二日志文件进行解析，得到增量支付数据，将增量支付数据发送至分布式消息队列服务器。

其中，支付系统服务器上设置了支付系统数据库，支付系统数据库用于存储支付数据。增量支付数据指的是支付系统数据库中当前增加的支付数据记录，增量支付数据可以是一条数据记录或者多条数据记录。在一个实施例中，增量支付数据中包括订单编号、交易金额、收款方、付款方、交易时间等字段。

在一个实施例中，由于支付系统数据库中并不是所有的增量支付数据都需要进行对账,因此需要对支付系统数据库中的增量支付数据进行过滤，具体可以通过以下方式进行过滤：首先将增量支付数据发送至一个消息中间件进行缓存（该消息中间件例如可以是kafka分布式消息队列），然后通过一个过滤服务器按照预设的时间间隔从该消息中间件中获取增量支付数据，对获取的增量支付数据进行过滤，然后发送至分布式消息队列服务器。在进行过滤时，可以设置过滤规则，比如，可以过滤掉包含预设字段的数据，例如包含“冻结”字段的数据；再比如，可以过滤掉业务类型标识与预设的业务类型标识不一致的数据。

步骤210，对账系统服务器监听当前流处理窗口内分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从分布式消息队列服务器中获取目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

其中，对账系统服务器上设置有对账数据库，对账数据库中用于存储需要进行对账的增量业务数据及增量支付数据。流处理窗口指的是流处理技术对应的时间窗口，也即通过流处理技术处理数据的时间间隔，该时间间隔可以根据需要进行设定，在一个实施例中，可以设定该时间间隔为30分钟。

本实施例中，对账系统服务器采用流处理技术进行对账，具体来说，在每一个流处理窗口内，对账系统服务器监听分布式消息队列服务器在当前流处理窗口内接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从分布式消息队列服务器中获取目标增量业务数据和目标增量支付数据，并根据获取的数据的消息类型确定当前对账类型，按照当前对账类型对应的预设对账逻辑执行对账操作。

上述对账方法中，由于业务系统服务器以及支付系统服务器都是实时扫描数据库日志，当有增量数据写入时，能够实时发送到分布式消息队列服务器，并且对账系统服务器通过流处理地方式从分布式消息队列服务器中获取数据进行对账，从而实现了对账实时化，能够及时发现对账不一致的问题，减少资金损失。

进一步，由于将与上游业务系统相关的数据处理逻辑封装在数据处理层，并通过分布式消息队列与对账逻辑隔离，使得对账逻辑与上游业务逻辑松耦合，保证了对账逻辑的一致性，在各个业务场景下可以通用一套对账逻辑，不需要重复开发，大大降低了开发成本。

在一个实施例中，如图3所示，上述步骤206 中数据处理服务器轮询分布式存储节点并通过调用预先封装的数据处理层从分布式存储节点中获取增量业务数据，将获取到的增量业务数据发送至分布式消息队列服务器，包括：

步骤206A，数据处理服务器获取预先创建的主键信息表。

其中，主键信息表用于存储从分布式存储节点中抽取并且成功发送至分布式消息队列的增量业务数据的主键。

本实施例中，预先在分布式数据库中创建主键信息表，数据处理服务器在从分布式数据库中抽取数据时，首先需要从分布式数据库中获取主键信息表。

步骤206B，数据处理服务器将主键信息表中的主键与分布式存储节点中的目标数据表的主键进行比对，将比对不一致的主键确定为第一目标主键。

其中，分布式存储节点中的目标数据表指的是用于存储增量业务数据的数据表。目标数据表的主键指的是目标数据表中的主关键字(primary key)，主关键字由目标数据表中的一个或多个字段组成，它的值用于唯一地标识目标数据表中的某一条记录。

具体地，数据处理服务器在获取到主键信息表后，将主键信息表中的主键与目标数据表中的主键一一进行比对，当存在比对不一致的主键时，将比对不一致的主键确定为第一目标主键。

步骤206C，数据处理服务器从分布式存储节点中抽取与第一目标主键对应的增量业务数据，对抽取的增量业务数据进行清洗和转换，并发送至分布式消息队列服务器中。

在一个实施例中，分布式数据库可以提供链接关系，在分布式数据库和数据处理服务器之间建立直接的链接关系，数据处理服务器可以通过Select 语句直接访问分布式数据库进行数据抽取，例如，可通过执行以下SQL语句进行数据抽取：

SELECT ……FROM（目标数据表）NOT IN （主键信息表）。

数据处理服务器抽取了第一目标主键对应的增量业务数据，对抽取的增量业务数据进行清洗和转换，最后得到目标增量业务数据。

步骤206D，数据处理服务器获取发送成功的增量业务数据对应的第二目标主键，将第二目标主键回写至主键信息表中，以对主键信息表进行更新。

其中，第二目标主键指的是字段名称与第一目标主键相同的字段。

数据处理服务器从分布式数据库中抽取数据后，由于会对抽取的数据进行清洗和转换，一般情况下，经过清洗和转换后最终得到的增量业务数据的主键与分布式数据库中的主键是不相同的，但是最终得到的增量业务数据中会包含分布式数据库对应的主键字段。例如，当分布式数据库的一个主键为订单编号时，则最终得到的增量业务数据中同样包含订单编号这一字段，因此，数据处理服服务器可根据分布式数据库对应的第一目标主键从最终得到的增量业务数据中获取对应的第二目标主键，进一步，数据处理服务器将第二目标主键回写至主键信息表中，以对主键信息表进行更新。

上述实施例中，数据处理服务器通过将主键信息表中的主键与分布式存储节点中目标数据表的主键进行比对，可以将目标数据表中所有未被加载的数据全部抽取出来，确保抽取数据时不遗漏数据，进一步，在数据成功发送到分布式消息队列服务器后，将发送成功的数据在分布式数据库中对应的主键回写至主键信息表中，主键信息表得以不断地更新，从而保证每次抽取数据时，主键信息表中存储的都是所有历史抽取数据的主键，确保每次抽取数据时都不会抽取重复的数据。

在一个实施例中，上述步骤210中从分布式消息队列服务器中获取目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作，包括：对账系统服务器获取目标业务数据表对应的唯一键配置信息，唯一键配置信息中包括至少一个目标字段；对账系统服务器将目标增量业务数据中目标字段对应的字段值与对账数据库中目标字段对应的字段值进行比对；当存在比对一致的字段值时，对账系统服务器将比对一致的字段值对应的数据从目标增量业务数据中过滤掉，将剩下的目标增量业务数据加载至对账数据库中；当不存在比对一致的字段值时，对账系统服务器将所有目标增量业务数据加载至对账数据库中。

其中，目标业务数据表指的是对账数据库中用于存储增量业务数据的数据表。唯一键配置信息指的是事先配置的用于对目标业务数据表中的数据记录进行唯一性约束的信息，唯一键配置信息中包括至少一个目标字段，该目标字段为目标业务数据表中的字段。

本实施例中，由于目标增量业务数据和目标业务数据表包含同样的字段，因此目标增量业务数据中必然包含了唯一键配置信息对应的目标字段，将目标增量业务数据中目标字段对应的字段值与对账数据库中该目标字段对应的字段值进行比对，若是存在比对一致的字段值，说明对账数据库中存在与目标增量业务数据相同的数据记录，为了保证对账数据库中的数据记录不重复，可以将比对一致的字段值对应的目标增量业务数据过滤掉，将剩下的目标增量业务数据加载到对账数据库中，若是不存在比对一致的字段值，说明对账数据库中不存在与目标增量业务数据相同的数据记录，可以将所有目标增量业务数据全部加载至对账数据库中。

上述实施例中，对账系统服务器在向对账数据库存储数据时，通过对账数据库的唯一键配置信息，根据该唯一键配置信息对目标增量业务数据进行唯一性检查，可以确保对账数据库中存储的数据不重复。

在一个实施例中，对账系统服务器在存储增量支付数据时，同样可以获取目标支付数据表对应的唯一键配置信息，将目标增量支付数据中目标字段对应的字段值与对账数据库中目标字段对应的字段值进行比对；当存在比对一致的字段值时，将比对一致的字段值对应的数据从目标增量支付数据中过滤掉，将剩下的目标增量支付数据加载至对账数据库中；当不存在比对一致的字段值时，将所有目标增量支付数据加载至对账数据库中。其中，目标支付数据表指的是用于存储增量支付数据的数据表。

在一个实施例中，上述方法还包括：数据处理服务器获取目标配置文件；数据处理服务器对目标配置文件进行解析，得到可执行代码文件；数据处理服务器根据可执行代码文件更新预先封装的数据处理层。

其中，目标配置文件指的是用于对数据处理层进行配置的文件。在一个实施例中，目标配置文件中包括配置好的与当前业务场景对应的数据处理逻辑对应的SQL脚本，该SQL脚本中包含了当前业务场景对应的业务数据的主键信息表名称。

具体地，数据处理服务器在获取到目标配置文件后，可对目标配置文件进行解析，得到可执行代码文件，根据得到的可执行代码文件可对数据处理层进行更新，如此，开发人员只需要编写配置文件就能对数据处理层进行配置，实现了数据处理逻辑的可配置化。

在一个实施例中，当当前对账类型为预设对账类型时，按照当前对账类型对应的预设对账逻辑执行对账操作，包括：对账系统服务器将获取的目标增量业务数据及目标增量支付数据分别保存在内存中的两个临时数据表中；对账系统服务器将两个临时数据表进行关联操作，对关联成功的目标增量业务数据及目标增量支付数据进行核对，若核对成功，则判定为对账成功；若核对不成功，则判定为对账失败。

其中，预设对账类型为一对一对账。本实施例中，对账系统服务器可以在内存中新建第一临时数据表及第二临时数据表，将获取的目标增量业务数据保存至第一临时数据表中，将获取的目标增量支付数据保存至第二临时数据表，然后根据第一临时数据表及第二临时数据表中的订单编号字段对两张临时表进行关联操作，若第一临时数据表的任意一条目标增量业务数据记录与第二临时数据表的任意一条目标增量支付数据记录中的订单编号字段值相同，则这两条数据记录关联成功，对账系统服务器对关联成功的数据记录进行核对，核对时，比较两条数据记录中的支付账号、收款账号及支付金额是否相同，若相同，则核对成功，判定这两条数据记录对账成功；若不相同，则核对不成功，判定这两条数据记录对账失败。

在一个实施例中，对账系统服务器在完成对当前流处理窗口内的数据的核对操作后，删除第一临时数据表和第二临时数据表。在下一个流处理窗口内，重新新建第一临时数据表和第二临时数据表。从而可以在一个流处理窗口内快速完成对账操作。

在一个实施例中，对账系统服务器可根据对账状态在对账数据库中对增量业务数据及增量支付数据进行标记，将对账成功的标记为对账成功，对对账失败的标记为对账失败，对未关联成功的标记为未对账。

上述实施例中，通过将增量支付数据和增量业务数据保存在内存中，进行关联操作后来核对对账数据，可以在流处理窗口后快速实现对账，提高对账的时效性。

在一个实施例中，如图4所示，按照当前对账类型对应的预设对账逻辑执行对账操作，具体包括以下步骤：

S402，对账系统服务器将获取的目标增量业务数据及目标增量支付数据分别保存在内存中的两个临时数据表中；

S406，对账系统服务器将两个临时数据表进行关联操作，对关联成功的目标增量业务数据及目标增量支付数据进行核对，若核对成功，则判定为对账成功；若核对不成功，则判定为对账失败；

S408，对账系统服务器在对账数据库中对对账失败的目标增量业务数据及目标增量支付数据设置预设状态标记；

S410，对账系统服务器按照预设时间间隔扫描对账数据库，获取对账数据库中预设状态标记对应的目标增量业务数据及目标增量支付数据，根据预设状态标记对应的目标增量业务数据及目标增量支付数据再次执行对账操作。

其中，预设状态标记为用于表征对账失败的对账状态。本实施例中，对账系统服务器通过在对账数据库中对对账失败的目标增量业务数据及目标增量支付数据设置预设状态标记，并可以按照预设时间间隔扫描对账数据库，当扫描到有标记为预设状态标记的数据时，将这些数据再次进行对账，以实现对账补偿机制，防止因网络问题、服务器短时间压力大等原因导致的数据延迟情况。

在一个实施例中，对账系统服务器根据预设状态标记对应的增量业务数据及增量支付数据再次执行对账操作，可对这些数据进行关联操作，将关联成功的数据进行核对，若核对成功，则判定为对账成功；若核对不成功，则判定为对账失败。

在一个实施例中，上述方法还包括：对账系统服务器对对账数据库中数据的对账状态进行监控，当监控到对账状态为预设状态的持续时间超过预设阈值的数据时，生成警告信息并发送至运维终端，预设状态包括未对账和对账失败。

其中，预设状态包括未对账和对账失败。本实施例中，对账系统服务器对对账数据库中数据的对账状态进行实时监控，当增量业务数据和增量支付数据中的任意一条数据记录的对账状态为预设状态的时间超过预设阈值时，说明监控到异常对账情况，对账系统服务器可生成警告信息并发送至运维终端，以提供运维终端对应的运维人员及时进行人工介入，避免因异常情况出现资金损失。

应该理解的是，虽然图2-4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图5所示，提供了一种对账系统500，其特征在于，系统包括业务系统服务器502、分布式数据库服务器504、数据处理服务器506、支付系统服务器508、分布式消息队列服务器510及对账系统服务器512；其中：

业务系统服务器502用于实时扫描业务系统数据库的第一日志文件，对第一日志文件进行解析，得到增量业务数据，将增量业务数据发送至分布式数据库服务器；

分布式数据库服务器504用于将接收到的增量业务数据存储至分布式数据库的分布式存储节点；

数据处理服务器506用于轮询分布式存储节点并通过调用预先封装的数据处理层从分布式存储节点中获取增量业务数据，将获取到的增量业务数据发送至分布式消息队列服务器508；其中，数据处理层根据预设的数据处理逻辑进行封装得到；

支付系统服务器510用于实时扫描支付系统数据库的第二日志文件，对第二日志文件进行解析，得到增量支付数据，将增量支付数据发送至分布式消息队列服务器；

对账系统服务器512用于监听当前流处理窗口内分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从分布式消息队列服务器中获取目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

在一个实施例中，数据处理服务器还用于获取预先创建的主键信息表；主键信息表用于存储从分布式存储节点中抽取并且成功发送至分布式消息队列的增量业务数据的主键；将主键信息表中的主键与分布式存储节点中的目标数据表的主键进行比对，将比对不一致的主键确定为第一目标主键；从分布式存储节点中抽取与第一目标主键对应的增量业务数据，对抽取的增量业务数据进行清洗和转换，并发送至分布式消息队列服务器中；获取发送成功的增量业务数据对应的第二目标主键，将第二目标主键回写至主键信息表中，以对主键信息表进行更新。

在一个实施例中，对账系统服务器还用于获取目标业务数据表对应的唯一键配置信息，唯一键配置信息中包括至少一个目标字段；将目标增量业务数据中目标字段对应的字段值与对账数据库中目标字段对应的字段值进行比对；当存在比对一致的字段值时，将比对一致的字段值对应的数据从目标增量业务数据中过滤掉，将剩下的目标增量业务数据加载至对账数据库中；当不存在比对一致的字段值时，将所有目标增量业务数据加载至对账数据库中。

在一个实施例中，数据处理服务器还用于获取目标配置文件；对目标配置文件进行解析，得到可执行代码文件；根据可执行代码文件更新预先封装的数据处理层。

在一个实施例中，当当前对账类型为预设对账类型时，对账系统服务器还用于将获取的目标增量业务数据及目标增量支付数据分别保存在内存中的两个临时数据表中；将两个临时数据表进行关联操作，对关联成功的目标增量业务数据及目标增量支付数据进行核对，若核对成功，则判定为对账成功；若核对不成功，则判定为对账失败。

在一个实施例中，对账系统服务器还用于在对账数据库中对对账失败的目标增量业务数据及目标增量支付数据设置预设状态标记；预设状态标记为用于表征对账失败的对账状态；按照预设时间间隔扫描对账数据库，获取对账数据库中预设状态标记对应的目标增量业务数据及目标增量支付数据，根据预设状态标记对应的目标增量业务数据及目标增量支付数据再次执行对账操作。

在一个实施例中，对账系统服务器对对账数据库中数据的对账状态进行监控，当监控到对账状态为预设状态的持续时间超过预设阈值的数据时，生成警告信息并发送至运维终端，预设状态包括未对账和对账失败。

关于对账系统的具体限定可以参见上文中对于对账方法的限定，在此不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种对账方法，所述方法包括：

业务系统服务器实时扫描业务系统数据库的第一日志文件，对所述第一日志文件进行解析，得到增量业务数据，将所述增量业务数据发送至分布式数据库服务器；

所述分布式数据库服务器将接收到的所述增量业务数据存储至分布式数据库的分布式存储节点；

数据处理服务器轮询所述分布式存储节点并通过调用预先封装的数据处理层从所述分布式存储节点中获取增量业务数据，将获取到的所述增量业务数据进行清洗和转换，并发送至分布式消息队列服务器；其中，所述数据处理层根据预设的数据处理逻辑进行封装得到；

支付系统服务器实时扫描支付系统数据库的第二日志文件，对所述第二日志文件进行解析，得到增量支付数据，将所述增量支付数据发送至所述分布式消息队列服务器；

对账系统服务器监听当前流处理窗口内所述分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从所述分布式消息队列服务器中获取所述目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

2.根据权利要求1所述的方法，其特征在于，所述数据处理服务器轮询所述分布式存储节点并通过调用预先封装的数据处理层从所述分布式存储节点中获取增量业务数据，将获取到的所述增量业务数据发送至分布式消息队列服务器，包括：

所述数据处理服务器获取预先创建的主键信息表；所述主键信息表用于存储从分布式存储节点中抽取并且成功发送至分布式消息队列的增量业务数据的主键；

所述数据处理服务器将所述主键信息表中的主键与所述分布式存储节点中的目标数据表的主键进行比对，将比对不一致的主键确定为第一目标主键；

所述数据处理服务器从所述分布式存储节点中抽取与所述第一目标主键对应的增量业务数据，对抽取的增量业务数据进行清洗和转换，并发送至所述分布式消息队列服务器中；

所述数据处理服务器获取发送成功的增量业务数据对应的第二目标主键，将所述第二目标主键回写至所述主键信息表中，以对所述主键信息表进行更新。

3.根据权利要求1所述的方法，其特征在于，所述从所述分布式消息队列服务器中获取所述目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作，包括：

所述对账系统服务器获取目标业务数据表对应的唯一键配置信息，所述唯一键配置信息中包括至少一个目标字段；

所述对账系统服务器将所述目标增量业务数据中所述目标字段对应的字段值与对账数据库中所述目标字段对应的字段值进行比对；

当存在比对一致的字段值时，所述对账系统服务器将比对一致的字段值对应的数据从所述目标增量业务数据中过滤掉，将剩下的目标增量业务数据加载至所述对账数据库中；

当不存在比对一致的字段值时，所述对账系统服务器将所有目标增量业务数据加载至所述对账数据库中。

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

所述数据处理服务器获取目标配置文件；

所述数据处理服务器对所述目标配置文件进行解析，得到可执行代码文件；

所述数据处理服务器根据所述可执行代码文件更新所述预先封装的数据处理层。

5.根据权利要求1所述的方法，其特征在于，当所述当前对账类型为预设对账类型时，所述按照当前对账类型对应的预设对账逻辑执行对账操作，包括：

对账系统服务器将获取的所述目标增量业务数据及目标增量支付数据分别保存在内存中的两个临时数据表中；

对账系统服务器将两个临时数据表进行关联操作，对关联成功的目标增量业务数据及目标增量支付数据进行核对，若核对成功，则判定为对账成功；若核对不成功，则判定为对账失败。

6.根据权利要求5所述的方法，其特征在于，所述按照当前对账类型对应的预设对账逻辑执行对账操作，还包括：

对账系统服务器在对账数据库中对对账失败的目标增量业务数据及目标增量支付数据设置预设状态标记；所述预设状态标记为用于表征对账失败的对账状态；

对账系统服务器按照预设时间间隔扫描所述对账数据库，获取所述对账数据库中所述预设状态标记对应的目标增量业务数据及目标增量支付数据，根据所述预设状态标记对应的目标增量业务数据及目标增量支付数据再次执行对账操作。

7.根据权利要求1至5任意一项所述的方法，其特征在于，所述方法还包括：

对账系统服务器对对账数据库中数据的对账状态进行监控，当监控到对账状态为预设状态的持续时间超过预设阈值的数据时，生成警告信息并发送至运维终端，所述预设状态包括未对账和对账失败。

8.一种对账系统，其特征在于，所述系统包括业务系统服务器、分布式数据库服务器、数据处理服务器、支付系统服务器、分布式消息队列服务器及对账系统服务器；其中：

业务系统服务器用于实时扫描业务系统数据库的第一日志文件，对所述第一日志文件进行解析，得到增量业务数据，将所述增量业务数据发送至分布式数据库服务器；

所述分布式数据库服务器用于将接收到的所述增量业务数据存储至分布式数据库的分布式存储节点；

数据处理服务器用于轮询所述分布式存储节点并通过调用预先封装的数据处理层从所述分布式存储节点中获取增量业务数据，将获取到的所述增量业务数据进行清洗和转换，并发送至分布式消息队列服务器；其中，所述数据处理层根据预设的数据处理逻辑进行封装得到；

支付系统服务器用于实时扫描支付系统数据库的第二日志文件，对所述第二日志文件进行解析，得到增量支付数据，将所述增量支付数据发送至所述分布式消息队列服务器；

对账系统服务器用于监听当前流处理窗口内所述分布式消息队列服务器接收的目标增量业务数据及目标增量支付数据，当成功监听到目标增量业务数据及目标增量支付数据时，从所述分布式消息队列服务器中获取所述目标增量业务数据及目标增量支付数据，并按照当前对账类型对应的预设对账逻辑执行对账操作。

9.根据权利要求8所述的系统，其特征在于：

所述数据处理服务器还用于获取预先创建的主键信息表；所述主键信息表用于存储从分布式存储节点中抽取并且成功发送至分布式消息队列的增量业务数据的主键；将所述主键信息表中的主键与所述分布式存储节点中的目标数据表的主键进行比对，将比对不一致的主键确定为第一目标主键；从所述分布式存储节点中抽取与所述第一目标主键对应的增量业务数据，对抽取的增量业务数据进行清洗和转换，并发送至所述分布式消息队列服务器中；获取发送成功的增量业务数据对应的第二目标主键，将所述第二目标主键回写至所述主键信息表中，以对所述主键信息表进行更新。

10.根据权利要求8所述的系统，其特征在于：

所述对账系统服务器还用于获取目标业务数据表对应的唯一键配置信息，所述唯一键配置信息中包括至少一个目标字段；将所述目标增量业务数据中所述目标字段对应的字段值与对账数据库中所述目标字段对应的字段值进行比对；当存在比对一致的字段值时，将比对一致的字段值对应的数据从所述目标增量业务数据中过滤掉，将剩下的目标增量业务数据加载至所述对账数据库中；当不存在比对一致的字段值时，将所有目标增量业务数据加载至所述对账数据库中。

Images