CN115984022A - 分布式支付系统统一对账方法和装置 - Google Patents

Abstract

本发明公开了分布式支付系统统一对账方法和装置，属于分布式支付领域。该方法包括在统一对账平台中为业务流程设计和配置对账流程；业务系统将源数据转换为目标数据文件，通过API端点向统一对账平台发起对账请求；统一对账平台将对账请求序列化为对账任务记录；加载对账任务记录，在多节点之间完成对账任务投递；获取对账任务；拉取目标数据文件并执行对账流程，然后下发对账结果文件；业务系统拉取对账结果文件并更新源数据。本发明实现了关键流程内高内聚和流程间松耦合，避免了多系统重复工作，降低了系统的维护成本，在提高勾兑效率的同时避免了单点故障。

Description

分布式支付系统统一对账方法和装置

技术领域

本发明涉及金融支付领域，尤其涉及一种分布式支付系统统一对账方法和装置。

背景技术

随着互联网金融行业高速发展，分布式支付服务越来越多，交易业务数据成倍增加。在分布式支付系统中，对账流程为支付服务和清结算提供了关键的技术支持，用于使支付使用方和支付提供方相互确认交易、资金的正确性。如何提高对账效率和准确性，成为分布式支付系统亟需解决的问题。

现有的对账模式存在的问题主要在于，不同的业务系统参与者之间各自执行物理隔离的对账流程，存在重复工作的情况。而且不同的对账流程之间流程相似度较高，对账流程的调整会带来较大的系统测试和维护成本。在每次对账流程执行时，需要通过创建一个新的线程来进行驱动，导致对账流程性能低下。另一方面，对账流程内部关键步骤之间耦合度较高，也导致流程的拓展性较差。在模式选择上，对账流程采用基于内存的模式进行勾兑，而基于内存的模式会消耗较多的内存资源和I/O资源，并且存在OOM（内存不足）的风险。此外，所有的对账流程缺少相应的流程管理过程，同一业务系统内部所有的对账流程共享同一数据区，对账流程之间无隔离，系统资源率较低，容易引发资源使用瓶颈。最后，由于不同业务系统参与者的对账流程局限在单个节点上，还存在单点故障风险。

发明内容

为了解决现有技术中多个支付业务系统参与者协同完成同一笔交易且参与者之间存在账务勾兑时所存在的问题，本发明提供了如下技术方案。

本发明在第一方面提供了一种分布式支付系统统一对账方法，包括：

根据多个业务系统参与者信息和交易数据信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程；

通过业务系统获取源数据，并基于预定义数据规范将源数据转换为目标数据文件，然后将所述目标数据文件推送到指定的文件服务器目录下，并通过API端点向所述统一对账平台发起对账请求；

所述统一对账平台接收所述业务系统的对账请求，并将所述对账请求序列化为对账任务记录；核心线程引擎驱动主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递；所述核心线程引擎驱动工作线程获取对账任务，并执行统一对账流程；

所述核心线程引擎驱动相应的工作线程从所述文件服务器目录拉取所述目标数据文件，并对所述目标数据文件进行预处理，对预处理后的文件分别执行数据勾兑处理、差错处理和拓展处理，并在完成上述对账流程后得到对账结果文件；

将所述对账结果文件下发到指定文件服务器目录中，并通知业务系统拉取所述对账结果文件，以根据所述对账结果文件更新所述源数据。

优选地，所述根据多个业务系统参与者信息和交易数据信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程，进一步包括：

根据业务系统参与角色和交易数据的流向，设计和配置相应的单向连通图，所述单向连通图的每个节点对应于不同的业务系统参与者，实线表示两个节点间存在对账关系，箭头表示节点间对账流程走向或对账关系间的依赖关系。

优选地，所述通过业务系统获取源数据，进一步包括：

基于预先设置的获取规则，从非同一网段的外部系统参与者中获取源数据文件；

基于当前接口通信模式，从同一网段的外部系统参与者中获取源数据文件；

采用数据查询工具从业务数据库中采集需要对账的源数据。

优选地，所述将目标数据文件推送到指定的文件服务器目录下，进一步包括：

将所述目标数据文件根据各个业务系统的节点配置上传到预先指定的SFTP服务器目录；在目标数据文件上传结束后，上传一个空文件，表示已完成所述目标数据文件的上传操作。

优选地，所述核心线程引擎驱动主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递，进一步包括：

所述核心线程引擎驱动leader节点的主线程从数据库中加载未执行的任务，并封装为对账任务model，即内存数据模型；

