CN111311360A - 资源的退还方法和装置、存储介质、电子装置 - Google Patents

Abstract

本申请公开了一种资源的退还方法和装置、存储介质、电子装置。其中，该方法包括：通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，目标缓存被设置为允许多个实例中的任一实例读取相应的标识；查找与第一标识对应的第二标识，第二标识用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源；按照第二标识向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回对应的资源。本申请解决了相关技术中退还虚拟资源的效率较低的技术问题。

Description

资源的退还方法和装置、存储介质、电子装置

技术领域

本申请涉及互联网领域，具体而言，涉及一种资源的退还方法和装置、存储介质、电子装置。

背景技术

用户在网上购物时通常是将购物车中的多个商品一次下单结算并发起支付，支付成功则整个交易完成。用户收到商品后因为商品描述不符，质量不满意等问题对部分商品发起退货，退货请求经过商家客服审批同意后，用户通过物流将商品退还给商家，商家确认收货后向支付系统请求给用户退款。

在上述退款场景中，购物平台接收用户发起的退货请求，然后周期性的逐一向银行发起退款，处理效率较低。与退款类似，在点卡、充值卡、金币等虚拟资源的退还中，也存在类似的问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种资源的退还方法和装置、存储介质、电子装置，以至少解决相关技术中退还虚拟资源的效率较低的技术问题。

根据本申请实施例的一个方面，提供了一种资源的退还方法，包括：通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，第一资源与第二资源不同，目标缓存被设置为允许多个实例中的任一实例读取相应的标识；查找与第一标识对应的第二标识，其中，第二标识用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源；按照第二标识向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回对应的资源。

根据本申请实施例的另一方面，还提供了一种资源的退还装置，包括：获取单元，用于通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，第一资源与第二资源不同，目标缓存被设置为允许多个实例中的任一实例读取相应的标识；查找单元，用于查找与第一标识对应的第二标识，其中，第二标识用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源；请求单元，用于按照第二标识向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回对应的资源。

根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本申请实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。

在本申请实施例中，通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，第一资源与第二资源不同，目标缓存被设置为允许多个实例中的任一实例读取相应的标识；查找与第一标识对应的第二标识，其中，第二标识用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源；按照第二标识向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回对应的资源，进而解决了相关技术中退还虚拟资源的效率较低的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的资源的退还方法的硬件环境的示意图；

图2是根据本申请实施例的一种可选的资源的退还方法的流程图；

图3是根据本申请实施例的一种可选的资源的退还装置的示意图；

图4是根据本申请实施例的一种终端的结构框图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

发明人经过对退款场景的分析认识到，退款交易具有如下特点：1，退款不是用户直接发起的，而是平台(如购物平台，外卖平台等)作为退款方向银行直接发起，不需要实时给用户返回退款结果，一般情况下是承诺一周内完成退款；2，一笔正向支付可能会对应多笔不同时间发起的退款，比如用户一次下单支付，包含5件商品，其中的3件产品逐一走完退款流程发起退款，就是一笔正向支付对应3笔不同时间发起的退款。

针对上述第一个特点，目前的退款系统都是异步的，退款系统接收到退款请求后只是给请求方返回接收退款请求成功，不会返回银行退款的结果，等退款系统内部完成了银行退款再通知请求方银行退款的结果。

针对上述第二个特点，银行要求第三方支付机构发起退款时不能对同一笔正向支付同时发起多笔退款，因为银行侧处理退款请求时需要校验退款金额是否超过了原正向支付交易的金额，并在退款成功后更新原正向支付交易的已退款金额，如果对同一笔正向支付同时发起多笔退款，银行系统容易出现校验失败或者更新失败问题。少数银行还要求在一定时间内比如5分钟不能对同一笔正向支付二次发起退款，理由是银行系统内部处理一笔退款需要经过多个子系统流转，耗时较长。

