资源置换方法及装置与流程

本申请涉及计算机应用领域，尤其涉及一种资源置换方法及装置。

背景技术：

资源置换，是指资源置换发起端使用其本地的资源，置换业务平台中的资源的过程；例如，上述资源置换可以是产品申购，资源置换发起端本地的资源可以是“资金”，业务平台上的资源可以是“产品”，在这种场景下，上述资源置换过程，实质上是资源置换发起端使用其本地的“资金”，来“置换”业务平台中的“产品”的过程。

在相关技术中，资源置换发起端在向业务平台发起资源置换后，资源置换发起端通常会冻结相应数量的资源；当业务平台在完成资源置换后，再根据业务平台返回的申购结果，对冻结的资源数量进行清算，扣除完成资源置换的资源，以及释放未完成资源置换的资源。可见，目前的资源置换流程中，可会存在部分资源被无效冻结的问题。因此，如何优化资源置换流程，避资源被无效冻结，对于提升资源利用率具有很重要的意义。

技术实现要素：

本申请提出一种资源置换方法，应用于业务平台，该方法包括：

接收资源置换的发起端发送的资源置换文件列表；

针对资源置换文件列表中的资源置换文件分别创建对应的资源置换任务；

执行创建的资源置换任务，将执行成功的资源置换任务对应的资源置换文件写入确认文件，定时返回至所述资源置换的发起端；其中，所述执行成功的资源置换任务包含未明确执行失败的异常资源置换任务；

在将所述确定文件返回至所述资源置换的发起端后，重新执行所述异常资源置换任务，以对所述异常资源置换任务进行异常恢复。

本申请还提出一种资源置换装置，应用于业务平台，该装置包括：

接收模块，接收资源置换的发起端发送的资源置换文件列表；

创建模块，针对资源置换文件列表中的资源置换文件分别创建对应的资源置换任务；

第一执行模块，执行创建的资源置换任务，将执行成功的资源置换任务对应的资源置换文件写入确认文件，定时返回至所述资源置换的发起端；其中，所述执行成功的资源置换任务包含未明确执行失败的异常资源置换任务；

第二执行模块，在将所述确定文件返回至所述资源置换的发起端后，重新执行所述异常资源置换任务，以对所述异常资源置换任务进行异常恢复。

本申请中，通过为资源置换的发起端发送的资源置换文件列表中资源置换文件，分别创建对应的资源置换任务，并执行创建的资源置换任务，将执行成功的资源置换任务对应的资源置换文件写入确认文件，定时返回至资源置换的发起端；其中，执行成功的资源置换任务可以包含未明确执行失败的异常资源置换任务；在将确定文件返回至资源置换的发起端后，还可以重新执行异常资源置换任务，以对所述异常资源置换任务进行异常恢复；一方面，通过对未明确执行失败的异常任务进行重新执行，可以确保异常任务最终能够执行成功；另一方面，通过将未明确执行失败的异常任务作为执行成功的任务返回给资源置换任务发起端，可以避免资源置换任务发起端对与异常任务对应的资源进行无效冻结，提升资源利用率。

附图说明

图1是本申请一实施例示出的一种资源置换方法的流程图；

图2是本申请一实施例示出的一种业务平台生成确认文件的处理流程图；

图3是本申请一实施例示出的一种资源置换装置的逻辑框图；

图4是本申请一实施例提供的承载所述一种资源置换装置的服务器的硬件结构图。

具体实施方式

在相关技术中，资源置换任务通常为日常任务。资源置换的发起端在执行日常的资源置换业务时，会在与业务平台约定的时间点，定时将每日来自用户侧的资源置换申请转换为资源置换文件，并以资源置换文件列表的形式发送给业务平台。

其中，每一个资源置换文件，分别对应用户发起的一笔资源置换申请，该申请中记录了用户申请置换的资源数量。资源置换的发起端，在收到来自用户的资源置换申请时，可以基于用户申请置换的资源数量，从该用户对应的资源池中冻结相应数量的资源。

业务平台在收到资源置换文件列表时，可以针对列表中的每一个资源置换文件分别创建资源置换任务，逐笔执行创建的这些任务，并将执行成功的资源置换任务，写入确认文件，然后在与资源置换的发起端约定的时间点，定时将该确认文件返回给资源置换的发起端，以由资源置换的发起端对已冻结的资源进行清算，扣除完成资源置换的资源，以及释放未完成资源置换的资源。