所述leader节点基于follower节点的队列状态，将对账任务分发投递给对应的follower节点，并缓存到本地队列中；

各个节点的主线程通过其管理的工作线程依次消费队列中的所述对账任务，并按照所述对账任务的状态执行统一对账流程。

优选地，所述对所拉取到的目标数据文件进行预处理，进一步包括：

将从SFTP服务器的指定位置拉取到的src源文件、存疑期内的doubt存疑文件合并成merge文件；

将merge文件中的数据进行排序，以将其处理成待勾兑src.check文件。

优选地，在所述根据所述对账结果文件更新所述源数据之后，该方法还包括：

监听差错处理接口，如果接收到来自所述UI页面的差错调整请求，则进行对应的差错调整。

本发明在第二方面提供了一种分布式支付系统统一对账装置，包括：

配置单元，用于根据多个业务系统参与者信息和交易数据信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程；

获取单元，用于通过业务系统获取源数据，并基于预定义数据规范将源数据转换为目标数据文件，然后将所述目标数据文件推送到指定的文件服务器目录下，并通过API端点向所述统一对账平台发起对账请求；

任务处理单元，用于接收所述业务系统的对账请求，并将所述对账请求序列化为对账任务记录；通过主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递；通过工作线程获取对账任务，并执行统一对账流程；

对账单元，用于通过相应的工作线程从所述文件服务器目录拉取所述目标数据文件，并对所述目标数据文件进行预处理，对预处理后的文件分别执行数据勾兑处理、差错处理和拓展处理，在完成上述对账流程后得到对账结果文件；

输出单元，用于将所述对账结果文件下发到指定文件服务器目录中，通知业务系统拉取所述对账结果文件，并根据所述对账结果文件更新所述源数据。

本发明另一方面提供了一种电子设备，包括处理器和存储器，所述存储器存储有计算机程序代码，所述处理器用于读取所述计算机程序代码并执行前述第一方面的分布式支付系统统一对账方法。

本发明又一方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序代码，所述计算机程序代码可被处理器读取和执行，以执行前述第一方面的分布式支付系统统一对账方法。

本发明的有益效果是：

针对同一业务场景下多业务系统参与者参与对账的应用场景，将对账流程高度抽象成核心对账流程，包括文件获取/合并/排序、数据勾兑、差错处理、拓展处理和结果下发，实现了关键流程内高内聚，流程间松耦合，增加了系统的可拓展性，适用于业务边界明晰、业务职责高内聚、多个参与者参与的交易场景下的账务勾兑。通过暴露的API端点服务接收并序列化对账任务来确保任务安全，并提供核心线程引擎驱动任务获取/分发/执行、支持通过UI基于业务流程进行映射/设计/配置/查看来实现业务系统的快速接入。各业务系统均可接入该系统，避免重复工作和降低系统的维护成本。平台的核心勾兑流程基于文件进行，避免了对内存、I/O等核心资源的消耗，提高勾兑效率。由于对账平台从原单节点模式拓展为AP模式，还能够在提升系统效率的同时有效避免单点故障。

附图说明

图1是本发明所述的统一对账平台的功能架构示意图。

图2是本发明所述的分布式支付系统统一对账方法的总体流程图。

图3是本发明所述的分布式支付系统统一对账方法的详细流程图。

具体实施方式

为了更好地理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案做详细的说明。

本发明提供的方法可以在如下的终端环境中实施，该终端可以包括一个或多个如下部件：处理器、存储器和显示屏。其中，存储器中存储有至少一条指令，所述指令由处理器加载并执行以实现下述实施例所述的方法。处理器可以包括一个或者多个处理核心。处理器利用各种接口和线路连接整个终端内的各个部分，通过运行或执行存储在存储器内的指令、程序、代码集或指令集，以及调用存储在存储器内的数据，执行终端的各种功能和处理数据。存储器可以包括随机存储器（Random Access Memory，RAM），也可以包括只读存储器（Read-Only Memory，ROM）。存储器可用于存储指令、程序、代码、代码集或指令。显示屏用于显示各个应用程序的用户界面。

除此之外，本领域技术人员可以理解，上述终端的结构并不构成对终端的限定，终端可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，终端中还包括射频电路、输入单元、传感器、音频电路、电源等部件，在此不再赘述。