因为银行对同一笔正向支付不能同时发起多笔退款的硬性限制，退款系统通常是将向银行发起退款请求的任务放到一个全局唯一的单实例的应用中周期性执行，将这个应用称为退款发起方。退款发起方会从数据库中按照原正向支付交易去重查出待处理的退款请求，比如一共有5笔退款请求：A1、A2、B1、B2、C1，其中A1和A2，B1和B2分别对应同一笔正向支付交易，退款发起方按照正向支付交易去重后查出来的结果就是A1、B1和C1。查出待处理的退款请求后，会并发的将退款请求发送到银行侧，银行侧返回退款结果则向退款请求方通知是否退款成功，至此整个退款交易完成。

根据本申请实施例的一方面，提供了一种资源的退还方法的方法实施例，该方法适应用于上文描述得场景，还可以克服在上述场景中出现的问题。

可选地，在本实施例中，上述资源的退还方法可以应用于如图1所示的由终端101、服务器103以及资源平台105所构成的硬件环境中。如图1所示，服务器103通过网络与终端101、资源平台105进行连接，可用于为终端或终端上安装的客户端提供服务(如购物服务、游戏服务等)，可在服务器上或独立于服务器设置数据库107，用于为服务器103提供数据存储服务，上述网络包括但不限于：广域网、城域网或局域网，终端101并不限定于PC、手机、平板电脑等。

本申请实施例的资源的退还方法可以由服务器103来执行，也可以由服务器103和终端101、资源平台105共同执行。图2是根据本申请实施例的一种可选的资源的退还方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤S202，服务器通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识(或称目标原单标识、原单ID)，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，第一资源与第二资源不同，目标缓存被设置为允许多个实例中的任一实例读取相应的原单标识，即该缓存为共享缓存。

上述第二平台为提供虚拟资源服务的平台，如银行、虚拟货币存储平台、即时通讯应用的“钱包”等可用于存储虚拟资源的平台，第一资源即这些平台提供的资源，如银行的存款，而目标用户即第一资源的拥有者；第一平台可以为提供“购物”功能的平台，如商城、购物平台等平台，第二资源即这些平台提供的资源，如手机、食品、虚拟物品、服务等商品。上述多个实例为对执行本申请流程的应用服务进行实例化后得到的，这多个实例可并行运行在服务器上，这里的服务器可以是单个服务器，也可以是服务器集群，这些实例可以集成在第一平台上，也可以独立于第一平台作为一种服务提供给第一平台。后续以使用银行在购物平台上付款来购物为例进行详述。

步骤S204，服务器查找与第一标识对应的第二标识，第二标识(或称目标收单标识、收单ID)用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源。

每一笔原单ID的订单可能存在多个商品(即第二资源)，用户可针对其中的部分或者全部商品发起退款，每一笔退款对应于一个收单标识，换言之，一个收单是对一笔订单中的部分或者全部商品发起的退款。

步骤S206，服务器按照第二标识向第二平台发送资源退还请求，资源退还请求用于请求向目标对象退回对应的资源。

上述过程仅仅从一个实例的角度去描述，由于上述多个实例是并行运行的，那么只要缓存中还存在未处理的原单标识，其他实例也会按照相同的流程去处理，假设每个实例处理一个原单标识需要的时间是T，那么一个实例处理N个原单标识需要的时间是(N*T)，考虑到若退款请求方只使用一个单实例应用，日处理能力有限，无法满足高频(如大促活动期间)的退款需求，而在本申请的技术方案中，假设多个实例的数量为M(M为大于等于2的正整数)，那么处理N个原单标识需要的时间是(N*T/M)，显然(N*T)是(N*T/M)的至少两倍，换言之，采用本申请的技术方案，可以解决了相关技术中退还虚拟资源的效率较低的技术问题，进而达到将效率提高的技术效果。

本申请在实现退款合单和退款重试的需求的基础上，提供了一种可扩展的，支持多实例发起银行退款请求的，高效的退款解决方案。下面结合图2所示的步骤进一步详述本申请的技术方案。

在步骤S202提供的技术方案中，通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识。