然而，在实际应用中，业务平台在逐笔执行创建的资源置换任务时，可能会由于某些外部原因(比如系统宕机或者线上限流等等)，导致业务平台在与资源置换的发起端约定的返回确认文件的时间以前，部分资源置换任务尚未执行成功；基于现有的资源置换流程，业务平台通常只会将业务平台执行成功的资源置换任务对应的资源置换文件，写入确认文件，返回给资源置换的发起端。

一方面，资源置换的发起端，在收到业务平台的确认文件后，会对冻结的这部分未执行成功的资源置换文件对应的资源进行释放，对于释放的这部分资源来说，等同于进行了无效冻结。

另一方面，对于这部分未执行成功的资源置换任务，在业务平台一侧通常会继续执行，此时如果造成这些任务在约定的时间点以前未执行成功的外部原因恢复(比如系统宕机重新恢复或者线上限流解除等等)，这些任务可能会被执行成功。在这种情况下，与这些任务对应的资源会被成功置换为业务平台一侧的资源。然而，由于这部分资源在资源置换的发起端一侧，已经进行了释放，业务平台和资源置换的发起端两方的数据并不同步，因而这些在确认文件返回后执行成功的任务，则为无效任务，置换成功的这部分资源实际上无效的占用了业务平台上的可供置换的资源，对业务平台造成了损失。

可见，业务平台现有的资源置换流程，一方面可能会对业务平台造成资源损失，另一方面并不能充分利用资源置换的发起端一侧的资源，存在资源的利用率不高的问题。

有鉴于此，本申请提出一种资源置换方法，通过为资源置换的发起端发送的资源置换文件列表中资源置换文件，分别创建对应的资源置换任务，并执行创建的资源置换任务，将执行成功的资源置换任务对应的资源置换文件写入确认文件，定时返回至资源置换的发起端；其中，执行成功的资源置换任务可以包含未明确执行失败的异常资源置换任务；在将确定文件返回至资源置换的发起端后，还可以重新执行异常资源置换任务，以对所述异常资源置换任务进行异常恢复；

一方面，通过对未明确执行失败的异常任务进行重新执行，可以确保异常任务最终能够执行成功；

另一方面，通过将未明确执行失败的异常任务作为执行成功的任务返回给资源置换任务发起端，可以避免资源置换任务发起端对与异常任务对应的资源进行无效冻结，提升资源利用率；同时，也可以避免上述异常任务在确认文件返回的时间点以后执行成功时，由于其对应的冻结资源已经被源置换任务发起端释放，而造成的业务平台上的资源损失。

下面通过具体实施例并结合具体的应用场景对本申请进行描述。

请参考图1，图1是本申请一实施例提供的资源置换方法，应用于业务平台，所述方法执行以下步骤：

步骤101，接收资源置换的发起端发送的资源置换文件列表；

步骤102，针对资源置换文件列表中的资源置换文件分别创建对应的资源置换任务；

步骤103，执行创建的资源置换任务，将执行成功的资源置换任务对应的资源置换文件写入确认文件，定时返回至所述资源置换的发起端；其中，所述执行成功的资源置换任务包含未明确执行失败的异常资源置换任务；

步骤104，在将所述确定文件返回至所述资源置换的发起端后，重新执行所述异常资源置换任务，以对所述异常资源置换任务进行异常恢复。

上述资源置换，是指资源置换发起端使用其本地的资源，置换业务平台中的资源的过程。上述业务平台，可以泛指一切面向用户提供资源置换业务的业务平台；上述资源置换的发起端，则可以包括能够与上述业务平台进行对接，向上述业务平台发起资源置换的服务平台。

例如，在示出的一种应用中，上述资源置换可以是产品申购；上述业务平台可以是第三方的支付平台；上述资源置换的发起端，可以是银行的服务器平台；上述资源可以是第三方的支付平台面向用户提供的，可以使用传统的银行账户余额申购的基金产品。

