CN111737262A - 一种数据处理方法及装置 - Google Patents

Abstract

一种数据处理方法及装置，用以提高数据处理的灵活性。处理服务器从预设数据表中目标账户对应的数据中选择生成时间最晚且状态为待处理的数据作为目标数据，处理目标数据，并将其状态更新为处理中，在得到目标数据对应的处理结果后：若处理失败，则将预设数据表中目标数据的状态更新为处理失败，并将各条数据中生成时间位于目标数据之前的数据的状态更新为无需处理，若处理成功，则将预设数据表中目标数据的状态更新为处理成功。通过在预设数据表中设置各条数据的状态，能够准确把控每条数据的处理进度，从而能够实现按照生成时间由近及远的顺序处理各条数据，有助于提高数据处理的灵活性。

Description

一种数据处理方法及装置

技术领域

本发明涉及金融科技(Fintech)技术领域，尤其涉及一种数据处理方法及装置。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融行业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、实时性要求，也对技术提出了更高的要求。

金融行业(比如银行)一般都会涉及到数据处理作业，且由于金融行业的性质，需要尽可能地保证数据处理作业的准确性、安全性和不可丢失性。然而，现阶段的数据处理方法大都只能对单条数据进行处理，当处理多条数据时，则需要针对于每条数据依次发送处理请求，导致数据处理方法的灵活性较差。

综上，目前亟需一种数据处理方法，用以提高数据处理的灵活性。

发明内容

本发明实施例提供一种数据处理方法及装置，用以提高数据处理的灵活性。

第一方面，本申请提供一种数据处理方法，该方法适用于处理服务器，该方法包括：处理服务器从预设数据表中目标账户对应的各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对目标数据进行处理，并将目标数据的状态更新为处理中，在得到目标数据对应的处理结果后：若处理结果为处理失败，则将预设数据表中目标数据的状态更新为处理失败，并将各条数据中生成时间位于目标数据之前的数据的状态更新为无需处理，若处理结果为处理成功，则将预设数据表中目标数据的状态更新为处理成功。

在上述设计中，通过设置预设数据表，并在预设数据表中设置各条数据的状态，使得处理服务器能够准确把控每条数据的处理进度，例如该条数据是处于处理中、待处理、处理成功、处理失败还是无需处理。如此，在已知各条数据的状态的条件下，处理服务器能够按照生成时间由近及远的顺序准确处理各条数据，从而适用于用户对多条数据的处理时间存在需求的场合，有助于提高数据处理的灵活性。

在一种可能的设计中，处理服务器从各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据之前，还确定各条数据中不存在状态为处理中的数据。如此，处理服务器可以避免对当前存在处理任务的账户的数据进行处理，以尽可能地保证某一账户的当前数据处理完成之后再处理下一条数据，有助于该账户的各条数据能够准确按照生成时间由近及远的顺序被处理。

在一种可能的设计中，若各条数据中存在状态为处理中的数据，则处理服务器可以根据预设数据表中的各个账户，重新确定目标账户。如此，处理服务器在当前账户存在处理任务的情况下，可以转为处理其它账户，从而在等待当前账户的数据的处理结果的同时能够并行处理其它账户的数据，数据处理的效率较好。

在一种可能的设计中，处理服务器对目标数据进行处理，包括：处理服务器从预设数据表中查询得到目标数据对应的第一数据值，获取目标账户在当前时刻对应的第二数据值，若第一数据值不大于第二数据值，则根据第一数据值生成目标数据对应的处理任务，若第一数据值大于第二数据值，则根据第二数据值生成目标数据对应的处理任务，进而将预设数据表中目标数据对应的状态更新为处理中。如此，处理服务器每次都可以根据账户的数据值和数据的数据值中的最小值执行数据处理操作，以避免账户的数据值不足以支持数据的数据值的情况发生，提高数据处理的可行性。

在一种可能的设计中，预设数据表通过如下方式得到：处理服务器接收数据处理请求，根据该数据处理请求中包括的账户信息，获取该账户信息对应的各条备选数据，从各条备选数据中确定出位于该数据处理请求中包括的时间信息范围内的各条数据，将各条数据添加在预设数据表中。

在一种可能的设计中，将所述各条数据添加在预设数据表中，包括：处理服务器按照生成时间由近及远的顺序从各条数据中选取一条未分析过的数据，根据该数据对应的第三数据值和该账户在当前时刻对应的第四数据值，确定该数据对应的第一数据值，将该数据、该账户信息和该第一数据值添加在预设数据表中，并设置预设数据表中该数据的状态为待处理，循环执行上述内容直至各条数据中不存在未分析的数据。其中，第一数据值为第三数据值和第四数据值中取值较小的值。

第二方面，本申请提供一种数据处理装置，该装置包括：

确定模块，用于根据预设数据表中的各个账户，确定目标账户；

处理模块，用于获取所述目标账户对应的各条数据，从所述各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对所述目标数据进行处理，并将所述目标数据的状态更新为处理中；

更新模块，用于在得到所述目标数据对应的处理结果后，若所述处理结果为处理失败，则将所述预设数据表中所述目标数据的状态更新为处理失败，并将所述各条数据中生成时间位于所述目标数据之前的数据的状态更新为无需处理；或者，若所述处理结果为处理成功，则将所述预设数据表中所述目标数据的状态更新为处理成功。

在一种可能的设计中，所述处理模块从所述各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据之前，还用于：确定所述各条数据中不存在状态为处理中的数据。

在一种可能的设计中，所述处理模块还用于：若所述各条数据中存在状态为处理中的数据，则根据预设数据表中的各个账户，重新确定所述目标账户。

在一种可能的设计中，所述处理模块具体用于：从所述预设数据表中查询得到所述目标数据对应的第一数据值，获取所述目标账户在当前时刻对应的第二数据值，若所述第一数据值不大于所述第二数据值，则根据第一数据值生成所述目标数据对应的处理任务；或者，若所述第一数据值大于所述第二数据值，则根据第二数据值生成所述目标数据对应的处理任务；将所述预设数据表中所述目标数据对应的状态更新为处理中。

在一种可能的设计中，所述处理模块通过如下方式得到预设数据表：先接收数据处理请求，所述数据处理请求中包括账户信息和时间信息；再获取所述账户信息对应的各条备选数据，从所述各条备选数据中确定出位于所述时间信息范围内的各条数据，最后将所述各条数据添加在所述预设数据表中。

在一种可能的设计中，所述处理模块具体用于：按照生成时间由近及远的顺序从所述各条数据中选取一条未分析过的数据，根据所述数据对应的第三数据值和所述账户在当前时刻对应的第四数据值，确定所述数据对应的第一数据值，将所述数据、所述账户信息和所述第一数据值添加在所述预设数据表中，并设置所述预设数据表中所述数据的状态为待处理，循环执行上述内容直至所述各条数据中不存在未分析的数据。其中，所述第一数据值为所述第三数据值和所述第四数据值中取值较小的值。

第三方面，本申请提供一种计算设备，包括至少一个处理单元以及至少一个存储单元，其中，所述存储单元存储有计算机程序，当所述程序被所述处理单元执行时，使得所述处理单元执行第一方面任意所述的数据处理方法。

第四方面，本申请提供一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行第一方面任意所述的数据处理方法。

本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

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

图1示例性示出一种数据处理系统的系统架构示意图；

图2示例性示出本申请实施例提供的一种数据处理方法的流程示意图；

图3示例性示出本申请实施例提供的一种退款处理方法的流程示意图；

图4示例性示出本申请实施例提供的一种各模块的工作方式的交互示意图；

图5示例性示出本申请实施例提供的另一种各模块的工作方式的交互示意图；

图6示例性示出本申请实施例提供的又一种各模块的工作方式的交互示意图；

图7示例性示出本申请实施例提供的一种数据处理装置的结构示意图；

图8示例性示出本申请实施例提供的一种计算设备的结构示意图。

具体实施方式

下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

图1为本发明实施例提供的一种数据处理系统的架构示意图，如图1所示，该数据处理系统中可以包括银行节点110、第三方支付机构120、服务器集群130和至少一个客户端，例如客户端141、客户端142和客户端143。其中，银行节点110可以与第三方支付机构120通信连接，第三方支付机构120可以与服务器集群130通信连接，服务器集群130可以与至少一个客户端中的每个客户端通信连接。通信连接的方式可以为有线通信连接，也可以为无线通信连接，不作限定。