若退款请求方采用的是单实例应用，其处理能力将会极大受限，故而本申请的方案中采用多实例应用，可以并行处理用户的退款请求。另外，单实例有单点隐患问题，即该实例一旦宕机则无法发起退款，而在本申请的技术方案中，采用多实例应用，存在故障冗余，在通过多个实例中的第一实例从第一平台的目标缓存中获取目标原单标识时，可从多个实例中查找未发生异常故障的第一实例；通过第一实例从目标缓存中获取目标原单标识。

可选地，在通过多个实例中的第一实例从第一平台的目标缓存中获取目标原单标识之后，在第一实例执行后续的步骤(如步骤S204、步骤S206等)的过程中若发生故障，那么可以从多个实例中查找未发生异常故障且处于空闲状态的第二实例，进而利用第二实例替代第一实例，继续处理。

在步骤S204提供的技术方案中，查找与目标原单标识对应的目标收单标识，目标收单标识用于表示请求向第一平台退回第三资源(如退还同一笔订单购买的商品中的部分商品)并请求在第二平台上向目标对象退回第四资源(如对所退还的部分商品进行退款)，第三资源属于第二资源，第四资源属于第一资源。

可选地，查找与目标原单标识对应的目标收单标识包括：查找与目标原单标识对应的所有收单标识，即对一个订单下发起的所有退款请求对应的收单标识；从与目标原单标识对应的收单标识中查找状态为待处理的目标收单标识。

相关技术中之所以将向银行发起退款请求的任务放到一个全局唯一的单实例的应用中周期性执行，是为了避免多实例同时执行任务时导致同一笔退款请求被两次发送到银行，因为多实例同时查询数据库时查询到的待处理的退款请求是一样的，比如实例T1，T2同时去查询到的待处理退款请求是A1，B1，C1。T1和T2两个实例同时将退款请求A1发往银行就会导致同一笔退款请求被二次发往银行了。而在本申请的技术方案中，并不直接将用户的退款请求放在全局缓存(即目标缓存)中，而是将需要退款的原单标识放在全局缓存中，并对原单标识进行去重，这样，在实例读取时只需要按照读取的原单标识查找对应的收单标识即可，由于每个实例读取的原单标识不可能相同，那么就不存在同一笔退款请求被二次发往银行的问题。

可选地，在查找与目标原单标识对应的目标收单标识之后，可将退还请求的请求标识与目标收单标识关联，并将目标收单标识的状态由待处理变更为处理中。

在步骤S206提供的技术方案中，按照目标收单标识向第二平台发送资源退还请求。

可选地，在目标收单标识为多个的情况下，按照目标收单标识向第二平台发送资源退还请求包括：向第二平台发送多个资源退还请求，每个资源退还请求用于请求向目标对象退回与一个目标收单标识匹配的资源，换言之，即若用户针对同一订单发起了多个退款请求，相应地，该方案会为每个退款请求发起一个对应的资源退还请求，以请求对所退还商品进行退款；或，向第二平台发送资源退还请求，资源退还请求用于请求向目标对象退回与所有目标收单标识匹配的资源，换言之，即若用户针对同一订单发起了多个退款请求，该方案会对这多个进行合并，请求退款的金额为所有退款请求的退款金额之和。

相关技术中用户的退款请求和发往银行的退款交易(如资源退还请求)是一一对应的，无法实现退款合单、退款重试等操作。在本申请的上述方案中可以实现退款合单，所谓退款合单是指将一定时间范围内的属于同一笔正向支付交易(即一个订单)的多笔退款请求按照金额相加合并成一笔发往银行，比如有3笔属于同一笔正向交易的退款请求，A1退10元、A2退2元、A3退款3元，合单以后变成一笔，退15元，银行收到的退款请求只有这一笔。退款合单的目的是为了规避部分银行制定的一定时间内比如1小时不能对同一笔正向支付交易二次发起退款的限制。