其中，上述业务平台，以及上述资源置换的发起端(以下简称发起端)的硬件架构，在本例中不进行特别限定，可以是服务器、服务器集群或者基于服务器集群构建的云平台。

在本例中，上述发起端，会在与业务平台约定的时间点，定时将每日来自用户侧的资源置换申请转换为资源置换文件，并以资源置换文件列表的形式发送给业务平台。

其中，资源置换文件中，记录了用户希望进行资源置换的资源数量。资源置换的发起端，在收到来自用户的资源置换申请时，可以基于用户申请置换的资源数量，从该用户对应的资源池中冻结相应数量的资源。

例如，当上述资源置换为基金产品申购时，上述发起端可以是银行，上述资源置换文件可以是银行向基金产品的发行机构发出的基金申购文件；在基金申购文件中记录了用户希望申购的基金额度；上述资源池则可以是基金申购用户的银行账户资金池，即该用户可用的账户资金总额。当银行收到用户的基金申购申请时，可以从该用户的银行账户资金池中冻结相应数量的资金。

在本例中，当业务平台在收到上述发起端的资源置换文件列表后，可以逐笔的读取该资源置换文件列表中的资源置换文件，并分别创建对应的资源置换任务。

其中，出于安全性考虑，在创建资源置换任务的过程中，可以引入对资源置换文件对应的用户进行身份校验的流程。在资源置换文件中可以携带本地资源置换的发起方用户的用户信息或者账户信息等，业务平台可以对这些信息进行校验，以验证发起方用户的用户身份是否合法，以及该用户是否具有资源置换的权限。如果校验失败，此时可以终止创建资源置换任务的流程。

例如，当上述资源置换为基金产品申购时，上述资源置换文件可以是基金申购文件，业务平台可以对基金申购文件中的用户签约信息进行校验；验证用户身份的合法性，以及用户是否具有基金申购权限；如果经过校验，确认用户身份不合法，或者用户不具有基金申购权限，此时可以终止申购任务。

在本例中，为了准确维护资源置换文件列表中的资源置换文件的状态，可以为资源置换文件列表中的资源置换文件标记对应的任务创建状态。

在默认情况下，可以将资源置换文件列表中的资源置换文件，标记为初始状态。当任一资源置换文件成功创建了对应的资源置换任务，可以将该资源置换文件从初始状态，修改为创建成功状态。

在本例中，对于成功创建的资源置换任务，可以存储在一张资源置换任务列表中。在执行资源置换任务时，业务平台可以从该资源置换列表中，逐笔的读取资源置换任务进行执行，完成将上述发起端一侧的用户资源，置换为业务平台中的资源的操作。

例如，当上述资源置换为基金产品申购时，上述资源置换文件可以是基金申购文件，上述资源置换任务则可以是基金申购任务；业务平台可以从基金申购任务列表中，逐笔读取基金申购任务，创建相应的申购单据并进行支付，当成功完成支付后，此时该笔基金申购任务执行成功。

其中，出于安全性考虑，在执行资源置换任务的过程中，也可以再次引入对资源置换任务对应的用户进行身份校验的流程，只要在验证出用户身份合法，以及该用户具有资源置换的权限时，再执行对应的资源置换任务，不再赘述。

在本例中，为了准确维护资源置换任务列表中的资源置换任务的状态，也可以为资源置换任务列表中的资源置换任务标记对应的执行状态。

在示出的一种实施方式中，上述执行状态可以包括执行成功状态、异常状态以及执行失败状态。

在默认情况下，资源置换任务列表中的资源置换任务，仍然可以标记为初始状态。

一方面，业务平台在执行从资源置换任务列表中读取到的任一资源置换任务时，如果接收到了针对该任务的执行失败的返回消息，此时可以将该资源置换任务从初始状态，修改为执行失败状态。

另一方面，业务平台在执行从资源置换任务列表中读取到的任一资源置换任务时，如果接收到了针对该任务的执行成功的返回消息，此时可以将该资源置换任务从初始状态，修改为执行成功状态。

以上描述的两种状态，均为很明确的执行成功或者执行失败的状态。在实际应用中，除了以上描述的两种很明确的状态以外，通常还会存在无法判定资源置换任务是否执行成功或者失败的异常状态。