如图1所示，服务器集群130中可以包括并行设置的多个处理服务器，例如处理服务器1311、处理服务器1312和处理服务器1313。示例性地，服务器集群130中还可以包括负载均衡服务器132。当同时包括负载均衡服务器132和多个处理服务器时，负载均衡服务器132可以分别与每个客户端和每个处理服务器连接。

本申请实施例中，客户端可以是指能够与用户交互的任意用户设备，例如手机、平板电脑、台式机、可穿戴手环等。且，客户端与用户交互的方式不限于触屏、语音、遥控、脑电波。

基于图1所示意的退款处理系统，图2示例性示出本申请实施例提供的一种数据处理方法的流程示意图，该方法适用于处理服务器，例如图1所示意的处理服务器1311、处理服务器1312或处理服务器1313，又例如图1所示意的服务器集群130。如图2所示，该方法包括：

步骤201，处理服务器根据预设数据表中的各个账户，确定目标账户。

本申请实施例中，在预设数据表中存在两个或两个以上的账户时，处理服务器可以从两个或两个以上的账户中随机选择一个账户作为目标账户，也可以按照各个账户的数据添加到预设数据表中的时间顺序选择目标账户。在每个目标账户中的一条数据被处理时，处理服务器可以再从预设数据表中选择下一个目标账户进行处理，以并行执行数据处理的过程和账户分析的过程，提高数据处理的效率。

在一种可选地实施方式中，预设数据表可以通过如下方式构建得到：

处理服务器接收至少一个客户端发送的数据处理请求，该数据处理请求中可以包括账户信息和时间信息，根据数据处理请求中的账户信息，获取该账户信息对应的各条备选数据，然后根据数据处理请求中的时间信息，从各条备选数据中确定出位于时间信息范围内的各条数据，将各条数据添加在预设数据表中。

示例性地，数据处理请求中包括的时间信息可以同时包括起始时间节点和终止时间节点，也可以仅包括起始时间节点。处理服务器中还可以设置有预设的时长阈值，若数据处理请求中包括起始时间节点和终止时间节点，且两者之间的时长大于时长阈值，则处理服务器可以根据终止时间节点选择时长阈值对应的时间节点作为最终的起始时间节点，并将各条备选数据中位于该最终的起始时间节点和终止时间节点之间的备选数据作为该账户对应的各条备选数据。若数据处理请求中仅包括起始时间节点，则处理服务器可以计算起始时间节点至当前时间节点之间的时长，若该时长大于时长阈值，则根据当前时间节点选择时长阈值对应的时间节点作为最终的起始时间节点，并将各条备选数据中位于该最终的起始时间节点和当前时间节点之间的备选数据作为该账户对应的各条数据。

在一种可选地实施方式中，处理服务器在获取该账户的各条数据后，可以按照生成时间由近及远的顺序从各条数据中选取一条未分析过的数据，将该数据对应的第三数据值和该账户在当前时刻对应的第四数据值中取值较小的作为该数据对应的第一数据值，然后将该数据、该账户信息和第一数据值添加在预设数据表中，并设置预设数据表中该数据的状态为待处理。在该条数据分析完成后，再按照生成时间由近及远的顺序从各条数据中选取一条未分析过的数据，重复循环执行上述内容直至各条数据中不存在未分析的数据，则该账户对应的各条数据即添加在预设数据表中。

本申请实施例中，若处理服务器同时收到至少两个客户端发送的数据处理请求，则处理服务器可以按照单线程依次处理每个客户端发送的数据处理请求，也可以创建多个线程，采用多个线程并行地处理至少两个客户端发送的数据处理请求，以提高数据处理的效率。

步骤202，处理服务器获取目标账户对应的各条数据，从各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对目标数据进行处理，并将目标数据的状态更新为处理中。

在一种可选地实施方式中，处理服务器获取目标账户对应的各条数据后，可以从预设数据表中查询该目标账户的各条数据的状态，若该目标账户的各条数据中不存在状态为处理中的数据，则可以从各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对目标数据进行处理，并将目标数据的状态更新为处理中，然后根据预设数据表中的各个账户，重新确定所述目标账户。若该目标账户的各条数据中存在状态为处理中的数据，则可以根据预设数据表中的各个账户，重新确定所述目标账户。如此，处理服务器可以避免对当前存在处理任务的账户的数据进行处理，以尽可能地保证某一账户的当前数据处理完成之后再处理下一条数据，有助于该账户的各条数据能够准确按照生成时间由近及远的顺序被处理。且，在当前账户存在处理任务的情况下，通过转为处理其它账户，使得处理服务器在等待当前账户的数据的处理结果的同时能够并行处理其它账户的数据，有助于提高数据的处理效率。

示例性地，处理服务器可以按照如下方式处理目标数据：从预设数据表中查询得到目标数据对应的第一数据值，获取目标账户在当前时刻对应的第二数据值，若第一数据值不大于第二数据值，则根据第一数据值生成目标数据对应的处理任务，若第一数据值大于第二数据值，则根据第二数据值生成目标数据对应的处理任务，将处理任务发送给第三方支付机构，以由第三方支付机构发送给银行节点进行处理。且，处理服务器还将预设数据表中所述目标数据对应的状态更新为处理中，因此后续在重新处理该目标账户时，只要该数据没有处理完成，则该数据的状态始终为处理中，处理服务器即不会对该目标账户进行处理，有助于保证该目标账户中的数据按照生成时间由近及远的顺序被依次处理。

步骤203，处理服务器在得到目标数据对应的处理结果后，判断：

若处理结果为处理失败，则执行步骤204；

若处理结果为处理成功，则执行步骤205。

在一种可选地实施方式中，处理服务器得到处理任务之后，还可以校验处理任务，若校验失败，则确定处理结果为处理失败，若校验成功，则可以将处理任务发送给第三方支付机构，以由第三方支付机构进行校验。若第三方支付机构校验失败，则处理服务器可以收到第三方支付机构响应的校验失败的信息，则确定处理结果为处理失败。若第三方支付机构校验成功，则第三方支付机构可以将处理任务发送给银行节点，由银行节点对处理任务进行处理，并在处理完成后，将处理结果通过第三方支付机构发送给处理服务器。

步骤204，处理服务器将预设数据表中目标数据的状态更新为处理失败，并将各条数据中生成时间位于目标数据之前的数据的状态更新为无需处理。

本申请实施例中，如果目标账户中有一条数据处理失败，则处理服务器也不再处理生成时间位于该数据的生成时间之前的数据，而是等待下次处理时该条数据处理成功后再处理。采用这种方式，处理服务器能够准确按照生成时间由近及远的顺序处理目标账户中的数据，避免在某条数据还没处理时把生成时间早的数据先处理掉而后续在处理该数据时出错的问题。

步骤205，处理服务器将预设数据表中目标数据的状态更新为处理成功。

在一种可选地实施方式中，步骤201和步骤202、步骤203至步骤205可以是并行执行的，即处理服务器在一个线程上对预设数据表中的账户的数据进行分析，在另一个线程上获取数据的处理结果并更新预设数据表。如此，能够进一步提高数据处理的效率。

本申请的上述实施例中，处理服务器从预设数据表中目标账户对应的各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对目标数据进行处理，并将目标数据的状态更新为处理中，在得到目标数据对应的处理结果后：若处理结果为处理失败，则将预设数据表中目标数据的状态更新为处理失败，并将各条数据中生成时间位于目标数据之前的数据的状态更新为无需处理，若处理结果为处理成功，则将预设数据表中目标数据的状态更新为处理成功。本申请实施例中，通过设置预设数据表，并在预设数据表中设置各条数据的状态，使得处理服务器能够准确把控每条数据的处理进度，例如该条数据是处于处理中、待处理、处理成功、处理失败还是无需处理。如此，在已知各条数据的状态的条件下，处理服务器能够按照生成时间由近及远的顺序准确处理各条数据，从而适用于用户对多条数据的处理时间存在需求的场合，有助于提高数据处理的灵活性。

下面示例性地以退款场景为例介绍本申请实施例中的数据处理方法，在该示例中，处理服务器用于对转入还款账户中的资金进行退款，预设数据表对应为退款记录表。

下面先对退款场景中涉及到的部分术语进行介绍。

1、还款账户。