可选地，在按照目标收单标识向第二平台发送资源退还请求之后，在第二平台的反馈信息表明已经向目标对象退回对应的资源的情况下，向目标对象返回表示已经退回对应的资源的提示信息；在第二平台的反馈信息表明向目标对象退回资源失败且退还请求被配置为不允许重复发起的情况下，向目标对象返回表示退回资源失败的提示信息；在第二平台的反馈信息表明向目标对象退回资源的操作在处理中的情况下，按照目标时间周期从第二平台查询向目标对象退回资源的操作的处理状态，以便于根据处理状态执行进一步的操作。

可选地，在按照目标收单标识向第二平台发送资源退还请求之后，在第二平台的反馈信息表明已经向目标对象退回对应的资源的情况下，将目标收单标识的状态由处理中变更为处理成功；在第二平台的反馈信息表明向目标对象退回资源失败的情况下，将目标收单标识的状态由处理中变更为处理失败。

可选地，在将目标收单标识的状态由处理中变更为处理失败之后，在退还请求被配置为允许重复发起的情况下，将目标收单标识的状态由处理失败变更为待处理。退款重试是指银行返回退款失败的情况下不需要退款请求方二次发起退款，直接重新发起银行退款的功能，退款重试的目的是为了避免由退款请求方二次发起退款导致整个退款耗时过长的问题。

本方案相对于相关技术存在如下的不同点：将退款收单和退款交易分离，解除两者一对一的限制，退款收单是指接收退款请求方的退款请求并将退款金额，表示原正向支付交易的原单ID，唯一标识这一笔退款请求的收单ID等信息保存到数据库退款收单表中，退款交易是指将退款请求发送给银行，并将唯一标识这一笔退款交易的交易ID，银行订单号，银行退款结果等保存到数据库退款交易表中，退款收单信息和退款交易信息通过另外一张映射表关联起来，表中记录收单ID和交易ID的对应关系，退款请求的退款结果以对应的退款交易表的退款结果为准。比如有三笔退款收单，退款收单表的信息如表1所示：

表1

这三笔退款如果开启退款合单，因为00001和00003都是对同一笔正向支付交易A00001的退款，所以将其退款金额相加，合并成一笔发往银行，对应的交易表的信息如表2(其中的交易ID相当于请求标识)所示：

表2

对应的映射表如表3所示：

表3

收单ID(标识唯一一笔退款请求)	交易ID(标识唯一一笔退款请求)
		00001	10001
00002	10002
		00003	10001

开启退款合单的情况下，退款收单记录和退款交易记录是多对一的关系，即多笔属于同一正向支付交易的退款收单会合并成一笔发往银行，产生一笔退款交易，如收单ID00001和00003的退款收单被合并成一笔，对应的退款交易是交易ID 10001的记录。

表3中收单ID为00002的退款请求对应的退款交易10002是退款失败状态，如果需要退款重试，则只需在退款交易表和退款映射表分别在插入一条记录即可，退款交易表如表4所示：

表4

退款映射表如表5所示：

表5

收单ID(标识唯一一笔退款请求)	交易ID(标识唯一一笔退款请求)
		00001	10001
00002	10002
		00003	10001
00002	10003

在退款重试的情况下，退款收单记录和退款交易记录是一对多关系，一笔退款记录每重试一次就产生一笔新的退款交易记录，所以就存在一笔退款记录对应的退款交易记录有多笔，但是对应的退款成功的退款交易记录只有一笔，比如上述示例中的收单ID00002对应了两笔退款交易记录，分别是交易ID 10002，10004两笔，其中10002是退款失败的，10004是退款成功的。

如果不开启退款合单，也不做退款重试，则对应的交易表如表6所示：

表6

对应的映射表如表7所示：

表7

收单ID(标识唯一一笔退款请求)	交易ID(标识唯一一笔退款请求)
		00001	10004
00002	10005
		00003	10006

此时退款收单记录和退款交易记录就是一对一的关系，即一笔退款收单记录只对应一笔退款交易记录，如表7中的收单ID 00001对应交易ID10001。

基于任务分派模型向银行发送退款请求，将原有的退款发起方应用由单实例变成多实例的，且支持任意横向扩展，从而不断增加退款的日处理能力。任务分派模型有两个角色，任务分配角色和任务执行角色。