在本例中，上述异常状态，是指未明确执行失败的状态。上述异常状态可以分为以下两种情况：

第一种情况，业务平台在执行从资源置换任务列表中读取到的任一资源置换任务时，如果在与上述发起端约定的返回确认文件的时间点之前，该资源置换任务仍然没有执行完毕，此时很可能会由于某些外部原因(比如系统宕机或者线上限流等等)，导致业务平台未及时接收到该任务的返回消息。在这种情况下，可以将该资源置换任务标记为异常状态。

第二种情况，业务平台在执行从资源置换任务列表中读取到的任一资源置换任务时，如果接收到针对该任务的任务异常的返回消息，比如接收到的返回消息中携带未明确错误，业务平台无法确定该任务当前到底执行成功还是执行失败，在这种情况下，可以将该资源置换任务标记为异常状态。

在本例中，为了避免上述发起端对与异常任务对应的资源，进行无效冻结；以及，上述异常任务在确认文件返回的时间点以后执行成功时，由于其对应的冻结资源已经被源置换任务发起端释放，而造成的业务平台上的资源损失，上述业务平台可以对上述确认文件的生成流程进行改进。

在本例中，上述确认文件中将不再只包含哪些明确执行成功的资源置换文件，对于那些未明确执行失败的异常状态的资源置换任务对应的资源置换文件，也可以作为执行成功的资源置换文件，写入上述确认文件，返回至上述发起端。

请参见图2，图2为本例示出的一种业务平台生成确认文件的处理流程图，包括以下执行步骤：

步骤201，核对与资源置换文件列表中的资源置换文件对应的资源置换任务是否为执行失败状态；以及，核对该资源置换文件与对应的资源置换任务的资源置换数额是否一致；

在本例中，在将资源置换文件列表中的资源置换文件写入上述确认文件之前，需要进行两项核对：

第一，需要核对资源置换文件对应的资源置换任务是否为执行失败状态。

第二，需要核对资源置换文件与对应的资源置换任务的资源置换数额是否一致。

步骤202，如果与该资源置换文件对应的资源置换任务为执行成功状态或者异常状态，并且该资源置换文件与对应的资源置换任务的资源置换数额一致，将该资源置换文件标记为核对成功状态；

在本例中，不再只将执行成功状态的资源置换文件写入确认文件，而是将所有未明确执行失败，即执行成功状态和异常状态的资源置换文件，一并写入上述确认文件。

如果业务平台核对出任一资源置换文件对应的资源置换任务，为执行成功状态或者异常状态，此时可以进一步核对该资源置换文件与对应的资源置换任务的资源置换数额是否一致；如果该资源置换文件对应的资源置换任务，为执行成功状态或者异常状态，并且该资源置换文件与对应的资源置换任务的资源置换数额保持一致，可以将该资源置换文件标记为核对成功状态。

当然，对于资源置换文件列表中的任一资源置换文件而言，如果其对应的资源置换任务为执行失败状态，则可以直接将该资源置换文件标记为核对失败状态。

如果该资源置换文件为初始状态，即该资源置换文件未成功创建对应的资源置换任务，此时该资源置换文件可能是由于资源置换的起方用户的用户身份不合法，或者该用户不具有资源置换的权限，而无法创建资源置换任务。在这种情况下，也可以将该资源置换文件标记为核对失败状态。

另外，需要说明的是，当任一资源置换文件与对应的资源置换文件的资源置换数额不一致时，这种情况下，业务平台可以针对该资源置换文件重新创建资源置换任务，对资源置换任务的资源置换数额进行校正，或者由平台管理人员人工干预，对资源置换任务中的资源置换数额进行手动修改，以确保资源置换文件与对应的资源置换文件的资源置换数额一致。

步骤203，将标记为核对成功状态的资源置换文件写入确认文件。

在本例中，业务平台可以将所有核对成功状态的资源置换文件写入确认文件，并根据与上述发起端约定的时间点，将确认文件返回给上述发起端。

当然，对于核对失败状态的资源置换文件而言，将不再写入确认文件，从而上述发起端后续在收到确认文件后，将对核对失败状态的资源置换文件对应的冻结资源进行释放。