本发明提出了一种分布式支付系统统一对账方法和装置，用于分布式支付交易场景下，针对同一笔交易的多个参与者之间进行多边账务勾兑，采用统一集成的流程内高内聚、流程间松耦合的高性能对账方法，该方法基于文件操作，支持多节点协同并且具有拓展性，通过对比同一笔交易在不同系统间的关键交易要素（金额、交易状态等）是否一致来执行对账流程。如果不一致但无风险则进行数据同步，否则对比出相应的差错，并针对类似场景提供了可供参考的解决方案，适用于业务边界明晰、业务职责高内聚、多个参与者参与的交易场景下的账务勾兑。

图1是根据本发明的统一对账平台的功能架构示意图。参见图1，统一对账平台主要由高度集成的对账流程、核心线程引擎（threads engine）、对账任务队列（queue）、API端点服务和UI页面dashboard等部分构成。采用基于AP模式下的多节点通信和对账任务分发投递模式。所述dashboard是用户UI界面的一部分，用户在所述dashboard上可以为每个业务流程映射/设计/配置相应的对账流程。所述API端点用于暴露/接收业务系统异步的对账请求，并将对账请求序列化为对账任务记录。所述核心线程引擎用于驱动主线程加载对账任务，并完成对账任务投递。所述核心线程引擎进一步驱动工作线程按照对账流程依次进行处理，当对账流程处理结束后，将对账结果文件推送给业务系统，并通知业务系统进行后续的异步处理。此外，通过所述dashboard也可以查看对账任务对应的执行结果。

如图2所示，本发明第一方面提供了一种分布式支付系统统一对账方法，包括：

步骤101、根据多个业务系统参与者信息和交易数据相关信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程。

请一并参见图3，方法开始于步骤S10，在 dashboard（UI页面）上，允许用户根据业务系统参与角色和交易数据的流向，设计和配置相应的单向连通图，实现对账流程的快速接入。所述单向连通图是一种用于映射和控制对账过程的静态图，图中不同节点对应于不同业务系统参与者，实线表示两个节点间存在对账关系，箭头表示节点间对账流程走向或对账关系间的依赖关系。

具体地，对单向连通图的设计和配置可以包括节点映射/配置、对账边配置和对账流向设置。所述节点可以与业务系统参与者建立映射，表示可以从参与者实际获取的勾兑文件，因此所述节点映射/配置具体可以包括对文件数据行格式、文件存取路径/获取方式、关键数据域映射关系/取值范围等的配置。所述对账边表示相邻两个节点间存在某种勾兑关系，因此对账边配置可以包括对相邻边依赖性、节点数据过滤规则、勾兑规则、勾兑结果预警模型、勾兑文件存取规则等的配置。所述对账流向设置则可以体现为勾兑过程中对勾兑控制流流向的设置。

步骤102、通过业务系统获取源数据，并基于预定义数据规范将源数据转换为目标数据文件，然后将所述目标数据文件推送到指定的文件服务器目录下，并通过API端点向所述统一对账平台发起对账请求。

在图3的步骤S20中，业务系统分别从外部参与系统或业务数据库获取源数据文件，或者采集源数据。

进一步地，上述步骤S20可以包括以下步骤：

S21：基于预先设置的获取规则，从非同一网段的外部系统参与者中获取源数据文件。所述获取规则包括文件生成时间、格式、存储路径以及网络策略配置等。

S22：基于当前接口通信模式，从同一网段的外部系统参与者中获取所述源数据文件。

S23：采用数据查询工具从相应的业务数据库中采集需要对账的源数据。

在图3的步骤S30中，业务系统基于预定义数据规范，将源数据清洗为目标数据文件，并推送到文件服务器指定目录下。

进一步地，上述步骤S30具体可以包括：

S31：将从各业务系统采集到的源数据文件按照对应的业务系统节点配置进行清洗、解析，生成目标数据文件。

S32：将生成的目标数据文件根据各个业务系统的节点配置而上传到预先指定的SFTP服务器目录。在目标数据文件上传结束后，相应会上传一个“.OK”空文件，用于表示目标数据文件上传操作已完成。

在图3的步骤S40中，业务系统通过API端点向统一对账平台发起对账请求。如果是首次发起，则进入新建对账流程，否则表示重对账流程。通过API端点服务来接收并序列化对账任务，可以确保任务的安全性。

步骤103、所述统一对账平台接收所述业务系统的对账请求，并将所述对账请求序列化为对账任务记录；核心线程引擎驱动主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递；所述核心线程引擎驱动工作线程获取对账任务，并执行统一对账流程。

在图3的步骤S50中，统一对账平台接收业务系统的对账请求，并将对账任务序列化到数据库表中。

进一步地，上述步骤S50具体可以包括：