任务分配角色负责从退款收单表中查出所有的待处理的退款请求的表示原正向支付交易的原单ID，然后将原单ID逐一放到全局共享缓存中，全局共享缓存会负责对原单ID做去重。去重的目的是为了保证同一个原单ID只能被一个任务执行角色拿到。如果全局缓存中存在多个相同的原单ID，则不同的任务执行角色可能取到相同的原单ID，导致该原单ID关联的退款请求被重复发往银行。

任务执行角色负责从全局共享缓存中逐一取出待处理的原单ID，然后用原单ID去退款收单表中查询该原单ID关联的退款请求，如果开启了合单则将查询到的多笔退款请求的金额相加，以相加后的退款金额生成一笔退款交易然后发往银行；如果没有开始合单，则逐一将多笔退款请求发往银行，每笔退款请求都生成一笔退款交易，因为一个原单ID同一时间只能被一个任务执行角色拿到，从退款收单表查询该原单ID关联的退款请求后，任务执行角色只能一个一个的将退款请求发到银行，即上一个退款请求从银行返回结果后再向银行发下一个退款请求，所以保证了不会将属于同一笔正向支付交易的多笔退款请求同时发往银行。

以之前的示例数据为例进行说明，任务分配角色查出的待处理的原单ID有两个，A0001和A0002，任务执行角色用A0001查询出的退款收单请求有两条00001，00003，如果开启合单则，10001退10元，10003退2元，两者相加退12元，产生一笔退12元的退款交易，对应交易ID 10001的退款交易记录；如果没有开启合单，则10001对应交易ID 10004的退款交易记录，10003对应交易ID 10006的退款交易记录。

任务分配角色和任务执行角色在代码层面实际都是一个周期性执行的定时任务，两种定时任务在每个退款发起方应用实例上都可执行。具体而言，退款发起方应用的每个实例都会周期性的执行任务执行角色对应的定时任务，而退款发起方应用的多个实例中同一时间只能有一个实例执行任务分配角色对应的定时任务，因为多个实例同时执行时，每个实例查出来的原单ID是基本一样的，但我们不需要重复的原单ID。

在本申请的技术方案中，将退款收单和退款交易分离从而灵活实现退款合单，重试等需求的解决方案；基于任务分派模型发起退款交易的可扩展的高效的解决方案。作为一种可选的实施例，下面结合本方案的完整退款流程详述：

步骤1，接收退款请求方的退款请求，生成一个唯一标识此退款请求的收单ID，将收单ID，此退款请求对应的标识原正向支付交易的原单ID，退款金额等保存到退款收单表中，此时该退款请求就是待处理INIT状态，返回给退款请求方是收单成功而非退款成功。假设此时待处理的退款请求就是示例中的收单ID为00001，00002，00003三条记录。

步骤2，任务分配角色从退款收单表中查询所有待处理的退款请求的原单ID，将原单ID放到唯一的全局共享缓存中，全局共享缓存对原单ID做去重。基于上述示例，任务分配角色查询出来的原单ID就是A0001，A0002，A0001三个，全局缓存去重后就剩下A0001，A0002两个。

步骤3，多个任务执行角色同时从全局共享缓存中逐一取出原单ID，如果没有取到则表示没有待处理的退款请求，则此次任务执行完成。假如此时取出原单ID A0001，使用A0001去退款收单表查询待处理的退款请求，一共有两笔，收单ID分别是00001，00003。此时如果配置了退款合单，则将这两笔的退款金额(分别是10元，2元)相加得到12元，以12元作为新的退款金额，接着生成一个标识唯一一笔退款交易的交易ID和银行用的退款银行订单号，将新的退款金额，交易ID，退款银行订单号，原单ID等保存到退款交易表中(注意保存到交易时退款交易的状态是PROCESS处理中)，将交易ID和两笔收单ID的对应关系逐一保存到映射表中，更新退款收单表对应的退款请求的状态从待处理INIT到处理中PROCESS，都执行成功后就向银行发起退款请求。如果没有配置合单，则逐一处理两笔退款请求，每笔退款请求同样生成交易ID和银行订单号，将退款金额，交易ID，退款银行订单号，原单ID等保存到退款交易表中，将交易ID和收单ID的对应关系保存到映射表中，更新退款收单表对应的退款请求的状态从待处理INIT到处理中PROCESS，都执行成功后向银行发起退款。以配置合单的情形为例，生成的交易ID是10001，银行订单号是120001，将交易ID，银行订单号还有退款金额12元保存到退款交易表中，将00001和10001，00002和10001的对应关系逐一保存到映射表中，然后分别更新00001和10002的状态从待处理INIT到处理中PROCESS，都执行完成将退款请求发往银行。