本申请实施例中，还款账户是针对于用户的贷款业务而设置，例如用户在银行A中贷款了10万元，则银行A会为用户开立还款账户，用户需要每月按时从自己的其他账户中转存固定的还款金到还款账户上。到用户设置的还款日时，银行A就会自动从用户的还款账户上把钱扣下来，并对应减少用户的欠款。这样，当用户还款至10万元时，由于欠款还清，因此还款账户可以作废。不同的贷款产品可以对应不同的还款账户，例如房贷对应房贷还款账户，车贷对应车贷还款账户。

2、账户的剩余余额和账户的可用余额。

本申请实施例中，账户的剩余余额是指账户中实际存储的金额，账户的可用余额是指账户能够用于退款的金额。例如在账户的剩余余额为100的情况下，如果账户已确定需要执行金额为50的退款，那么账户的可用余额为50。

下列实施例中的退款处理方法适用于还款账户，还款账户是指专门用于还款的账户，而无法用于其它支付行为。基于此，如果用户不小心向还款账户转错了钱，那么用户实际上并没有办法对还款账户中的钱进行退款处理，这种情况下，用户只能联系银行进行核实，导致还款处理的过程非常复杂，用户的体验不好。

图3示例性示出本申请实施例提供的一种退款处理方法的流程示意图，该方法适用于处理服务器，例如图1所示意的处理服务器1311、处理服务器1312或处理服务器1313，又例如图1所示意的服务器集群130。如图3所示，该方法包括：

步骤301，处理服务器接收退款请求，退款请求中包括待退款的账户信息和退款时间信息。

在一种可选地实施方式中，每个客户端上可以设置有还款APP，用户通过登录还款APP来执行还款操作。当用户发现自己还款操作出错后，用户可以登录还款APP，然后点击还款APP界面上的退款按钮，并填写待退款的账户信息和退款时间信息。其中，待退款的账户信息可以是指还款账户的账号，例如银行卡号。退款时间信息可以是指一个时间节点，该时间节点用于指示用户想对从该时间节点到当前时间节点之间的所有入账流水都执行退款。或者，退款时间信息可以也可以是指一个时间节点区间，该时间节点区间用于指示用户想要对该时间节点区间中的所有入账流水执行退款。

本申请实施例中，当用户填写完待退款的账户信息和退款时间信息，并点击提交按钮后，客户端可以根据用户填写的这些信息生成退款请求，然后将退款请求发送给处理服务器。示例性的，如果退款处理系统如图1所示，则客户端实际上可以先将退款请求发送给负载均衡服务器132，这种情况下，负载均衡服务器132可以先获知各个处理服务器的可用情况，例如中央处理器(central processing unit，CPU)的缓存情况、内存空间的可用情况等，然后从处理服务器1311至处理服务器1313中选择最为空闲的处理服务器作为目标服务器，并将退款请求发送给目标服务器进行退款处理。采用这种方式，用户的退款请求每次都能够发送给较为空闲的处理服务器进行处理，有助于减少用户等待退款的时间。

步骤302，处理服务器对退款请求进行校验：

若校验不通过，则执行步骤303；

若校验通过，则执行步骤304。

本申请实施例中，用户可以是指个人用户，也可以是指企业用户。当用户为企业用户时，该企业中的所有员工都可以登录该企业用户对应的还款APP，但是不同的员工存在不同的权限。

在一种可选地实施方式中，处理服务器对退款请求进行校验，可以包括以下内容中的一项或多项：

一、处理服务器校验当前登录的用户的支付密码是否正确。

在用户为企业用户的情况下，如果用户的支付密码不正确，则说明该员工涉嫌违规操作，这种情况下，处理服务器对退款请求的校验不通过。

二、处理服务器查询退款记录表中处于待处理状态或处理中状态的全部入账流水中是否存在待退款的账户对应的入账流水。

本申请实施例中，退款记录表用于存储待退款或已退款的入账流水，每条入账流水的状态存在5种可能状态：待处理、处理中、处理失败、处理成功、无需处理。如果退款记录表中存在某个账户对应的入账流水处于待处理状态或处理中状态，则说明该账户目前正在处理一笔退款，这种情况下，如果同时执行该账户对应的新的退款，那么可能会存在该账户在正在处理的退款处理完之后剩余的金额无法再执行新的退款的情况。为了解决这个问题，本申请实施例设置同一时段内只有一个退款请求被处理。在这种情况下，如果退款记录表中处于待处理状态或处理中状态的全部入账流水中存在待退款的账户对应的入账流水，则处理服务器对退款请求的校验不通过。

关于入账流水表的相关内容，将在以下的实施例中进行具体描述，此处先不作过多介绍。

第三，处理服务器判断待退款的账户中的余额是否小于设定金额。

本申请实施例中，设定金额用于指示待退款的账户的退款能力，设定金额可以由本领域技术人员根据经验进行设置，例如可以为0，也可以为稍大于0的数。当待退款的账户中的余额小于设定金额时，待退款的账户不具有退款能力，因此处理服务器对退款请求的校验不通过。当待退款的账户中的余额不小于设定金额时，待退款的账户具有退款能力，因此处理服务器对退款请求的校验可以通过，当然也可以执行其它内容的校验。

第四，处理服务器确定当前登录还款APP的用户是否具有还款权限。

在一种可选地实施方式中，处理服务器可以查询当前登录的员工的身份，如果员工的身份属于不具有还款能力的员工身份(例如公司其它员工)，则处理服务器对退款请求的校验可以通过。如果员工的身份属于具有还款能力的员工身份(例如公司法人)，则处理服务器对退款请求的校验可以通过，也可以执行其它内容的校验。当然，这只是一种可选地实施方式，在其它可选地实施方式中，处理服务器也可以通过其它方式确定登录还款APP的用户是否具有还款权限，例如可以校验用户上传的身份证信息确定该用户是否具有还款权限，也可以通知用户输入校验码确定该用户是否具有还款权限等。

在一种可选地实施方式中，为了保证校验的准确性，处理服务器可以对退款请求执行上述4种校验内容。当处理服务器对退款请求执行上述4种校验内容时，退款请求校验通过，具体可以包括以下内容：用户的支付密码正确，且退款记录表中处于待处理状态或处理中状态的全部入账流水中不存在待退款的账户对应的入账流水，且待退款的账户中的余额不小于设定金额，且当前登录还款APP的用户具有还款权限。对应的，退款请求校验不通过，具体可以包括以下内容：用户的支付密码错误，且退款记录表中处于待处理状态或处理中状态的全部入账流水中存在待退款的账户对应的入账流水，且待退款的账户中的余额小于设定金额，且当前登录还款APP的用户不具有还款权限。

步骤303，处理服务器向客户端发送退款失败的消息。

在一种可选地实施方式中，当导致校验不通过的校验内容不同时，对应的退款失败的消息也不同，例如：

若是由于用户的支付密码错误导致校验不通过，则退款失败的消息可以为“支付密码错误”，这样，如果用户是因为不小心输错了支付密码导致校验失败，那么用户还可以重新输入正确的支付密码以重新发起退款；或者，

若是由于退款记录表中处于待处理状态或处理中状态的全部入账流水中存在待退款的账户对应的入账流水导致校验不通过，则退款失败的消息可以为“当前存在正在处理的退款，暂时无法发起退款”，这样，用户可以获知自己等待一段时间后能够重新发起退款；或者，

若是由于待退款的账户中的余额小于设定金额导致校验不通过，则退款失败的消息可以为“账户余额不足”，这样，如果用户必须执行退款，则用户可以先向账户转入部分资金再重新发起退款；或者，

若是由于当前登录还款APP的用户不具有还款权限导致校验不通过，则退款失败的消息可以为“权限不足”，这样，如果用户必须执行退款，则用户可以委托其他具有退款权限的员工以重新发起退款。

步骤304，处理服务器从待退款的账户对应的入账流水中获取与退款时间信息匹配的目标入账流水。

本申请实施例中，各个账户对应的入账流水都可以储存在入账流水数据库中，这种情况下，处理服务器可以先从入账流水数据库中筛选出待退款的账户对应的入账流水，然后从这些入账流水中筛选出与退款时间信息匹配的目标入账流水。

在一种可选地实施方式中，与退款时间信息匹配的目标入账流水，具体可以是指：