在本例中，当业务平台根据与上述发起端约定的时间点，将生成的确认文件返回给上述发起端后，对于那些异常状态的资源置换任务，业务平台可以进行持续推进，重新执行这些资源置换任务，以确保这些未在向上述发起端返回确认文件的时间点之前执行成功的资源置换任务，最终能够执行成功。

其中，业务平台在重新执行这些异常状态的资源置换任务时，可以通过启用一个定时任务，定时的来重新进行执行。

同时，为了避免重复执行相同的资源置换任务，对其它资源置换任务的执行造成影响，可以预先设定一个最大的重试次数。对于重新执行的这些异常状态的任务来说，如果重新执行的次数达到该最大的重试次数，仍然没有执行成功，此时业务平台可以向平台管理人员输出告警，以及记录了这些仍然没有执行成功的异常状态的任务的日志文件。平台管理人员在查看到告警后，可以手动检查上述日志文件，人工的对这些异常状态的任务重新进行执行，以最大程度的确保这些异常状态的任务最能能够全部执行成功。

通过以上实施例可见，业务平台通过将为明确执行失败的异常状态的资源置换任务，作为执行成功的资源置换任务写入确认文件，返回给上述发起端；以及，通过启动异常恢复机制，对这些异常状态的资源置换任务进行重新执行；一方面，通过对未明确执行失败的异常任务进行重新执行，可以确保异常任务最终能够执行成功；通过将未明确执行失败的异常任务作为执行成功的任务返回给资源置换任务发起端，可以避免资源置换任务发起端对与异常任务对应的资源进行无效冻结，提升资源利用率；同时，也可以避免上述异常状态的任务在在确认文件返回的时间点以后执行成功时，由于其对应的冻结资源已经被源置换任务发起端释放，而造成的业务平台上的资源损失。

以下结合一种具体的资源置换的应用场景对以上实施例中的技术方案进行详述。

需要说明的是，以上实施例中示出的技术方案，可以广泛应用于“资源置换”相关的一些应用场景；例如，上述资源置换可以是产品申购，资源置换发起端本地的资源可以是“资金”，业务平台上的资源可以是“产品”，在这种场景下，上述资源置换过程，实质上是资源置换发起端使用其本地的“资金”，来“置换”业务平台中的“产品”的过程。

在以下实施例中，将以上述资源置换为基金产品申购为例进行说明；容易理解的是，以上述资源置换为基金产品申购为例仅为示例性的，在实际应用中，上述资源置换也可以指代其它相似的场景，在本例中不再进行一一详述。

在示出的一种基金产品申购的应用场景中：

上述“业务平台”可以是第三方支付平台；

上述“资源置换的发起端”可以是银行；

上述“资源”可以是第三方支付平台面向用户提供的，可以使用传统的银行账户余额申购的基金产品；

上述“资源置换文件”可以是银行向基金产品的发行机构发出的基金申购文件；在基金申购文件中记录了用户希望申购的基金额度。

上述“资源池”可以是基金申购用户的银行账户资金池，即该用户可用的账户资金总额。当银行收到用户的基金申购申请时，可以从该用户的银行账户资金池中冻结相应数量的资金。

上述“确认文件”可以是第三方支付平台在完成基金申购后，向银行返回的回盘文件。银行收到回盘文件后，可以对冻结的用户资金进行清算，扣除申购成功的资金金额，以及释放未完成基金申购的资金金额，返回至用户的账户余额中。

以下以银行和第三方支付平台在完成日常的基金申购的交互过程进行描述。

在本例中，银行和第三方支付平台可以预先约定银行每日向第三方支付平台上送基金申购文件列表，以及第三方支付平台在基于基金申购文件列表完成基金申购后，向银行返回回盘文件的时间点。

假设预先约定的银行向第三方支付平台上送基金申购文件列表的时间点为每日凌晨3点；第三方支付平台向银行返回回盘文件的时间点为每日清晨6点。

每日的每日凌晨3点，银行会汇总当日所有基金申购文件，在申购用户账户中冻结相应数额的资金，然后生成基金申购文件列表上送给第三方支付平台。

第三方支付平台可以启动一个凌晨3点～清晨6点的定时任务，通过该定时任务在每日凌晨3点～清晨6点基于银行上送的基金申购文件列表，逐笔的创建基金申购任务，并针对创建的基金申购任务逐笔的创建申购单据并进行支付完成基金申购。