S51：所述统一对账平台接收业务系统发起的对账请求，并对请求依次进行接口检查、业务检查和流程处理。

S52：在预设数据库表ucp_task_run（任务表）中插入一条待处理的对账任务数据记录。

S53：向相应的业务系统返回受理成功消息。

由于各个业务系统均可接入到统一支付平台，能够避免各个业务系统的重复工作并降低业务系统的维护成本，同时减少了单点故障风险。

在图3的步骤S60中，所述核心线程引擎驱动主线程加载所述对账任务记录，形成内存数据模型，并基于队列的状态在多follower节点（可以来自单机模式下的同一进程内，也可以来自集群模式下的不同进程内）之间完成投递。工作线程从对账任务队列（queue）中获取对账任务，并按照统一对账流程完成流转。

进一步地，上述步骤S60具体可以包括：

S61：核心线程引擎thread engine 驱动leader节点（领导者节点）的主线程从数据库中加载未执行的任务，并封装为对账任务model，即内存数据模型。

S62：leader节点基于follower节点（跟随者节点）的队列状态，将对账任务model分发投递给对应的follower节点，并缓存到本地队列queue中。

S63：利用生产者消费者模型，各个节点的主线程通过其管理的工作线程依次消费队列中的对账任务model，并按照对账任务model的状态执行统一对账流程。

步骤104、所述核心线程引擎驱动相应的工作线程从所述文件服务器目录拉取所述目标数据文件，并对所述目标数据文件进行预处理，对预处理后的文件分别执行数据勾兑处理、差错处理和拓展处理，在完成上述对账流程后得到对账结果文件。

在图3的步骤S70中，工作线程对所获取的数据文件进行拉取、合并、排序预处理。

进一步地，上述步骤S70具体可以包括：

S71：所述工作线程根据业务系统的节点配置，从指定位置拉取指定文件。在默认情况下，工作线程从SFTP服务器获取该指定文件。例如，待拉取的文件可以包括src源文件、存疑期内的doubt存疑文件等。在文件拉取之前，首先通过查询是否存在步骤S32所述的“.OK”空文件，来判断待拉取文件是否就绪。

S72：将拉取到的src源文件、存疑期内的doubt存疑文件合并成merge文件。

S73：将merge文件中的数据进行排序，以将其处理成待勾兑src.check文件。在一个实施例中，基于linux 文件系统默认通过SORT指令完成数据排序和写入。所述统一对账平台还支持其他的文件数据排序方式，包括HASH排序。

在图3的步骤S80中，工作线程对预处理后的文件执行数据勾兑处理。

进一步地，上述步骤S80具体可以包括：

S81：工作线程根据步骤S10中的对账边关系配置，对关联业务节点的src.check文件逐一进行交易数据勾兑。在默认情况下，可以通过单路勾兑来完成一对一勾兑。在勾兑过程中可以基于节点数据过滤规则来选择跳过符合规则的数据。

S82：工作线程根据勾兑的结果，将数据对比为存疑、对平或差错数据，相应的生成doubt存疑文件、check对平文件和error差错文件。

在图3的步骤S90中，工作线程可以对勾兑后的数据执行差错处理，并且可以将差错结果展示在dashboard（UI页面）上并进行后续处理。

具体地，工作线程可以基于各业务系统的策略配置，对勾兑结果文件进行解析存储，其中可以将check对平文件存储到ucp_checked（对平表）中，并分别将doubt存疑文件和error差错文件记录到ucp_check_error（差错表）中，然后将上述记录数据通过dashboard进行展示，以供用户进行查看以及后续的差错处理。

在图3的步骤S100中，工作线程选择性地执行拓展处理。工作线程基于配置的触发条件，对error差错文件进行判断，即判断是否触发相应的拓展处理流程。例如，拓展处理可以包括通过触发短信通知来进行预警通知。

上述核心勾兑流程都是针对文件来执行的，因而避免了将大量数据加载到内存而对系统内存、I/O等核心资源的消耗。

步骤105、将所述对账结果文件下发到指定文件服务器目录中，并通知业务系统拉取所述对账结果文件，以根据所述对账结果文件更新所述源数据。

在图3的步骤S110中，工作线程完成所有对账流程，可以执行结果下发操作。

进一步地，上述步骤S110具体可以包括：

S111：工作线程将对账结果文件按照预先配置推送到指定目录。由于对账前的数据文件从SFTP服务器中获取，因此在默认情况下，工作线程将对账结果推送到相对应的SFTP指定目录下。