入账流水的发生时间位于该退款时间信息所限定的时间范围内，例如在用户选择一个起始时间节点和一个终止时间节点的情况下，当退款时间信息对应为时间节点范围2020.06.01～2020.06.11，则与退款时间信息匹配的入账流水可以是指2020.06.01～2020.06.11的时间范围内待退款的账户产生的全部的入账流水。或者在用户只选择一个起始时间点的情况下，当退款时间信息对应为起始时间节点为2020.06.01，当前时间节点为2020.06.21，则与退款时间信息匹配的入账流水可以是指2020.06.01～2020.06.21的时间范围内待退款的账户产生的全部的入账流水；或者，

入账流水的发生时间位于预设的时间跨度范围和退款时间信息所限定的时间范围的交集内，其中交集是指与当前时间距离最近的交集，例如在用户选择一个起始时间节点和一个终止时间节点的情况下，当退款时间信息对应为时间节点范围2020.06.01～2020.06.11，预设的时间跨度范围为3天，则与退款时间信息匹配的入账流水可以是指2020.06.09～2020.06.11的时间范围内待退款的账户产生的全部的入账流水。或者在用户只选择一个起始时间点的情况下，当退款时间信息对应为起始时间节点为2020.06.01，当前时间节点为2020.06.21，预设的时间跨度范围为3天，则与退款时间信息匹配的入账流水可以是指2020.06.19～2020.06.21的时间范围内待退款的账户产生的全部的入账流水。这种方式将距离当前时间最近的入账流水作为待退款的入账流水，使得退款操作能够从最近发生的入账交易开始执行，有助于提高退款的实时性和准确性。

步骤305，处理服务器按照时间由近及远的顺序从未处理的目标入账流水中取出一条目标入账流水：

若当前存在未处理的目标入账流水，则处理服务器对取出的目标流水执行步骤306至步骤307；或者，

若当前不存在未处理的目标入账流水，则处理服务器执行步骤308。

本申请实施例中，目标入账流水的时间近是指目标入账流水的入账时间与当前时间的时间差小，目标入账流水的时间远是指目标入账流水的入账时间与当前时间的时间差大。

步骤306，处理服务器判断该条目标入账流水是否满足预设的退款条件，若不满足，则执行步骤305，若满足，则执行步骤307。

在一种可选地实施方式中，处理服务器可以先判断目标入账流水是否满足预设的终止处理规则，若目标入账流水满足预设的终止处理规则，则可以直接终止处理该账户，即对该账户中没有处理的入账流水也不再处理，进而重新选择其他账户进行处理。若目标入账流水不满足预设的终止处理规则，则可以再判断目标入账流水是否满足预设的忽略处理规则，若目标入账流水满足预设的忽略处理规则，则确定目标入账流水不满足预设的退款条件，处理服务器可以直接忽略该条入账流水，继续处理该账户的下一笔入账流水，若目标入账流水不满足预设的忽略处理规则，则确定目标入账流水满足预设的退款条件。

示例性地，终止处理规则可以包括以下内容：

目标入账流水已存储在退款记录表中，且目标入账流水的状态为处理成功；或者，

目标入账流水存储在退款记录表中。

当满足上述终止处理规则时，对于未处理的其它目标入账流水，处理服务器也可以不再分析。这种情况适用于每次退款时处理服务器都是按照时间由近及远的顺序分析目标入账流水，如此，只要存在一条目标入账流水已被退款处理过，那么位于该条目标入账流水的入账时间之前的目标入账流水(即未处理的其它目标入账流水)都已被退款处理过，因此此次可以不再分析这些目标入账流水。

可以理解的，上述内容只是示例性介绍几种可能的终止处理规则，至于规则的具体内容，可以由用户根据实际需求进行设置，本申请对此不作限定。

示例性地，忽略处理规则可以包括以下内容：

目标入账流水的转出方账户为待退款的账户所在的银行；在这种情况下，该条目标入账流水对应为该用户在待退款的账户所在的银行的一条借款入账，这笔入账的存在不会影响其它入账，因此处理服务器可以不对该条入账流水进行退款操作，并可以继续选择一条新的目标入账流水。或者，

目标入账流水的转出方账户不是当前登录的用户名下的账户；在正常情况下，只有用户自己会向自己的还款账户(即待退款的账户)转入资金以用于还款操作，如果是其它用户转账到该用户的还款账户中，说明这笔资金存在问题，例如可能是其它用户转错了账户，或者是银行系统故障导致。为了避免对存在问题的入账流水进行退款，当满足上述条件，则处理服务器可以直接确定目标入账流水不满足预设的退款条件。或者，

目标入账流水已存储在退款记录表中，且目标入账流水的状态为处理成功；在这种情况下，如果目标入账流水已存储在退款记录表中，且目标入账流水的状态为处理成功，则说明目标入账流水已经被退款成功，为了防止重复退款，当满足上述条件，则处理服务器也可以直接确定目标入账流水不满足预设的退款条件。或者，

目标入账流水存储在退款记录表中；在这种情况下，只要用户之前已经对该目标入账流水执行过退款处理，则无论用户是否退款成功，后续都不再对该条目标入账流水进行退款。这种情况是考虑到如下场景：在银行系统不故障的情况下，用户执行的退款操作大概率都会成功，只有在用户向还款账户转入了资金之后立马销户的情况下用户的退款操作才会失败。基于此，如果是这种场景导致的退款失败，那么后续再执行退款也不会成功。因此，当满足上述条件，则处理服务器也可以直接确定目标入账流水不满足预设的退款条件。

在一种可选地实施方式中，目标入账流水不满足忽略处理规则，可以包括以下内容：

目标入账流水的转出方账户为当前登录的用户名下的账户，目标入账流水未存储在退款记录表中。这种情况用于指示该条目标入账流水为用户从自己的其它账户中转出资金至待退款的账户中，且用户之前没有对该目标入账流水执行过退款处理；或者，

目标入账流水的转出方账户为当前登录的用户名下的账户，且目标入账流水存储在退款记录表中，目标入账流水的状态为处理失败或无需处理。这种情况用于指示该条目标入账流水为用户从自己的其它账户中转出资金至待退款的账户中，且用户之前虽然对该目标入账流水执行过退款处理，但是并没有退款成功。

可以理解的，上述内容只是示例性介绍几种可能的忽略处理规则，至于规则的具体内容，可以由用户根据实际需求进行设置，本申请对此不作限定。

步骤307，处理服务器根据该条目标入账流水对应的入账金额和待退款的账户的可用余额，确定该条目标入账流水对应的退款金额，将该条目标入账流水、该条目标入账流水对应的账户和退款金额添加到退款记录表中，且将退款记录表中该条目标入账流水的状态设置为待处理。

本申请实施例中，当目标入账流水对应的入账金额不大于待退款的账户的可用余额，则待退款的账户的可用余额能够支持对目标入账流水进行退款，这种情况下，目标入账流水对应的退款金额为目标入账流水对应的入账金额。当目标入账流水对应的入账金额大于待退款的账户的可用余额，则待退款的账户的可用余额无法支持对目标入账流水进行退款，这种情况下，目标入账流水对应的退款金额为待退款的账户的可用余额。且，在将目标入账流水及其对应的退款金额添加到退款记录表之后，还可以将待退款的账户的可用余额更新为待退款的账户的可用余额与目标入账流水对应的退款金额的差。这样，只要不出现中途从待退款的账户中转出其它金额的情况，待退款的账户的剩余余额就能够按照设置的退款金额依次退款，直至待退款的账户的剩余余额为0，或者待退款的目标入账流水都退款完成。

需要说明的是，“将每一条目标入账流水实时添加到退款记录表中”仅是一种可选地实施方式，在另一种可选地实施方式中，也可以先设置一个待退款列表，当某一条目标入账流水满足退款条件后，先将该条目标入账流水添加到待退款列表中，并继续分析下一条目标入账流水，当待退款的账户对应的全部目标入账流水都分析完之后，再将待退款列表中的退款记录添加到退款记录表中。上面的实施方式是按照一个入账流水一个入账流水的顺序进行分析，可能使得退款记录表中相邻的两个入账流水属于生成时间较为接近的不同账户。而这种实施方式是按照一个账户一个账户的顺序进行分析，使得退款记录表中相邻的两个入账流水属于生成时间较为接近的同一账户，这种方式能够实现账户级别的退款入表。

下面举一个具体的例子对步骤301至步骤307的实现过程进行介绍：

表1示例性示出一种当前时段的退款记录表。可以理解的，表1所示意出的退款记录表只是一种示例，在其它的示例中，退款记录表还可以包括退款申请时间、退款请求金额、退款交易时间等。