一方面，第三方支付平台在收到银行的基金申购文件列表后，可以逐笔读取该列表中的基金申购文件，对基金申购文件中的用户签约信息进行校验，验证用户身份的合法性，以及用户是否具有基金申购权限；如果经过校验，确认用户身份合法，并且用户具有基金申购权限，可以将该基金申购文件由初始状态，修改标记为创建成功状态。创建成功的基金申购任务，可以存储在一张基金申购任务列表中。

另一方面，第三方支付平台可以逐笔读取基金申购任务列表中的基金申购任务，并再次对基金申购任务中的用户签约信息进行校验，验证用户身份的合法性，以及用户是否具有基金申购权限；如果经过校验，确认用户身份合法，并且用户具有基金申购权限，可以执行创建申购单据，并进行支付以完成基金申购。

第三方支付平台在执行基金申购支付时，可以与相应的支付平台进行对接，如果接收到支付平台返回的支付失败的返回消息时，可以将对应的基金申购任务标记为支付失败状态。

如果接收到支付平台返回的携带未明确支付错误的返回消息时，可以将对应的基金申购任务标记为异常状态。

如果基金申购任务列表中存在凌晨6点前仍然没有完成申购支付的基金申购任务，比如系统宕机或者线上限流等，导致未在清晨6点完成这写基金申购任务，可以将这些基金申购任务标记为异常状态。

在本例中，第三方支付平台还可以在清晨6点启用一个生成回盘文件的定时任务，通过该定时任务，第三方支付平台可以在清晨6点根据当前的基金申购结果完成基金申购文件的勾兑，生成回盘文件以及向银行返回回盘文件。

对基金申购文件进行勾兑，是指对基金申购文件与对应的基金申购任务中的申购金额进行核对，以及对基金申购文件与对应的基金申购任务的状态进行核对。

在对基金申购文件进行勾兑时，第三方支付平台可以遍历基金申购文件列表以及基金申购任务列表，分别核对每一笔基金申购文件，和对应的基金申购任务列表的申购金额是否一致；以及核对每一笔基金申购文件对应的基金申购任务列表的状态是否为执行失败状态；

如果一笔基金申购文件与对应的基金申购任务列表中的申购金额一致，并且该基金申购文件对应的基金申购任务为执行成功状态或者异常状态，此时该笔基金申购文件勾兑成功，可以将该笔基金申购文件标记为勾兑成功状态。

当基金申购文件列表中所有基金申购文件勾兑完成，第三方业务平台可以将所有勾兑成功状态的文件写入回盘文件，返回给银行。

第三方支付平台还可以在清晨6点启用一个重新执行异常状态的基金申购任务的定时任务。通过该定时任务，第三方支付平台可以在清晨6点发送了回盘文件后，对异常状态的基金申购任务重新进行执行，以确保这些异常状态的基金申购任务能够申购成功。

一方面，可以设置一个最大重试次数，在设定的最大重试次数之内，重复执行这些异常状态的基金申购任务。

另一方面，如果这些异常状态的基金申购任务重新执行次数达到最大重试次数，仍然未能申购成功，此时可以向平台管理人员输出告警，以及记录了这些异常状态的基金申购任务的日志文件，由平台管理人员人工对这些任务进行推进，从而确保这些任务能都申购成功。

银行在收到第三方支付平台返回的回盘文件后，可以逐笔读取回盘文件中申购成功的基金申购文件，然后针对相应的用户账户执行冻结资金的清算。对预申购成功的基金申购文件，可以在冻结的资金中扣除相应的金额；对于明确申购失败的基金申购文件，可以将冻结的资金返还至用户的银行账户中。

由于回盘文件中写入的基金申购文件中，不仅包括明确申购成功的基金申购文件，还包括在凌晨6点前未能申购成功的基金申购文件，而在凌晨6点前未能申购成功的基金申购文件对应的基金申购任务，第三方支付平台会在凌晨6点返回回盘文件后重新进行申购，并通过人工干预的方式确保申购成功，因此银行对于这部分基金申购文件，可以正常的进行冻结资金的扣除。