步骤4，银行返回退款结果，如退款成功、退款失败、退款处理中，将退款结果更新到对应的退款交易记录，退款收单记录中。如果退款成功或者退款失败且不需要重试则向退款请求方通知退款的最终结果。如果退款处理中，则隔一段时间后向银行发起查询请求获取这笔退款交易的终态。交易ID是10001的交易记录银行返回的退款结果是退款成功，则将这笔交易记录和关联的00001，00002退款收单记录的状态都从处理中改成退款成功。

步骤5，银行返回退款失败且配置了退款重试，则需要将这笔退款交易对应的退款请求的状态从退款失败FAIL改成待处理INIT，改成待处理后，任务分配角色会将退款请求的原单ID重新放入全局共享缓存中，任务执行角色会重新建退款请求发往银行，整个流程跟正常的退款流程一样。比如交易ID是10001的交易记录返回退款失败且需要重试，则将对应的退款收单记录00001，00002的状态从退款失败FAIL改成退款待处理INIT。

采用本申请的技术方案，所带来的有益效果如下：提供了一种可任意横向扩展的高效异步退款解决方案，完全满足量级不断增长的退款需求；提供退款合单和退款重试的支持，可有效规避银行的退款限制规则，大大缩短退款整体耗时。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

根据本申请实施例的另一个方面，还提供了一种用于实施上述资源的退还方法的资源的退还装置。图3是根据本申请实施例的一种可选的资源的退还装置的示意图，如图3所示，该装置可以包括：

获取单元301，用于通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，第一资源与第二资源不同，目标缓存被设置为允许多个实例中的任一实例读取相应的标识。

查找单元303，用于查找与第一标识对应的第二标识，其中，第二标识用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源。

请求单元305，用于按照第二标识向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回对应的资源。

需要说明的是，该实施例中的获取单元301可以用于执行本申请实施例中的步骤S202，该实施例中的查找单元303可以用于执行本申请实施例中的步骤S204，该实施例中的请求单元305可以用于执行本申请实施例中的步骤S206。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

通过上述模块，上述多个实例是并行运行的，那么只要缓存中还存在未处理的原单标识，其他实例也会按照相同的流程去处理，假设每个实例处理一个原单标识需要的时间是T，那么处理N个原单标识需要的时间是(N*T)，考虑到若退款请求方只使用一个单实例应用，日处理能力有限，无法满足高频(如大促活动期间)的退款需求，而在本申请的技术方案中，假设多个实例的数量为M(M为大于等于2的正整数)，那么处理N个原单标识需要的时间是(N*T/M)，显然(N*T)是(N*T/M)的至少两倍，换言之，采用本申请的技术方案，可以解决了相关技术中退还虚拟资源的效率较低的技术问题，进而达到至少将效率提高50％的技术效果。

可选地，获取单元还可用于：从多个实例中查找未发生异常的第一实例；通过第一实例从目标缓存中获取第一标识。

可选地，请求单元还可用于：在第二标识为多个的情况下，向第二平台发送多个资源退还请求，其中，每个资源退还请求用于请求向目标对象退回与一个第二标识匹配的资源；或，向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回与所有第二标识匹配的资源。