S112：在check对平文件、doubt存疑文件和error差错文件推送完成后，继续推送上传一个“.OK”空文件，用于标记文件上传动作已完成。

S113：所述统一对账平台调用业务系统的对账结果通知接口，以通知业务系统本次对账完成。

在图3的步骤S120中，业务系统拉取对账结果文件，并更新源数据对账结果。

进一步地，上述步骤S120具体可以包括：

S121：业务系统可以从SFTP指定目录拉取对账结果文件（check对平文件、doubt存疑文件和error差错文件），并更新本地对账结果。

S122：监听差错处理接口并接收来自dashboard的差错调整请求，如果接收到相应请求，则进行对应的差错调整流程。

可以看出，通过本发明的针对同一业务场景下多业务系统参与者参与对账的统一集成对账平台和对账方法，将对账流程高度抽象成核心对账流程，包括文件获取/合并/排序、数据勾兑、差错处理、拓展处理和结果下发，实现了关键流程内高内聚，流程间松耦合，增加了系统的可拓展性。通过暴露的API端点服务接收并序列化对账任务来确保任务安全，并提供核心线程引擎驱动任务获取/分发/执行、支持通过UI基于业务流程进行映射/设计/配置/查看来实现业务系统的快速接入。各业务系统均可接入该系统，避免重复工作和降低系统的维护成本。平台的核心勾兑流程基于文件进行，避免了对内存、I/O等核心资源的消耗，使得勾兑效率能够有效提升60%以上。由于对账平台从原单节点模式拓展为AP模式，还能够在提升系统效率的同时有效避免单点故障。

本发明的第二方面还包括与前述实施例的分布式支付系统统一对账方法完全对应一致的功能模块架构，即提供了一种分布式支付系统统一对账装置，包括：

配置单元，用于根据多个业务系统参与者信息和交易数据信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程；

获取单元，用于通过业务系统获取源数据，并基于预定义数据规范将源数据转换为目标数据文件，然后将所述目标数据文件推送到指定的文件服务器目录下，并通过API端点向统一对账平台发起对账请求；

任务处理单元，用于接收所述业务系统的对账请求，并将所述对账请求序列化为对账任务记录；通过主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递；通过工作线程获取对账任务，并执行统一对账流程；

对账单元，用于通过相应的工作线程从所述文件服务器目录拉取所述目标数据文件，并对所述目标数据文件进行预处理，对预处理后的文件分别执行数据勾兑处理、差错处理和拓展处理，在完成上述对账流程后得到对账结果文件；

输出单元，用于将所述对账结果文件下发到指定文件服务器目录中，通知业务系统拉取所述对账结果文件，并根据所述对账结果文件更新所述源数据。

上述装置可通过上述第一方面的实施例提供的分布式支付系统统一对账方法实现，具体的实现方式可以参见第一方面的实施例中的描述，在此不再赘述。

本发明还提供了一种电子设备，包括处理器和存储器，所述存储器存储有计算机程序代码，所述处理器用于读取所述计算机程序代码并执行前述实施例中的分布式支付系统统一对账方法。其中处理器和存储器可以通过总线或者其他方式连接，以通过总线连接为例。处理器可以为中央处理器（Central Processing Unit，CPU）。处理器还可以为其他通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。

存储器作为一种非暂时性计算机可读存储介质，可用于存储非暂时性软件程序、非暂时性计算机可执行程序以及模块，如本申请实施例中的分布式支付系统统一对账方法所对应的程序指令/模块。处理器通过运行存储在存储器中的非暂时性软件程序、指令以及模块，从而执行处理器的各种功能应用以及数据处理，即实现上述方法实施例中的方法。

存储器可以包括存储程序区和存储数据区，其中，所述存储程序区可存储操作系统、至少一个功能所需要的应用程序；而所述存储数据区可存储处理器所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非暂时性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂时性固态存储器件。该计算机可读存储介质可以是有形存储介质，诸如随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、软盘、硬盘、可移动存储盘、CD-ROM，或本技术领域内所公知的任意其它形式的存储介质。在一些实施例中，存储器可选地包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至处理器。上述网络的实例包括但不限于，互联网、企业内部网、局域网、移动通信网及其组合。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，如果本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种分布式支付系统统一对账方法，其特征在于，包括：

根据多个业务系统参与者信息和交易数据信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程；

通过业务系统获取源数据，基于预定义数据规范将所述源数据转换为目标数据文件，将所述目标数据文件推送到指定的文件服务器目录下，并通过API端点向所述统一对账平台发起对账请求；