可见，在本例中通过对回盘文件的生成机制进行改进，在对基金申购文件进行勾兑时，不再仅将明确申购成功的基金申购文件写入回盘文件，而是将那些未在凌晨6点前未能申购成功的异常状态的基金申购文件也写入回盘文件，并在凌晨6点后对于这部分异常状态的基金申购文件持续进行推进：

一方面，通过这种方式，可以避免未将这部分异常状态的基金申购文件写入回盘文件时，银行对这部分基金申购文件对应的资金进行冻结后，再重新进行释放的无效操作，从而避免银行对于这部分异常状态的基金申购文件对应的资金，进行无效冻结，提升银行的资金利用效率。

另一方面，第三方支付平台发生系统宕机或者线上限流等意外情况，造成部分申购任务未在凌晨6点前申购完成时，如果第三方支付平台未将这部分异常状态的基金申购文件写入回盘文件，那么银行则会对这部分基金申购文件对应的资金进行释放。而这部分未完成的申购任务，第三方支付平台并不会终止申购，因此当系统宕机重新恢复，或者线上限流解除时，这部分未完成的申购任务会在凌晨6点以后申购成功，而在银行一侧，这部分申购任务对应的资金可能已被释放返还至用户账户，在这种情况下，等同于第三方支付平台执行了一笔无效的申购，从而会对第三方支付平台造成资金损失。可见，通过将这部分异常状态的基金申购文件也写入回盘文件，可以避免这些异常状态的申购任务，在凌晨6点以后申购成功后，由于其对应的冻结资金已经被银行释放，而造成的第三方支付平台的资金损失的问题。

与上述方法实施例相对应，本申请还提供了装置的实施例。

请参见图3，本申请提出一种资源置换装置30，应用于业务平台；其中，该业务平台具体可以是一服务器；请参见图4，作为承载所述资源置换装置30的服务器所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述资源置换装置30通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置30包括：

接收模块301，接收资源置换的发起端发送的资源置换文件列表；

创建模块302，针对资源置换文件列表中的资源置换文件分别创建对应的资源置换任务；

第一执行模块303，执行创建的资源置换任务，将执行成功的资源置换任务对应的资源置换文件写入确认文件，定时返回至所述资源置换的发起端；其中，所述执行成功的资源置换任务包含未明确执行失败的异常资源置换任务；

第二执行模块304，在将所述确定文件返回至所述资源置换的发起端后，重新执行所述异常资源置换任务，以对所述异常资源置换任务进行异常恢复。

在本例中，所述第一执行模块303：

核对与资源置换文件列表中的资源置换文件对应的资源置换任务是否为执行失败状态；以及，核对该资源置换文件与对应的资源置换任务的资源置换数额是否一致；

如果与该资源置换文件对应的资源置换任务为执行成功状态或者异常状态，并且该资源置换文件与对应的资源置换任务的资源置换数额一致，将该资源置换文件标记为核对成功状态；

将标记为核对成功状态的资源置换文件写入确认文件。

在本例中，所述第一执行模块303进一步：

如果与该资源置换文件对应的资源置换任务为执行失败状态，或者该资源置换文件未成功创建资源置换任务，将该资源置换文件标记为核对失败状态。

在本例中，在将执行成功的资源置换任务对应的资源置换文件写入确认文件之前，所述第一执行模块303进一步：

当接收到针对任一资源置换任务的执行成功的返回消息时，将该资源置换任务标记为执行成功状态；

当接收到针对任一资源置换任务的执行失败的返回消息时，将该资源置换任务标记为执行失败状态；

当任一资源置换任务在所述确认文件返回后仍未执行完毕，或者接收到针对任一资源置换任务的任务异常的返回消息时，将该资源置换任务标记为异常状态。

在本例中，所述第二执行模块304进一步：

当所述异常资源置换任务的重新执行次数达到预设次数后，所述异常资源置换任务仍未执行成功，则输出告警以及记录了所述异常资源置换任务的日志文件。

在本例中，所述资源置换为资源申购；所述资源置换文件为资源申购文件；所述确定文件为资源申购确认文件；所述资源置换的发起端为银行；所述业务平台为第三方支付平台；所述资源包括第三方支付平台提供的基金产品。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。