可选地，上述查找单元还可用于：查找与第一标识对应的收单标识；从与第一标识对应的收单标识中查找状态为待处理的第二标识。

可选地，本申请的装置还可包括：状态管理单元，用于在查找与第一标识对应的第二标识之后，将退还请求的请求标识与第二标识关联，并将第二标识的状态由待处理变更为处理中。

可选地，本申请的装置还可包括：反馈单元，用于在按照第二标识向第二平台发送资源退还请求之后，在第二平台的反馈信息表明已经向目标对象退回对应的资源的情况下，向目标对象返回表示已经退回对应的资源的提示信息；在第二平台的反馈信息表明向目标对象退回资源失败且退还请求被配置为不允许重复发起的情况下，向目标对象返回表示退回资源失败的提示信息。

可选地，状态管理单元还用于在第二平台的反馈信息表明向目标对象退回资源的操作在处理中的情况下，按照目标时间周期从第二平台查询向目标对象退回资源的操作的处理状态。

可选地，状态管理单元还用于在按照第二标识向第二平台发送资源退还请求之后，在第二平台的反馈信息表明已经向目标对象退回对应的资源的情况下，将第二标识的状态由处理中变更为处理成功；在第二平台的反馈信息表明向目标对象退回资源失败的情况下，将第二标识的状态由处理中变更为处理失败。

可选地，状态管理单元还用于在将第二标识的状态由处理中变更为处理失败之后，在退还请求被配置为允许重复发起的情况下，将第二标识的状态由处理失败变更为待处理。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

根据本申请实施例的另一个方面，还提供了一种用于实施上述资源的退还方法的服务器或终端。

图4是根据本申请实施例的一种终端的结构框图，如图4所示，该终端可以包括：一个或多个(图4中仅示出一个)处理器401、存储器403、以及传输装置405，如图4所示，该终端还可以包括输入输出设备407。

其中，存储器403可用于存储软件程序以及模块，如本申请实施例中的资源的退还方法和装置对应的程序指令/模块，处理器401通过运行存储在存储器403内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的资源的退还方法。存储器403可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器403可进一步包括相对于处理器401远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置405用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置405包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置405为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器403用于存储应用程序。

处理器401可以通过传输装置405调用存储器403存储的应用程序，以执行下述步骤：

通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，第一资源与第二资源不同，目标缓存被设置为允许多个实例中的任一实例读取相应的标识；

查找与第一标识对应的第二标识，其中，第二标识用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源；

按照第二标识向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回对应的资源。

采用本申请实施例，上述多个实例是并行运行的，那么只要缓存中还存在未处理的原单标识，其他实例也会按照相同的流程去处理，假设每个实例处理一个原单标识需要的时间是T，那么处理N个原单标识需要的时间是(N*T)，考虑到若退款请求方只使用一个单实例应用，日处理能力有限，无法满足高频(如大促活动期间)的退款需求，而在本申请的技术方案中，假设多个实例的数量为M(M为大于等于2的正整数)，那么处理N个原单标识需要的时间是(N*T/M)，显然(N*T)是(N*T/M)的至少两倍，换言之，采用本申请的技术方案，可以解决了相关技术中退还虚拟资源的效率较低的技术问题，进而达到至少将效率提高50％的技术效果。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图4所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)、PAD等终端设备。图4其并不对上述电子装置的结构造成限定。例如，终端还可包括比图4中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图4所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行资源的退还方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，第一标识用于表示使用第二平台上目标对象的第一资源交换第一平台上的第二资源，第一资源与第二资源不同，目标缓存被设置为允许多个实例中的任一实例读取相应的标识；

查找与第一标识对应的第二标识，其中，第二标识用于表示请求向第一平台退回第三资源并请求在第二平台上向目标对象退回第四资源，第三资源属于第二资源，第四资源属于第一资源；

按照第二标识向第二平台发送资源退还请求，其中，资源退还请求用于请求向目标对象退回对应的资源。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种资源的退还方法，其特征在于，包括：