账户	入账流水号	退款状态	退款金额	入账时间
					A	11	处理中	50	2020.06.09-10:00
B	21	待处理	10	2020.06.09-9:00
					B	22	处理成功	30	2020.06.10-12:00
C	31	无需处理	10	2020.06.09-10:00
					C	32	无需处理	20	2020.06.09-14:00
C	33	处理失败	50	2020.06.10-15:00
					C	34	处理成功	45	2020.06.10-17:00

表1

如表1所示，当前时段下，账户A、账户B和账户C都存在要退款的入账流水，账户A中存在一条正在退款中的入账流水11，账户B中存在一条待退款的入账流水21和一条已经退款成功的入账流水22，账户C中存在两条无需退款的入账流水31和入账流水32，以及一条退款失败的入账流水33和一条已经退款成功的入账流水34。

表2示例性示出一种账户A、账户B和账户C对应的目标入账流水表。

账户	入账流水号	入账金额	入账时间
				A	11	50	2020.06.09-10:00
B	21	10	2020.06.09-9:00
				B	22	30	2020.06.10-12:00
C	31	10	2020.06.09-10:00
				C	32	20	2020.06.09-14:00
C	33	50	2020.06.10-15:00
				C	34	45	2020.06.10-17:00

表2

如表2所示，当账户A的用户发起退款请求，退款请求指示对入账流水号11的入账金额进行退款，则由于当前时段的退款记录表1中存在入账流水号11，且入账流水号11的状态为正在处理，说明当前时段正在对入账流水号11进行退款操作，因此处理服务器可以向用户显示“入账流水号11当前存在正在处理的退款，暂时无法发起退款”的退款失败的消息；

当账户B的用户发起退款请求，退款请求指示对入账流水号21的入账金额和入账流水号22的入账金额进行退款，由于入账流水号22的入账时间位于入账流水号21之后，因此可以先对入账流水号22进行分析再对入账流水号21进行分析。由于当前时段的退款记录表1中存在入账流水号22，且入账流水号22的状态为处理成功，说明当前时段之前已经对入账流水号22成功进行退款操作，因此处理服务器可以向用户显示“入账流水号22请勿重新退款”或“退款请求处理中，请稍等再试”或其它显示内容的退款失败的消息。且，一种情况下，由于时间较近的入账流水号22已被分析过，因此入账流水号21也就不用再分析了。另一种情况下，为了防止入账流水号21在之前的分析中没有退款，因此即使时间较近的入账流水号22已被分析过，入账流水号21也可以被分析。在这种情况下，由于当前时段的退款记录表1中存在入账流水号21，且入账流水号21的状态为待处理，说明当前时段正在等待对入账流水号21进行退款操作，因此处理服务器可以向用户显示“入账流水号21当前存在正在处理的退款，暂时无法发起退款”或“退款请求处理中，请稍等再试”或其它内容的退款失败的消息；

当账户C的用户发起退款请求，退款请求指示对入账流水号31的入账金额、入账流水号32的入账金额、入账流水号33的入账金额和入账流水号34的入账金额进行退款，则由于按照入账时间由远及近的顺序依次为入账流水号34、入账流水号33、入账流水号32和入账流水号31，因此可以先对入账流水号34进行分析，再对入账流水号33进行分析，再对入账流水号32进行分析，最后对入账流水号31进行分析。由于当前时段的退款记录表1中存在入账流水号34，且入账流水号34的状态为处理成功，说明当前时段之前已经对入账流水号34成功进行退款操作，因此处理服务器可以向用户显示“入账流水号34请勿重新退款”或“退款请求处理中，请稍等再试”或其它内容的退款失败的消息。

一种情况下，由于时间较近的入账流水号34都已被分析过，因此入账流水号33、入账流水号32和入账流水号31也就不用再分析了。另一种情况下，为了防止入账流水号33、入账流水号32和入账流水号31在之前的分析中没有退款，因此即使时间较近的入账流水号34已被分析过，入账流水号33、入账流水号32和入账流水号31也可以被分析。在这种情况下，由于当前时段的退款记录表1中存在入账流水号33，且入账流水号33的状态为处理失败，说明当前时段之前由于某种故障导致等待退款的入账流水号33没能成功退款，因此处理服务器可以将入账流水号33添加在退款记录表中，或者也可以考虑到用户销户的情况，直接向用户返回“某种故障导致入账流水号33退款失败”的退款失败的消息。且，由于当前时段的退款记录表1中存在入账流水号32和入账流水号31，且入账流水号32和入账流水号31的状态均为无需处理，说明当前时段之前入账流水号32和入账流水号31都没能成功退款，因此处理服务器可以将入账流水号32和入账流水号31添加在退款记录表中，或者也可以考虑到用户销户的情况，直接向用户返回“某种故障导致入账流水号32和入账流水号31退款失败”的退款失败的消息。或者，在另一种情况下，考虑到这两条入账流水虽然没有退款成功，但是实际上已经存储在退款记录表中，只是没有处理，因此也还是可以向用户返回“退款请求成功”的消息。

表3示例性示出另一种账户C对应的目标入账流水表。

账户	入账流水号	入账金额	入账时间
				C	31	10	2020.06.09-10:00
C	32	20	2020.06.09-14:00
				C	33	50	2020.06.10-15:00
C	34	45	2020.06.10-17:00
				C	35	70	2020.06.11-13:00
C	36	22	2020.06.11-15:00

表3

如表3所示，当账户C的用户发起退款请求，退款请求指示对入账流水号34的入账金额、入账流水号35的入账金额、入账流水号36的入账金额进行退款，则由于按照入账时间由远及近的顺序依次为入账流水号36、入账流水号35和入账流水号34，因此可以先对入账流水号36进行分析，再对入账流水号35进行分析，再对入账流水号34进行分析。在账户C的剩余金额为80的情况下，由于当前时段的退款记录表1中不存在入账流水号36和入账流水号35，因此处理服务器可以将入账流水号36及其对应的退款金额(取可用余额80和入账金额22之中的较小值，即22)和入账流水号35及其对应的退款金额(可用余额更新为58，取可用余额58和入账金额70之中的较小值，即58)添加到退款记录表中，并将入账流水号36和入账流水号35的状态设置为待处理，如表4所示。由于当前时段的退款记录表1中存在入账流水号34，且入账流水号34的状态为处理成功，说明当前时段之前已经对入账流水号34成功进行退款操作，因此处理服务器可以向用户显示“入账流水号34请勿重新退款”的退款失败的消息。或者，在另一种情况下，考虑到这条入账流水虽然此次没有进行退款，但是实际上在其它的处理流程中已经成功退款，因此也还是可以向用户返回“退款请求成功”的消息。

账户	入账流水号	退款状态	退款金额
				A	11	处理中	50
B	21	待处理	100
				B	22	处理成功	30
C	31	无需处理	50
				C	32	无需处理	100
C	33	处理失败	20
				C	34	处理成功	70
C	35	待处理	58
				C	36	待处理	22

表4

步骤308，处理服务器执行多轮退款任务操作，在相邻的两轮退款任务操作中，前一轮退款任务操作执行完之后等待预设的时间间隔之后再启动下一轮退款任务操作。其中，预设的时间间隔可以根据用户的需求进行设置，例如可以设置为1分钟或2分钟。

针对于每轮退款任务操作，处理服务器执行步骤309至步骤315。

步骤309，处理服务器从退款记录表中本轮退款任务操作还未分析过的账户中选择出一个目标账户，对退款记录表中目标账户对应的目标入账流水进行分析：

当目标账户对应的目标入账流水中存在状态为处理中的目标入账流水，则说明该目标入账流水之前已经发起过退款，且当前该退款还未处理完成，这种情况下，该笔目标入账流水可能会退款成功也可能会退款失败，而这两种退款结果会使得目标账户的可用余额发生变化，因此当前时段不能对该账户的其他目标入账流水执行退款操作。这种情况下，执行步骤309，即处理服务器先转而去分析其他账户的目标入账流水，在下一轮退款任务操作时，如果该目标账户对应的该笔目标入账流水执行完成，则可以再对该目标账户的其他目标入账流水执行退款操作。或者，

当目标账户对应的目标入账流水中不存在状态为处理中的目标入账流水，则执行步骤310。

需要说明的是，本申请实施例中，处理服务器可以按照时间由近及远的顺序选择目标账户，也可以随机选择目标账户。因为在一个退款任务操作中会轮询对所有的账户都分析一次，所以如何选择目标账户对于本轮退款任务操作的执行结果没有本质的区别。