所述统一对账平台接收所述业务系统的对账请求，并将所述对账请求序列化为对账任务记录；核心线程引擎驱动主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递；所述核心线程引擎驱动工作线程获取对账任务，并执行统一对账流程；

所述核心线程引擎驱动相应的工作线程从所述文件服务器目录拉取所述目标数据文件，对所述目标数据文件进行预处理，并对预处理后的文件分别执行数据勾兑处理、差错处理和拓展处理，在完成上述对账流程后得到对账结果文件；

将所述对账结果文件下发到指定文件服务器目录中，并通知业务系统拉取所述对账结果文件，以根据所述对账结果文件更新所述源数据。

2.根据权利要求1所述的分布式支付系统统一对账方法，其特征在于，所述根据多个业务系统参与者信息和交易数据信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程，进一步包括：

根据业务系统参与角色和交易数据的流向，设计和配置相应的单向连通图，所述单向连通图的每个节点对应于不同的业务系统参与者，实线表示两个节点间存在对账关系，箭头表示节点间对账流程走向或对账关系间的依赖关系。

3.根据权利要求1所述的分布式支付系统统一对账方法，其特征在于，所述通过业务系统获取源数据，进一步包括：

基于预先设置的获取规则，从非同一网段的外部系统参与者中获取源数据文件；

基于当前接口通信模式，从同一网段的外部系统参与者中获取源数据文件；

采用数据查询工具从业务数据库中采集需要对账的源数据。

4.根据权利要求1所述的分布式支付系统统一对账方法，其特征在于，所述将所述目标数据文件推送到指定的文件服务器目录下，进一步包括：

将所述目标数据文件根据各个业务系统的节点配置上传到预先指定的SFTP服务器目录；在目标数据文件上传结束后，上传一个空文件，表示已完成所述目标数据文件的上传操作。

5.根据权利要求1所述的分布式支付系统统一对账方法，其特征在于，所述核心线程引擎驱动主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递，进一步包括：

所述核心线程引擎驱动leader节点的主线程从数据库中加载未执行的任务，并封装为对账任务model，即内存数据模型；

所述leader节点基于follower节点的队列状态，将对账任务分发投递给对应的follower节点，并缓存到本地队列中；

各个节点的主线程通过其管理的工作线程依次消费队列中的所述对账任务，并按照所述对账任务的状态执行统一对账流程。

6.根据权利要求1所述的分布式支付系统统一对账方法，其特征在于，所述对所述目标数据文件进行预处理，进一步包括：

将从SFTP服务器的指定位置拉取到的src源文件、存疑期内的doubt存疑文件合并成merge文件；

将merge文件中的数据进行排序，以将其处理成待勾兑的src.check文件。

7.根据权利要求1所述的分布式支付系统统一对账方法，其特征在于，在所述根据所述对账结果文件更新所述源数据之后，该方法还包括：

监听差错处理接口，如果接收到来自所述UI页面的差错调整请求，则进行对应的差错调整。

8.一种分布式支付系统统一对账装置，其特征在于，包括：

配置单元，用于根据多个业务系统参与者信息和交易数据信息，在统一对账平台的UI页面中为同一业务流程设计和配置相应的对账流程；

获取单元，用于通过业务系统获取源数据，并基于预定义数据规范将源数据转换为目标数据文件，然后将所述目标数据文件推送到指定的文件服务器目录下，并通过API端点向所述统一对账平台发起对账请求；

任务处理单元，用于接收所述业务系统的对账请求，并将所述对账请求序列化为对账任务记录；通过主线程加载所述对账任务记录，形成内存数据模型，并在多节点之间完成对账任务投递；通过工作线程获取对账任务，并执行统一对账流程；

对账单元，用于通过相应的工作线程从所述文件服务器目录拉取所述目标数据文件，并对所述目标数据文件进行预处理，对预处理后的文件分别执行数据勾兑处理、差错处理和拓展处理，在完成上述对账流程后得到对账结果文件；

输出单元，用于将所述对账结果文件下发到指定文件服务器目录中，通知业务系统拉取所述对账结果文件，并根据所述对账结果文件更新所述源数据。

9.一种电子设备，其特征在于，包括处理器和存储器，所述存储器存储有计算机程序代码，所述处理器用于读取所述计算机程序代码并执行根据权利要求1至7任一项所述的分布式支付系统统一对账方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序代码，所述计算机程序代码可被处理器读取和执行，以执行根据权利要求1至7任一项所述的分布式支付系统统一对账方法。

Images