通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，所述第一标识用于表示使用第二平台上目标对象的第一资源交换所述第一平台上的第二资源，所述第一资源与所述第二资源不同，所述目标缓存被设置为允许所述多个实例中的任一实例读取相应的标识；

查找与所述第一标识对应的第二标识，其中，所述第二标识用于表示请求向所述第一平台退回第三资源并请求在所述第二平台上向所述目标对象退回第四资源，所述第三资源属于所述第二资源，所述第四资源属于所述第一资源；

按照所述第二标识向所述第二平台发送资源退还请求，其中，所述资源退还请求用于请求向所述目标对象退回对应的资源。

2.根据权利要求1所述的方法，其特征在于，通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识包括：

从所述多个实例中查找未发生异常的所述第一实例；

通过所述第一实例从所述目标缓存中获取所述第一标识。

3.根据权利要求1所述的方法，其特征在于，在所述第二标识为多个的情况下，按照所述第二标识向所述第二平台发送资源退还请求包括：

向所述第二平台发送多个所述资源退还请求，其中，每个所述资源退还请求用于请求向所述目标对象退回与一个所述第二标识匹配的资源；或，

向所述第二平台发送所述资源退还请求，其中，所述资源退还请求用于请求向所述目标对象退回与所有所述第二标识匹配的资源。

4.根据权利要求1至3中任意一条所述的方法，其特征在于，

查找与所述第一标识对应的第二标识包括：查找与所述第一标识对应的标识；从与所述第一标识对应的标识中查找状态为待处理的所述第二标识；

在查找与所述第一标识对应的第二标识之后，所述方法还包括：将所述退还请求的请求标识与所述第二标识关联，并将所述第二标识的状态由待处理变更为处理中。

5.根据权利要求1至3中任意一项所述的方法，其特征在于，在按照所述第二标识向所述第二平台发送资源退还请求之后，所述方法还包括：

在所述第二平台的反馈信息表明已经向所述目标对象退回对应的资源的情况下，向所述目标对象返回表示已经退回对应的资源的提示信息；

在所述第二平台的反馈信息表明向所述目标对象退回资源失败且所述退还请求被配置为不允许重复发起的情况下，向所述目标对象返回表示退回资源失败的提示信息；

在所述第二平台的反馈信息表明向所述目标对象退回资源的操作在处理中的情况下，按照目标时间周期从所述第二平台查询向所述目标对象退回资源的操作的处理状态。

6.根据权利要求1至3中任意一项所述的方法，其特征在于，在按照所述第二标识向所述第二平台发送资源退还请求之后，所述方法还包括：

在所述第二平台的反馈信息表明已经向所述目标对象退回对应的资源的情况下，将所述第二标识的状态由处理中变更为处理成功；

在所述第二平台的反馈信息表明向所述目标对象退回资源失败的情况下，将所述第二标识的状态由处理中变更为处理失败。

7.根据权利要求6所述的方法，其特征在于，在将所述第二标识的状态由处理中变更为处理失败之后，所述方法还包括：

在所述退还请求被配置为允许重复发起的情况下，将所述第二标识的状态由处理失败变更为待处理。

8.一种资源的退还装置，其特征在于，包括：

获取单元，用于通过多个实例中的第一实例从第一平台的目标缓存中获取第一标识，其中，所述第一标识用于表示使用第二平台上目标对象的第一资源交换所述第一平台上的第二资源，所述第一资源与所述第二资源不同，所述目标缓存被设置为允许所述多个实例中的任一实例读取相应的标识；

查找单元，用于查找与所述第一标识对应的第二标识，其中，所述第二标识用于表示请求向所述第一平台退回第三资源并请求在所述第二平台上向所述目标对象退回第四资源，所述第三资源属于所述第二资源，所述第四资源属于所述第一资源；

请求单元，用于按照所述第二标识向所述第二平台发送资源退还请求，其中，所述资源退还请求用于请求向所述目标对象退回对应的资源。

9.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1至7任一项中所述的方法。

10.一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器通过所述计算机程序执行上述权利要求1至7任一项中所述的方法。

Images