步骤310，处理服务器可以按照时间由近及远的顺序从目标账户对应的目标入账流水中选择一条还未分析过的目标入账流水，判断退款记录表中该条目标入账流水的状态：

若该条目标入账流水的状态为处理成功(说明该条目标入账流水在之前的退款任务操作中已退款成功，该条目标入账流水无需重复退款)，则执行步骤310；或者，

若该条目标入账流水的状态为处理失败，则执行步骤311；或者，

若该条目标入账流水的状态为待处理，则执行步骤312。

步骤311，处理服务器将目标账户中生成时间在该条目标入账流水的生成时间之后的其它目标入账流水的状态更新为无需处理。

在一种可选地实施方式中，当目标入账流水的状态为处理失败，则说明该条目标入账流水在上一轮退款任务操作中退款失败，在时间较近的目标入账流水都没有成功退款的情况下，为了保证目标账户中的金额能够依次按照原路径被退回，这种情况下，处理服务器可以同样不对生成时间处于该退款失败的目标入账流水之后的目标入账流水进行退款处理。且，处理服务器还需要将这些没有处理的目标入账流水的状态由待处理更新为无需处理，如此，在用户后续重新对该目标账户发起退款请求时，处理服务器才能获知该目标账户中不存在待处理的入账流水，从而有助于用户后续的退款操作能够顺利进行。

步骤312，处理服务器根据目标账户的剩余金额和该条目标入账流水对应的退款金额，确定该条目标入账流水对应的可退金额，根据该条目标入账流水及其对应的可退金额生成该条目标入账流水对应的退款任务。且，由于该条目标入账流水已经启动退款流程，因此处理服务器还可以更新退款记录表中该条目标入账流水的状态为处理中。

本申请实施例中，当目标账户的剩余金额不小于目标入账流水对应的退款金额，则目标账户的剩余金额能够支持对该条目标入账流水进行退款，这种情况下，该条目标入账流水对应的可退金额为该条目标入账流水对应的退款金额。当目标账户的剩余金额小于该条目标入账流水对应的退款金额，则目标账户的剩余金额无法支持对该条目标入账流水进行退款，这种情况下，该条目标入账流水对应的可退金额为目标账户的剩余金额。

示例性的，当确定可退金额后，还可以在退款记录表中记录该目标入账流水对应的可退金额和退款金额，以便于后续根据退款记录表查询详细的退款数据。

本申请实施例中，处理服务器将该条目标入账流水对应的退款任务发送给第三方支付机构，以由第三方支付机构将退款任务发送给银行进行退款处理，处理服务器之后执行步骤309。在这种情况下，处理服务器在对目标账户中的一条目标入账流水生成退款任务后，即可不再分析该目标账户的其他目标入账流水，从而能够保证在同一时段内一个账号中只有一个目标入账流水的退款任务被执行，在这个目标入账流水的任务执行完成之后，再执行这个账号的其它目标入账流水。如此，即使在该条目标入账流水退款之后发生了转出交易，导致目标账户中的剩余余额无法再执行其它目标入账流水的退款，这种方式也能够在生成其它目标入账流水对应的退款任务之前识别出无法退款，从而有助于提高生成退款任务的准确性，提高退款成功的几率。

在一种可选地实施方式中，在处理服务器经由第三方支付机构与银行通信连接的情况下，该条退款任务到达银行之前会至少经过如下两次校验：

处理服务器的校验阶段，处理服务器对该条退款任务的合法性进行一次校验，例如校验该条退款任务的转入方账户名称和转入方机构类型是否一致，若一致(例如转出方账户名称为中国银行I类账户，转出方机构类型为中国银行)，则校验通过，处理服务器可以将该条退款任务发送给第三方支付机构，由第三方支付机构继续校验。若不一致(例如转出方账户名称为中国银行I类账户，转出方机构类型为中国工商银行)，则校验不通过，处理服务器直接确定该条退款任务退款失败，这种情况下，处理服务器可以直接更新退款记录表中该条目标入账流水的状态为处理失败，且还可以将目标账户中生成时间位于该条目标入账流水的生成时间之前的其他目标入账流水的状态更新为无需处理。

第三方支付机构的校验阶段，第三方支付机构对该条退款任务的合法性进行二次校验，例如校验该条退款任务的用户和转出方账户是否匹配，若匹配(例如转出方账户是退款任务的用户名下的账户)，则校验通过，第三方支付机构可以将该条退款任务发送给银行，由银行执行退款操作。若匹配(例如转出方账户不是退款任务的用户名下的账户)，则校验不通过，第三方支付机构可以直接向处理服务器响应退款失败的指示消息，这种情况下，处理服务器可以直接更新退款记录表中该条目标入账流水的状态为处理失败，且还可以将目标账户中生成时间位于该条目标入账流水的生成时间之前的其他目标入账流水的状态更新为无需处理。

本申请实施例中，上述仅是一种可选地实施方式，在另一种可选地实施方式中，处理服务器也可以直接与银行通信连接，而无需经由第三方支付机构转接银行。这种情况下，处理服务器如果对该条目标入账流水对应的退款任务校验成功，则可以直接将退款任务发送给银行，以由银行进行退款处理。

步骤313，处理服务器在执行退款任务操作(本轮或后续每轮)的过程中，还可以接收第三方支付机构发送的该条目标入账流水对应的退款结果，在退款记录表中该条目标入账流水对应的状态为处理中的情况下：

若该条目标入账流水对应的退款结果为退款成功，则执行步骤314；或者，

若该条目标入账流水对应的退款结果为退款失败，则执行步骤315。

步骤314，处理服务器将退款记录表中该条目标入账流水的状态更新为处理成功。

步骤315，处理服务器将退款记录表中该条目标入账流水的状态更新为处理失败，并可以将目标账户中生成时间位于该条目标入账流水的生成时间之前的其他目标入账流水的状态更新为无需处理。

在一种可选地实施方式中，处理服务器接收到的该条目标入账流水对应的退款结果还可能既不是退款成功也不是退款失败，而是待处理或处理中，这可能是由于银行与处理服务器之间的消息传递过程出现问题导致的。在这种情况下，为了保证退款处理的准确性，预防退款事故的发生，处理服务器还可以先不更新该条目标入账流水的状态，而是直接生成告警消息，并发送给第三方支付机构；或者如果处理服务器和第三方支付机构之间没有对应的告警接口，则处理服务器也可以生成告警日志，后续由运维人员告知给第三方支付机构，以由第三方支付机构进行核对确认后，再确定后续的退款流程。

在另一种可选地实施方式中，退款记录表中该条目标入账流水对应的状态还可能本来就是处理成功或处理失败，如果处理服务器又接收到该条目标入账流水对应的退款结果，则说明第三方支付机构可能重复对处理服务器发送了该条目标入账流水的两次退款结果消息，第三方支付机构的消息传递过程可能出现故障。在这种情况下：

如果该条目标入账流水对应的退款结果和退款记录表中该条目标入账流水对应的状态匹配，例如该条目标入账流水对应的退款结果为退款成功且退款记录表中该条目标入账流水对应的状态为处理成功，或者该条目标入账流水对应的退款结果为退款失败且退款记录表中该条目标入账流水对应的状态为处理失败，则处理服务器可以不更新退款记录表中该条目标入账流水对应的状态；或者，

如果该条目标入账流水对应的退款结果和退款记录表中该条目标入账流水对应的状态不匹配，例如该条目标入账流水对应的退款结果为退款成功且退款记录表中该条目标入账流水对应的状态为处理失败，或者该条目标入账流水对应的退款结果为退款失败且退款记录表中该条目标入账流水对应的状态为处理成功，则说明银行的退款过程可能出现故障，为了避免银行事故的发生，处理服务器也可以生成告警消息，并发送给第三方支付机构；或者如果处理服务器和第三方支付机构之间没有对应的告警接口，则处理服务器也可以生成告警日志，后续由运维人员告知给第三方支付机构，以由第三方支付机构和银行核对确认后，再确定后续继续的退款流程。

下面以表4所示意的退款记录表为例对退款过程进行详细的介绍。

在第一轮退款任务操作中，处理服务器先针对于账户C进行分析，由于账户C中不存在状态为处理中的入账流水，因此处理服务器可以先从账户C中选出一个生成时间最晚的入账流水36，由于入账流水36的状态为待处理，因此处理服务器可以基于入账流水36、对应的退款金额22和账户C的剩余金额生成入账流水36对应的退款任务，将该退款任务发送给第三方支付机构后，更新入账流水36的状态为处理中。

这时，由于账户C中存在一条正在处理的退款任务，且还未得到退款结果，因此处理服务器接下来不再对账户C进行分析，而是转而对账户B进行分析。由于账户B中不存在状态为处理中的入账流水，因此处理服务器可以先从账户B中选出一个生成时间最晚的入账流水22，入账流水22的状态为处理成功，说明入账流水22之前已经退款成功，因此处理服务器可以不再对入账流水22进行分析，而是转而对入账流水21进行分析。由于入账流水21的状态为待处理，因此处理服务器可以基于入账流水21、对应的退款金额100和账户B的剩余金额生成入账流水21对应的退款任务，将该退款任务发送给第三方支付机构后，更新入账流水21的状态为处理中。

这时，由于账户B中存在一条正在处理的退款任务，且还未得到退款结果，因此处理服务器接下来不再对账户B进行分析，而是转而对账户A进行分析。账户A中存在状态为处理中的入账流水11，说明账户A中有一条入账流水11正在进行退款处理，且还未得到退款结果，这种情况下，处理服务器可以不再对账户A进行分析。至此，退款记录表中的全部账户在第一轮退款任务操作中都被分析过一次，第一轮退款任务操作结束，这时对应的退款记录表更新为表5。

表5

一种可能的情形下，处理服务器等待预设的时间间隔后启动第二轮退款任务操作，如果在等待期间，处理服务器接收到第三方支付机构返回的入账流水11的退款结果为退款成功、入账流水21的退款结果为退款失败、入账流水36的退款结果为退款成功，则可以将退款处理表中入账流水11的状态更新为处理成功、入账流水21的状态更新为处理失败、入账流水36的状态更新为处理成功。接着，在第二轮退款任务操作中，处理服务器先针对于账户C进行分析，由于账户C中不存在状态为处理中的入账流水，因此处理服务器可以先从账户C中选出一个生成时间最晚的入账流水36，由于入账流水36的状态为处理成功，因此处理服务器可以不对入账流水36重复退款，而是可以再选出一个生成时间较晚的入账流水35，由于入账流水35的状态为待处理，因此处理服务器可以根据入账流水35、入账流水35对应的退款金额58和账户C的剩余金额生成入账流水35对应的退款任务，将该退款任务发送给第三方支付机构后，更新入账流水35的状态为处理中。对应的，账户B和账户A中都不存在待处理的入账流水，因此处理服务器可以不对账户B和账户A中的入账流水进行处理。更新后的退款记录表如表6所示。

表6

另一种可能的情形下，处理服务器等待预设的时间间隔后启动第二轮退款任务操作，如果在等待期间，处理服务器接收到第三方支付机构返回的入账流水11的退款结果为退款成功、入账流水36的退款结果为退款失败，则可以将退款处理表中入账流水11的状态更新为处理成功、入账流水36的状态更新为处理失败，由于账户C中处于待处理状态的入账流水中还存在生成时间晚于入账流水36的入账流水35，考虑到退款失败的原因可能是用户的转出账户销户，因此处理服务器还可以将退款处理表中入账流水35的状态更新为无需处理。接着，在第二轮退款任务操作中，账户C和账户A中不存在待处理的入账流水，账户B中存在一条处于处理中状态的入账流水，因此处理服务器可以不对账户C、账户B和账户A中的入账流水进行处理。更新后的退款记录表如表7所示。

账户	入账流水号	退款状态	退款金额
				A	11	处理成功	50
B	21	处理中	100
				B	22	处理成功	30
C	31	无需处理	50
				C	32	无需处理	100
C	33	处理失败	20
				C	34	处理成功	70
C	35	无需处理	58
				C	36	处理失败	22

表7

本申请实施例中，通过在退款请求中携带待退款的账户信息和退款时间信息，使得处理服务器能够对待退款的账户中处于退款时间信息范围内的入账流水依次进行退款操作，这种方式有助于实现账户级别的退款操作，能够适用于用户对账户上的多个入账流水具有退款需求的场合，灵活性较好。

在一种可选地实施方式中，还可以将模块化思想应用到本申请的退款处理方法中，以从更细粒度上实现账户级别的退款操作。基于模块化思想，还可以将图2所示意的退款方法流程划归为不同的模块来处理，其中，模块可以理解为微服务，也可以理解为服务器或芯片，还可以理解为服务器中的线程。示例性地，在一种可能的设计中，可以在处理服务器中设置退款请求处理模块、退款处理模块和退款结果模块，退款请求处理模块用于执行步骤301至步骤307中的方法，退款处理模块用于执行步骤308至步骤312中的方法，退款结果模块用于执行步骤313至步骤315中的方法。其中，退款处理模块中可以包括忽略处理子模块和终止处理子模块，忽略处理子模块用于使用忽略处理规则确定入账流水是否满足忽略处理的条件，而终止处理子模块用于使用终止处理规则确定入账流水是否满足终止处理的条件。本申请实施例中，退款请求处理模块、退款处理模块和退款结果模块之间的工作方式有多种，例如：

图4示例性示出第一种工作方式的交互流程图，在第一种工作方式中，退款请求处理模块、退款处理模块和退款结果模块并行执行各自的工作，且互不干涉。具体地说，退款请求处理模块负责接收不同客户端发送的退款请求，根据退款请求中的待退款的账户信息和退款时间信息确定待退款的入账流水，针对于每一条待退款的入账流水进行分析，当该条入账流水满足退款条件时，将该条入账流水添加到退款记录表中。退款处理模块负责按照预设的时间间隔定时对退款记录表中处于待处理的入账流水进行分析，每分析一轮之后，都间隔预设的时间间隔之后启动下一轮分析。退款结果模块负责接收第三方支付机构发送的退款结果，根据退款结果更新退款记录表中处于处理中的入账流水的状态。在这种工作方式中，虽然这三个模块互不干涉，但是各自之间分工明确，即使其中某一个模块故障，也不会影响其它模块的正常工作。

图5示例性示出第二种工作方式的交互流程图，在第二种工作方式中，退款请求处理模块、退款处理模块和退款结果模块之间相互通知自己的工作状态。具体地说，退款请求处理模块每根据一个客户端发送的退款请求将该退款请求对应的全部入账流水添加到退款记录表之后，都可以向退款处理模块发送第一指示信息，第一指示信息中携带有该客户端对应的待退款的账户的标识(例如账号)。对应的，退款处理模块接收到第一指示信息之后，可以从退款记录表中获取该待退款的账户对应的一条入账流水，生成该条入账流水对应的退款任务并发送给第三方支付机构。对应的，退款结果模块接收到第三方支付机构发送的该入账流水对应的退款结果后，除了可以更新退款记录表中该入账流水的状态之外，还可以向退款处理模块发送第二指示信息，第二指示信息中携带有该入账流水的标识(例如入账流水号)。对应的，退款处理模块接收到第二指示信息之后，可以继续处理该待退款的账户对应的其它入账流水。在这种工作方式中，这三个模块之间通过发送指示信息的方式相互协作，从而有助于提高退款处理的实时性。但是，这种方式下如果某一个模块故障，那么其它模块则接收不到该模块的指示信息，因此其它模块也一直不会处理其它入账流水，导致退款处理中断。

图6示例性示出第三种工作方式的交互流程图，在第三种工作方式中，退款请求处理模块、退款处理模块和退款结果模块之间并行执行各自的工作，且还可以相互通知自己的工作状态。这种方式下，如果退款处理模块接收到退款请求处理模块发送的第一指示信息，则可以按照上述第二种工作方式处理入账流水，同时，在处理完一个入账流水之后，即使没有接收到退款结果模块发送的第二指示信息，退款处理模块也可以按照上述第一种工作方式继续处理其它账户的入账流水，或者可以等待预设的间隔时间之后继续处理该账户的其它入账流水。这样，即使退款请求处理模块不向退款处理模块发送第一指示信息，或者即使退款结果模块不向退款处理模块发送第二指示信息，退款处理模块的处理过程也不会中断。这种方式既能够保证退款处理的实时性，又能够保证退款处理的持续可用。

针对上述方法流程，本发明实施例还提供一种数据处理装置，该装置的具体内容可以参照上述方法实施。

图7为本发明实施例提供的一种数据处理装置的结构示意图，如图7所示，该数据处理装置700包括：

确定模块701，用于根据预设数据表中的各个账户，确定目标账户；

处理模块702，用于获取所述目标账户对应的各条数据，从所述各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对所述目标数据进行处理，并将所述目标数据的状态更新为处理中；

更新模块703，用于在得到所述目标数据对应的处理结果后：

若所述处理结果为处理失败，则将所述预设数据表中所述目标数据的状态更新为处理失败，并将所述各条数据中生成时间位于所述目标数据之前的数据的状态更新为无需处理；或者，

若所述处理结果为处理成功，则将所述预设数据表中所述目标数据的状态更新为处理成功。

可选地，所述处理模块702从所述各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据之前，还用于：

确定所述各条数据中不存在状态为处理中的数据。

可选地，所述处理模块702还用于：

若所述各条数据中存在状态为处理中的数据，则根据预设数据表中的各个账户，重新确定所述目标账户。

可选地，所述处理模块702具体用于：

从所述预设数据表中查询得到所述目标数据对应的第一数据值；

获取所述目标账户在当前时刻对应的第二数据值；

若所述第一数据值不大于所述第二数据值，则根据第一数据值生成所述目标数据对应的处理任务；或者，

若所述第一数据值大于所述第二数据值，则根据第二数据值生成所述目标数据对应的处理任务；

将所述预设数据表中所述目标数据对应的状态更新为处理中。

可选地，所述处理模块702通过如下方式得到预设数据表：

接收数据处理请求；所述数据处理请求中包括账户信息和时间信息；

获取所述账户信息对应的各条备选数据，从所述各条备选数据中确定出位于所述时间信息范围内的各条数据；

将所述各条数据添加在所述预设数据表中。

可选地，所述处理模块702具体用于：

按照生成时间由近及远的顺序从所述各条数据中选取一条未分析过的数据，根据所述数据对应的第三数据值和所述账户在当前时刻对应的第四数据值，确定所述数据对应的第一数据值，将所述数据、所述账户信息和所述第一数据值添加在所述预设数据表中，并设置所述预设数据表中所述数据的状态为待处理；其中，所述第一数据值为所述第三数据值和所述第四数据值中取值较小的值；

循环执行上述内容直至所述各条数据中不存在未分析的数据。

从上述内容可以看出：本申请的上述实施例中，处理服务器从预设数据表中目标账户对应的各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对目标数据进行处理，并将目标数据的状态更新为处理中，在得到目标数据对应的处理结果后：若处理结果为处理失败，则将预设数据表中目标数据的状态更新为处理失败，并将各条数据中生成时间位于目标数据之前的数据的状态更新为无需处理，若处理结果为处理成功，则将预设数据表中目标数据的状态更新为处理成功。本申请实施例中，通过设置预设数据表，并在预设数据表中设置各条数据的状态，使得处理服务器能够准确把控每条数据的处理进度，例如该条数据是处于处理中、待处理、处理成功、处理失败还是无需处理。如此，在已知各条数据的状态的条件下，处理服务器能够按照生成时间由近及远的顺序准确处理各条数据，从而适用于用户对多条数据的处理时间存在需求的场合，有助于提高数据处理的灵活性。

基于同一发明构思，本发明实施例还提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如图2或图3中任一项所述的数据处理方法。

基于同一发明构思，本发明实施例还提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行如图2或图3中任一项所述的数据处理方法。

基于相同的技术构思，本发明实施例提供了一种计算设备，如图8所示，包括至少一个处理器1101，以及与至少一个处理器连接的存储器1102，本发明实施例中不限定处理器1101与存储器1102之间的具体连接介质，图8中处理器1101和存储器1102之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。

在本发明实施例中，存储器1102存储有可被至少一个处理器1101执行的指令，至少一个处理器1101通过执行存储器1102存储的指令，可以执行前述的基于分布式批量处理系统的处理方法中所包括的步骤。

其中，处理器1101是计算设备的控制中心，可以利用各种接口和线路连接计算设备的各个部分，通过运行或执行存储在存储器1102内的指令以及调用存储在存储器1102内的数据，从而实现数据处理。可选的，处理器1101可包括一个或多个处理单元，处理器1101可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理运维人员下发的指令。可以理解的是，上述调制解调处理器也可以不集成到处理器1101中。在一些实施例中，处理器1101和存储器1102可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器1101可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合基于分布式批量处理系统的处理方法的实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器1102作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器1102可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器1102是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器1102还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

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

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

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

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

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种数据处理方法，其特征在于，所述方法包括：

根据预设数据表中的各个账户，确定目标账户；

获取所述目标账户对应的各条数据，从所述各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对所述目标数据进行处理，并将所述目标数据的状态更新为处理中；

在得到所述目标数据对应的处理结果后：

若所述处理结果为处理失败，则将所述预设数据表中所述目标数据的状态更新为处理失败，并将所述各条数据中生成时间位于所述目标数据之前的数据的状态更新为无需处理；或者，

若所述处理结果为处理成功，则将所述预设数据表中所述目标数据的状态更新为处理成功。

2.如权利要求1所述的方法，其特征在于，所述从所述各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据之前，还包括：

确定所述各条数据中不存在状态为处理中的数据。

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

若所述各条数据中存在状态为处理中的数据，则根据预设数据表中的各个账户，重新确定所述目标账户。

4.如权利要求1所述的方法，其特征在于，所述对所述目标数据进行处理，包括：

从所述预设数据表中查询得到所述目标数据对应的第一数据值；

获取所述目标账户在当前时刻对应的第二数据值；

若所述第一数据值不大于所述第二数据值，则根据第一数据值生成所述目标数据对应的处理任务；或者，

若所述第一数据值大于所述第二数据值，则根据第二数据值生成所述目标数据对应的处理任务；

将所述预设数据表中所述目标数据对应的状态更新为处理中。

5.如权利要求1至4中任一项所述的方法，其特征在于，所述预设数据表通过如下方式得到：

接收数据处理请求；所述数据处理请求中包括账户信息和时间信息；

获取所述账户信息对应的各条备选数据，从所述各条备选数据中确定出位于所述时间信息范围内的各条数据；

将所述各条数据添加在所述预设数据表中。

6.如权利要求5所述的方法，其特征在于，所述将所述各条数据添加在所述预设数据表中，包括：

按照生成时间由近及远的顺序从所述各条数据中选取一条未分析过的数据，根据所述数据对应的第三数据值和所述账户在当前时刻对应的第四数据值，确定所述数据对应的第一数据值，将所述数据、所述账户信息和所述第一数据值添加在所述预设数据表中，并设置所述预设数据表中所述数据的状态为待处理；其中，所述第一数据值为所述第三数据值和所述第四数据值中取值较小的值；

循环执行上述内容直至所述各条数据中不存在未分析的数据。

7.一种数据处理装置，其特征在于，所述装置包括：

确定模块，用于根据预设数据表中的各个账户，确定目标账户；

处理模块，用于获取所述目标账户对应的各条数据，从所述各条数据中选择生成时间最晚且状态为待处理的数据作为目标数据，对所述目标数据进行处理，并将所述目标数据的状态更新为处理中；

更新模块，用于在得到所述目标数据对应的处理结果后，若所述处理结果为处理失败，则将所述预设数据表中所述目标数据的状态更新为处理失败，并将所述各条数据中生成时间位于所述目标数据之前的数据的状态更新为无需处理；或者，若所述处理结果为处理成功，则将所述预设数据表中所述目标数据的状态更新为处理成功。

8.如权利要求7所述的装置，其特征在于，所述处理模块具体用于：

从所述预设数据表中查询得到所述目标数据对应的第一数据值；

获取所述目标账户在当前时刻对应的第二数据值；

若所述第一数据值不大于所述第二数据值，则根据第一数据值生成所述目标数据对应的处理任务；或者，

若所述第一数据值大于所述第二数据值，则根据第二数据值生成所述目标数据对应的处理任务；

将所述预设数据表中所述目标数据对应的状态更新为处理中。

9.一种计算设备，其特征在于，包括至少一个处理单元以及至少一个存储单元，其中，所述存储单元存储有计算机程序，当所述程序被所述处理单元执行时，使得所述处理单元执行权利要求1～6任一权利要求所述的方法。

10.一种计算机可读存储介质，其特征在于，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行权利要求1～6任一权利要求所述的方法。

Images