CN117035781A - 消息处理方法、装置、电子设备及介质 - Google Patents

Abstract

本公开关于一种消息处理方法、装置、电子设备及介质。该方法包括：接收信息处理请求；解析所述信息处理请求，确定所述信息处理请求对应的第一账户和第二账户，根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户；调用支付渠道，向所述目标出资账户发起资源退还操作。本公开在接收到信息处理请求的情况下，首先确定信息处理请求对应的目标出资账户，然后调用支付渠道向目标出资账户发起退款，可以提前确定出退款应出资账户，将调用支付渠道资源退还接口的次数减少为一次，节省了资源退还接口容量资源，提高了资源退还接口的利用率，缩短了资源退还链路，提高了资源退还时效，提升了用户体验。

Description

消息处理方法、装置、电子设备及介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种消息处理方法、装置、电子设备及介质。

背景技术

用户在购物平台购买物品支付成功后，会显示“申请退款”、“退款”、“售后”等控件。若用户因某些原因不想要了，可以通过该控件申请退款。购物平台接收到用户的信息处理请求后，会调用支付渠道(如第三方支付渠道)，将用户支付的资金退回用户账户。相关技术中，一般有两个账户用于为用户退款，一个是资源提供方账户(如商户账户)，另一个是资源交互平台的账户(如平台垫资账户)。在给用户退款时，购物平台首先使用资源提供方账户出资，调用第三方支付渠道发起退款，如果支付渠道返回成功，那么用户退款成功。如果支付渠道返回失败，购物平台会使用资源交互平台的账户出资，调用第三方支付渠道发起退款。如此，相关技术在为用户退款时，会存在调用支付渠道两次的情况，浪费了支付渠道的资源退还接口容量资源，在高并发的情况下(如大促期间)可能会导致退款延时或资源退还失败。另外，两次调用支付渠道进行退款的过程增加了资源退还链路，资源退还时效性较差，用户体验差。

发明内容

本公开提供一种消息处理方法、装置、电子设备及介质，以至少解决相关技术中浪费资源退还接口容量资源、资源退还时效性差以及资源退还失败的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种消息处理方法，包括接收信息处理请求；解析所述信息处理请求，确定所述信息处理请求对应的第一账户和第二账户，根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户；所述第一账户为所述信息处理请求对应的资源提供方的账户，所述第二账户为所述信息处理请求对应的资源交互平台的账户；调用支付渠道的资源退还接口，向所述目标出资账户发起资源退还操作。

可选地，所述从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：确定所述信息处理请求对应的信息队列，将所述信息处理请求添加至所述信息队列中；按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求；所述聚合信息处理请求的资源交互总额等于所述至少一个信息处理请求的资源交互额之和；从所述第一账户和所述第二账户中确定所述聚合信息处理请求对应的目标出资账户。

可选地，所述按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求，包括：基于预设的聚合周期，定时对所述信息队列中的至少一个信息处理请求进行聚合。

可选地，所述按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求，包括：实时统计所述信息队列中的信息处理请求的数量；当所述信息队列中的信息处理请求的数量达到目标阈值时，对所述信息队列中的信息处理请求进行聚合，生成聚合信息处理请求。

可选地，所述方法还包括：实时记录所述信息处理请求的入队时长：在所述信息队列中信息处理请求的数量未达到目标阈值的情况下，确定所述信息队列中的信息处理请求的入队时长是否达到预设时长；在所述信息队列中的信息处理请求的入队时长达到预设时长的情况下，对所述信息队列中入队时长达到预设时长的信息处理请求进行聚合，生成聚合信息处理请求。

可选地，所述根据第一预设规则，从第一账户和第二账户中确定所述信息处理请求对应的目标出资账户，包括：解析所述信息处理请求，确定所述信息处理请求对应的第一资源提供方标识；确定所述第一资源提供方标识对应的第一存余账户，确定所述第一存余账户内的资源余存值是否小于所述信息处理请求的资源交互额，获得第一确定结果；根据所述第一确定结果，从第一账户和第二账户中确定所述信息处理请求对应的目标出资账户。

可选地，所述根据所述第一确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第一账户；响应于所述第一存余账户内的资源余存值小于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第二账户。

可选地，所述方法还包括：响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，基于所述资源交互额，扣减所述第一存余账户内的资源余存值。

可选地，所述方法还包括：接收资源支付请求；响应于所述资源支付请求，确定所述资源支付请求对应的第二资源提供方标识；确定所述第二资源提供方标识对应的第二存余账户，基于所述资源支付请求的资源支付额，增加所述第二存余账户内的资源余存值。

可选地，所述方法还包括：按照预设的重置周期，重置所述第一存余账户内的资源余存值，并设置更新后的所述第一存余账户内的资源余存值为初始值。

可选地，所述根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：解析所述信息处理请求，确定所述信息处理请求对应的订单支付时间；确定所述订单支付时间是否满足预设条件，获得第二确定结果；根据所述第二确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户。

可选地，所述确定所述订单支付时间是否满足预设条件，包括：确定所述订单支付时间与所述信息处理请求的接收时间是否属于同一计费周期。

可选地，所述根据第二确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：响应于所述订单支付时间与所述信息处理请求的接收时间属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第一账户；响应于所述订单支付时间与所述信息处理请求的接收时间不属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第二账户。

根据本公开实施例的第二方面，提供一种消息处理装置，包括：接收单元，被配置为接收信息处理请求；确定单元，被配置为解析所述信息处理请求，确定所述信息处理请求对应的第一账户和第二账户，根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户；所述第一账户为所述信息处理请求对应的资源提供方的账户，所述第二账户为所述信息处理请求对应的资源交互平台的账户；调用单元，被配置为调用支付渠道，向所述目标出资账户发起资源退还操作。

可选地，所述确定单元被配置为：确定所述信息处理请求对应的信息队列，将所述信息处理请求添加至所述信息队列中；按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求；所述聚合信息处理请求的资源交互总额等于所述至少一个信息处理请求的资源交互额之和；从所述第一账户和所述第二账户中确定所述聚合信息处理请求对应的目标出资账户。

可选地，所述确定单元被配置为：基于预设的聚合周期，定时对所述信息队列中的至少一个信息处理请求进行聚合。

可选地，所述确定单元被配置为：实时统计所述信息队列中的信息处理请求的数量；当所述信息队列中的信息处理请求的数量达到目标阈值时，对所述信息队列中的信息处理请求进行聚合，生成聚合信息处理请求。

可选地，所述确定单元被配置为：实时记录所述信息处理请求的入队时长：在所述信息队列中信息处理请求的数量未达到目标阈值的情况下，确定所述信息队列中的信息处理请求的入队时长是否达到预设时长；在所述信息队列中的信息处理请求的入队时长达到预设时长的情况下，对所述信息队列中入队时长达到预设时长的信息处理请求进行聚合，生成聚合信息处理请求。

可选地，所述确定单元被配置为：解析所述信息处理请求，确定所述信息处理请求对应的第一资源提供方标识；确定所述第一资源提供方标识对应的第一存余账户，确定所述第一存余账户内的资源余存值是否小于所述信息处理请求的资源交互额，获得第一确定结果；根据所述第一确定结果，从第一账户和第二账户中确定所述信息处理请求对应的目标出资账户。

可选地，所述确定单元被配置为：响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第一账户；响应于所述第一存余账户内的资源余存值小于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第二账户。

可选地，所述装置还包括扣减单元，被配置为：响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，基于所述资源交互额，扣减所述第一存余账户内的资源余存值。

可选地，所述装置还包括增调单元，被配置为：接收资源支付请求；响应于所述资源支付请求，确定所述资源支付请求对应的第二资源提供方标识；确定所述第二资源提供方标识对应的第二存余账户，基于所述资源支付请求的资源支付额，增加所述第二存余账户内的资源余存值。

可选地，所述装置还包括重置单元，被配置为：按照预设的重置周期，重置所述第一存余账户内的资源余存值，并设置更新后的所述第一存余账户内的资源余存值为初始值。

可选地，所述确定单元被配置为：解析所述信息处理请求，确定所述信息处理请求对应的订单支付时间；确定所述订单支付时间是否满足预设条件，获得第二确定结果；根据所述第二确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户。

可选地，所述确定单元被配置为：确定所述订单支付时间与所述信息处理请求的接收时间是否属于同一计费周期。

可选地，所述确定单元被配置为：响应于所述订单支付时间与所述信息处理请求的接收时间属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第一账户；响应于所述订单支付时间与所述信息处理请求的接收时间不属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第二账户。

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现本公开任一实施例所述的消息处理方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行，以使计算机实现本公开任一实施例所述的消息处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，所述计算机程序产品包括计算机程序或计算机指令，所述计算机程序或计算机指令由处理器加载并执行，以使计算机实现本公开任一实施例所述的消息处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本公开实施例的消息处理方法在接收到信息处理请求的情况下，首先确定信息处理请求对应的目标出资账户，然后调用支付渠道向目标出资账户发起退款，可以提前确定出退款应出资账户，将调用支付渠道资源退还接口的次数减少为一次，节省了资源退还接口容量资源，提高了资源退还接口的利用率，并且缩短了资源退还链路，提高了资源退还时效，提升了用户体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种消息处理方法的应用环境示意图；

图2是根据一示例性实施例示出的一种消息处理方法的流程图；

图3是根据一示例性实施例示出的一种消息处理方法的子流程图；

图4是根据一示例性实施例示出的一种消息处理方法的子流程图；

图5是根据一示例性实施例示出的一种消息处理方法的流程图；

图6是根据一示例性实施例示出的一种消息处理方法的存余账户的示意图；

图7是根据一示例性实施例示出的一种消息处理方法的流程图；

图8是根据一示例性实施例示出的一种消息处理装置的框图；

图9是根据一示例性实施例示出的一种服务器的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

请参阅图1，其所示为根据一示例性实施例示出的一种消息处理方法的应用环境示意图，该应用环境可以包括终端11和服务器12，该终端11和服务器12通过无线网络连接。

终端11可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此，终端11上安装有提供人机交互功能的客户端软件如应用程序(Application，简称为App)，该应用程序可以是独立的应用程序，也可以是应用程序中的子程序。示例性的，该应用程序可以是短视频类应用程序、或即时通信类应用程序。

服务器12可以是为终端11中的应用程序提供后台服务的服务器。服务器12可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统。

本领域技术人员可以知晓，上述终端的数量可以仅为一个，几十个或几百个，或者更多数量。本公开实施例对终端的数量和设备类型不加以限定。

图2是根据一示例性实施例示出的一种消息处理方法的流程图，如图2所示，该消息处理方法用于如图1所示的服务器12中，包括以下步骤：

步骤S201：接收信息处理请求。

在一种可能的应用场景中，用户在购物平台如购物网站或购物APP(Application，应用程序)上发起资源退还操作，如用户点击购物网站或购物APP页面上显示的“退款”或“售后”控件，购物网站或购物APP检测到用户的点击操作，生成信息处理请求，并将该信息处理请求发送至服务器。解析该信息处理请求，可以获得包括但不限于以下信息：用户标识(如用户ID)、资源提供方标识(如资源提供方ID，该资源提供方ID可以是店铺的名称、主播的ID等)、资源交互额、信息处理请求的接收时间、订单号、订单支付的时间。

步骤S202：解析所述信息处理请求，确定所述信息处理请求对应的第一账户和第二账户，根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，所述第一账户为所述信息处理请求对应的资源提供方的账户，所述第二账户为所述信息处理请求对应的资源交互平台的账户。

在本公开实施例中，第一账户和第二账户均是用来给用户退款的，第一账户可以是资源提供方账户，第二账户可以平台账户或平台垫资账户。在本实施例中无论从第一账户出资为用户退款，还是从第二账户出资为用户退款，都需要调用支付渠道的资源退还接口，通过支付渠道的资源退还接口进行退款。

在本步骤中，在接收到信息处理请求后，可以从信息处理请求中解析出资源提供方标识，根据该资源提供方标识确定信息处理请求对应的第一账户和第二账户。然后，可以根据从信息处理请求中解析出的信息，例如用户标识、资源提供方标识、资源交互额、信息处理请求的接收时间、订单号、订单支付的时间等确定目标出资账户。

在一种可能的应用场景中，可以根据资源提供方标识确定目标出资账户，例如预先将购物平台上的资源提供方(如商家)分为两类，其中一类的资源提供方对应的出资账户为第一账户，另一类资源提供方对应的出资账户为第二账户。例如，可以将评分高于或等于参考值的资源提供方为一类用户，评分低于参考值的资源提供方为另一类用户，评分高于或等于参考值的资源提供方的信息处理请求对应的目标出资账户为第一账户，评分低于参考值的资源提供方的信息处理请求对应的目标出资账户为第一账户。从而，在接收到信息处理请求后，可以先确定该信息处理请求对应的资源提供方的类型，进而根据资源提供方的类型确定出该信息处理请求对应的目标出资账户。

在另一种可能的应用场景中，可以根据用户标识确定目标出资账户，例如预先将购物平台上的注册用户分类两类，一类用户对应的出资账户为第一账户，另一类用户对应的出资账户为第二账户。在接收到信息处理请求后，可以先确定发起该信息处理请求的用户的类别，进而根据用户的类别确定出该信息处理请求对应的目标出资账户。

在另一种可能的应用场景中，可以预先为每个资源提供方建立对应的资源存余账户。在接收到信息处理请求后，先确定该信息处理请求对应的存余账户内的资源余存值是否满足条件，如果满足条件，则确定目标出资账户为第一账户，如果不满足条件，则确定目标出资账户为第二账户。例如，可以确定存余账户内的资源余存值是否大于或等于信息处理请求的资源交互额，如果存余账户内的资源余存值大于或等于信息处理请求的资源交互额，则目标出资账户为第一账户，如果存余账户内的资源余存值小于信息处理请求的资源交互额，则目标出资账户为第二账户。

步骤S203：调用支付渠道的资源退还接口，向所述目标出资账户发起资源退还操作。

在确定目标出资账户之后，即可调用支付渠道(如第三方支付渠道)，通过该支付渠道的资源退还接口向目标出资账户发起资源退还操作，为用户退还资源。

本公开实施例的消息处理方法在接收到信息处理请求的情况下，首先确定信息处理请求对应的目标出资账户，然后调用支付渠道向目标出资账户发起退款，可以提前确定出退款应出资账户，将调用支付渠道资源退还接口的次数减少为一次，节省了资源退还接口容量资源，提高了资源退还接口的利用率，并且缩短了资源退还链路，提高了资源退还时效，提升了用户体验。

本公开实施例考虑到在某些场景下(例如购物节大促期间)可能存在同一时刻有大量用户发起信息处理请求的情况(即高并发的情况)，本公开实施例在接收到信息处理请求的情况下，先将信息处理请求添加至信息队列中，然后对信息队列中的多个信息处理请求进行聚合，聚合为一个聚合信息处理请求，调用一次支付渠道为该聚合信息处理请求退款，从而将调用支付渠道的次数由多次减少为一次，从而进一步节约了支付渠道资源退还接口的容量资源，提高了资源退还接口利用率和退款成功率。

其中，将信息处理请求添加至信息队列中，对信息队列中的多个信息处理请求进行聚合，并调用支付渠道为该聚合信息处理请求退款的过程如图3所示，包括：

步骤S301：响应于信息处理请求，确定信息处理请求对应的信息队列，将信息处理请求添加至信息队列中。

在本公开一些实施例中，可以预先为每个资源提供方创建对应的信息队列，该信息队列可以与资源提供方的资源提供方标识一一对应。在接收到信息处理请求的情况下，解析该信息处理请求，获得资源提供方标识，进而确定信息处理请求对应的信息队列。在一种可能的应用场景中，例如可以利用Redis构建信息队列，构建的信息队列相当于对接收到的信息处理请求进行缓存，在满足预设规则或预设条件时对信息队列中的信息处理请求进行聚合。

步骤S302：按照第二预设规则，对信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求；聚合信息处理请求的资源交互总额等于至少一个信息处理请求的资源交互额之和。

在本步骤中，对信息队列中的信息处理请求进行聚合的规则可以预先设置，并可以灵活调整。

在一种可能的应用场景中，可以基于预设的聚合周期，定时对信息队列中的至少一个信息处理请求进行聚合，以此在保证资源退还时效的同时减少调用支付渠道的次数，节省支付渠道资源退还接口的容量资源，提高接口利用率。其中，聚合周期可以根据场景需求灵活设置，本发明在此不做限制。作为具体的示例，聚合周期可以设置为3秒。

在另一种可能的应用场景中，可以实时统计信息队列中的信息处理请求的数量，根据信息处理请求的数量进行聚合，以此将多个信息处理请求聚合为一个聚合信息处理请求，将调用支付渠道的次数由多次减少为一次，有效节省了支付渠道资源退还接口的容量资源，提高了接口利用率。例如，当信息队列中的信息处理请求的数量达到目标阈值时对信息处理请求进行聚合。其中，目标阈值可以根据场景需求灵活设置，本发明在此不做限制。作为具体的示例，目标阈值可以设置为5。

步骤S303：从所述第一账户和所述第二账户中确定所述聚合信息处理请求对应的目标出资账户。

在本步骤中，可以解析聚合信息处理请求，确定聚合信息处理请求对应的第一资源提供方标识，然后确定第一资源提供方标识对应的第一存余账户，并确定第一存余账户内的余额是否大于或等于聚合信息处理请求的资源交互额。如果第一存余账户内的余额大于或等于聚合信息处理请求的资源交互额，则确定目标出资账户为第一账户；如果第一存余账户内的余额小于聚合信息处理请求的资源交互额，则确定目标出资账户为第二账户。

由于接收到的信息处理请求的数量是不可控的，可能存在信息处理请求的数量在较长一段时间内还未达到目标阈值的情况，在这种情况下仅根据信息处理请求的数量进行聚合，无法及时为用户退款，资源退还时效性差，影响用户体验。为了解决该技术问题，如图4所示，本公开实施例的消息处理方法可以包括：

步骤S401：响应于接收到信息处理请求，将信息处理请求添加至对应的信息队列中，并实时记录所述信息处理请求的入队时长。在本实施例中，可以预先为每一个资源提供方建立一个信息队列，在接收到信息处理请求之后，解析信息处理请求，确定信息处理请求对应的资源提供方标识，根据资源提供方标识确定信息处理请求对应的信息队列。对于信息处理请求的入队时长，可以在添加信息处理请求时记录信息处理请求的添加时间，基于该添加时间，记录信息处理请求的入队时长。

步骤S402：实时记录信息队列中的信息处理请求的数量。

步骤S403：在信息队列中的信息处理请求的数量达到目标阈值的情况下，对信息队列中的信息处理请求进行聚合，生成聚合信息处理请求。

步骤S404：在信息队列中信息处理请求的数量未达到目标阈值的情况下，确定信息处理请求的入队时长是否达到预设时长。

步骤S405：在信息队列中的信息处理请求的入队时长达到预设时长的情况下，对信息队列中入队时长达到预设时长的信息处理请求进行聚合，生成聚合信息处理请求。

步骤S406：从第一账户和第二账户中确定聚合信息处理请求对应的目标出资账户。

在本实施例中，结合信息处理请求的数量和入队时长来确定聚合的信息处理请求。首先，根据信息处理请求的数量确定是否需要对缓存队列中的信息处理请求进行聚合，若信息处理请求的数量达到目标阈值，则对信息队列中的信息处理请求进行聚合，若信息处理请求的数量未达到目标阈值，则对信息处理请求的入队时长进行确定，若入队时长达到预设时长，则对信息处理请求进行聚合。例如，设置目标阈值为5，预设时长为30秒。在1月1日11:00：00将第一信息处理请求添加至信息队列，在1月1日11：00：10将第二信息处理请求和第三信息处理请求添加至信息队列，第一信息处理请求、第二信息处理请求和第三信息处理请求都是针对同一资源提供方的信息处理请求，可以添加至同一信息队列中。实时统计信息队列中信息处理请求的数量以及入队时长。在1月1日11：00：30时，信息队列中只有第一信息处理请求、第二信息处理请求和第三信息处理请求，信息队列中信息处理请求的数量未达到目标阈值，且第一信息处理请求的入队时长达到预设时长，则基于第一信息处理请求生成聚合信息处理请求，该聚合信息处理请求的资源交互额等于第一信息处理请求的资源交互额。在1月1日11：00：40时，信息队列中只有第二信息处理请求和第三信息处理请求，信息处理请求的数量未达到目标阈值，且第二信息处理请求和第三信息处理请求的入队时长达到预设时长，则基于第二信息处理请求和第三信息处理请求生成聚合信息处理请求，该聚合信息处理请求的资源交互额等于第一信息处理请求与第二信息处理请求的资源交互额之和。

在生成聚合信息处理请求之后，可以基于聚合信息处理请求对应的第一资源提供方标识，确定第一资源提供方标识对应的第一存余账户，并确定第一存余账户内的余额是否大于或等于聚合信息处理请求的资源交互额。如果第一存余账户内的余额大于或等于聚合信息处理请求的资源交互额，则确定目标出资账户为第一账户；如果第一存余账户内的余额小于聚合信息处理请求的资源交互额，则确定目标出资账户为第二账户。

本公开实施例的消息处理方法，在接收到信息处理请求的情况下，先将信息处理请求添加至信息队列中，然后对信息队列中的至少一个信息处理请求进行聚合，聚合为一个聚合信息处理请求，调用一次支付渠道为该聚合信息处理请求退款，从而将调用支付渠道的次数由多次减少为一次，从而进一步节约了支付渠道资源退还接口的容量资源，提高了资源退还接口利用率和退款成功率。

图5是根据一示例性实施例示出的一种消息处理方法的流程图，如图5所示，该消息处理方法包括：

步骤S501：接收信息处理请求。

步骤S502：解析所述信息处理请求，确定所述信息处理请求对应的第一资源提供方标识。

在本步骤中，解析该信息处理请求，可以获取该信息处理请求对应的第一资源提供方标识，该资源提供方标识可以是用户的唯一标识，例如店铺名称、主播ID号等。解析该信息处理请求还可以获取以下一项或多项信息：用户标识(如用户ID)、资源交互额、接收信息处理请求的时间、订单号和订单支付的时间。

步骤S503：确定所述第一资源提供方标识对应的第一存余账户。

步骤S504：确定所述第一存余账户内的资源余存值是否小于所述信息处理请求的资源交互额。

步骤S505：响应于第一存余账户内的资源余存值大于或等于信息处理请求的资源交互额，确定目标出资账户为第一账户。

步骤S506：响应于第一存余账户内的资源余存值小于信息处理请求的资源交互额，确定目标出资账户为第二账户。

步骤S507：响应于第一存余账户内的资源余存值大于或等于信息处理请求的资源交互额，基于所述资源交互额，扣减所述第一存余账户内的资源余存值。在第一存余账户内的余额大于或等于资源交互额的情况下，需要扣减存余账户内的余额，扣减的余额为信息处理请求的资源交互额。

步骤S508：调用支付渠道，向所述目标出资账户发起资源退还操作。

步骤S509：接收资源支付请求；

步骤S510：响应于所述资源支付请求，确定所述资源支付请求对应的第二资源提供方标识；

步骤S511：确定所述第二资源提供方标识对应的第二存余账户，基于所述资源支付请求的资源支付额，增加所述第二存余账户内的资源余存值。

在本公开实施例中，可以为每一个资源提供方建立一个存余账户，该存余账户只作为确定出资账户的依据，在建立存余账户时可以设置存余账户的资源余存值为初始值，初始值可以根据应用场景灵活设置，作为具体的示例，初始值可以是零。当接收到针对某一资源提供方的资源支付请求时，可以增加该资源提供方对应的存余账户的资源余存值，当接收到针对某一资源提供方的信息处理请求时，可以扣减该资源提供方对应的存余账户的资源余存值。当存余账户内的资源余存值大于或等于资源交互额时，即扣减成功时，出资账户为第一账户，当存余账户内的余额小于资源交互额时，即扣减失败时出资账户为第二账户。同样地，对于上述第一存余账户，若第一存余账户内的余额大于或等于信息处理请求的资源交互额，则目标出资账户为第一账户，若第一存余内的余额小于该资源交互额，则目标出资账户为第二账户。

在本公开一些可选的实施例中，该消息处理方法还可以包括如下过程：按照预设的重置周期，重置所述第一存余账户内的资源余存值，并设置更新后的所述第一存余账户内的资源余存值为初始值。在该实施例中，每个资源提供方的存余账户都是按照重置周期定时重置，该重置周期例如可以是每天重置一次。重置后的存余账户内的余额可以是预设的初始值，该初始值可以是零，也可以是其他值，本公开在此不做限制。

为使本公开实施例的消息处理方法更加清楚，以下述示例为例进行说明。

在该示意性实施例中，为每个资源提供方建立的存余账户为每日余额账户，该每日余额账户以天为重置周期，按天重置，重置后的每日余额账户内的资源余存值为零。例如，1月1日为每个资源提供方建立一个每日余额账户，该每日余额账户可以命名为“每日余额账户-1.1”。在1月2日，每个资源提供方的每日余额账户进行重置，重置后的资源余存值为零，重置后的每日余额账户可以命名为“每日余额账户-1.2”。在本实施例中，对每日余额账户进行重置也可以理解为每天都为资源提供方建立一个每日余额账户，重新建立的每日余额账户内的资源余存值为零。如图6所示，当用户购买商品时，可以根据商品所属资源提供方的资源提供方标识以及当前日期(接收到资源支付请求的日期)，确定对应的每日余额账户，增加该每日余额账户内的资源余存值，增加的资源余存值为资源支付请求的资源支付额，当用户发起退款时，可以根据商品所属资源提供方的资源提供方标识以及当前日期(接收到信息处理请求的日期)，确定对应的每日余额账户，扣减该每日余额账户内的资源余存值，扣减的资源余存值为资源支付请求的资源支付额，若扣减成功(即每日余额账户内的余额大于或等于信息处理请求的资源交互额)，则确定该信息处理请求对应的目标出资账户为第一账户，若扣减失败(即每日余额账户内的余额小于信息处理请求的资源交互额)，则确定该信息处理请求对应的目标出资账户为第二账户。例如，用户在1月1日确定购买某一商品并发起支付操作请求后，购物APP生成资源支付请求，该资源支付请求可以包括资源提供方标识、用户标识、商品标识和资源支付额等信息。购物APP将该资源支付请求发送至服务器。服务器接收到资源支付请求后，对该资源支付请求进行解析，确定资源支付请求对应的资源提供方标识，根据该资源提供方标识以及接收到资源支付请求的时间确定对应的存余账户：“每日余额账户-1.1”，然后增加该存余账户内的资源余存值，增加的资源余存值为资源支付请求的资源支付额。用户在1月2日发现商品买错了，需要进行退款。用户在购物APP上点击“退款”控件，购物APP生成信息处理请求，该信息处理请求可以包括资源提供方标识、用户标识、商品标识、资源交互额等信息。购物APP将该信息处理请求发送至服务器。服务器接收到信息处理请求后，对该信息处理请求进行解析，确定资源提供方标识，根据该资源提供方标识和接收到信息处理请求的接收时间确定对应的存余账户：“每日余额账户-1.2”。确定存余账户“每日余额账户-1.2”的资源余存值是否大于或等于资源交互额，当存余账户内的资源余存值大于或等于资源交互额时，出资账户为第一账户，当存余账户内的余额小于资源交互额时，出资账户为第二账户。然后，调用支付渠道，向出资账户发起资源退还操作，为用户退款。其中，当存余账户内的资源余存值大于或等于资源交互额时，还需要扣减存余账户的资源余存值，扣减的资源余存值等于资源交互额。当存余账户内的资源余存值小于资源交互额时，不需要扣减资源余存值。

本公开实施例的消息处理方法，为每个资源提供方建立了对应的存余账户，在接收到信息处理请求时，先确定该信息处理请求对应的存余账户内的余额是否大于或等于信息处理请求的资源交互额，再根据确定结果确定目标出资账户，可以通过简单的流程提前确定出退款应出资账户，将调用支付渠道资源退还接口的次数减少为一次，节省了资源退还接口容量资源，提高了资源退还接口的利用率，并且缩短了资源退还链路，提高了资源退还时效，提升了用户体验。

图7是根据一示例性实施例示出的一种消息处理方法的流程图，如图7所示，该消息处理方法包括：

步骤S701：接收信息处理请求。

步骤S702：解析所述信息处理请求，确定所述信息处理请求对应的订单支付时间。

步骤S703：确定所述订单支付时间是否满足预设条件，获得第二确定结果。

该预设条件可以提前设置，也可以根据需求灵活更改。在一种可能的应用场景中，该预设条件可以是确定订单支付时间与信息处理请求的发起时间是否属于同一计费周期。其中，计费周期可以根据场景需求灵活设置，本公开在此不做限制。作为具体示例，一天为一个计费周期。例如，订单支付时间为1月1日10:00:00，则在1月2日10:00:00之前接收到的信息处理请求都属于同一计费周期。在1月2日10:00:00之后接收到的信息处理请求不在同一计费周期。

步骤S704：根据所述第二确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户。

在一种可能的应用场景中，当订单支付时间与信息处理请求的发起时间属于同一计费周期时，确定信息处理请求对应的目标出资账户为第一账户；当订单支付时间与信息处理请求的发起时间不属于同一计费周期时，确定信息处理请求对应的目标出资账户为第二账户。

步骤S705：调用支付渠道的资源退还接口，向所述目标出资账户发起资源退还操作。

本公开实施例的消息处理方法，根据信息处理请求对应的订单的支付时间确定目标出资账户，可以提前确定出退款应出资账户，将调用支付渠道资源退还接口的次数减少为一次，节省了资源退还接口容量资源，提高了资源退还接口的利用率，并且缩短了资源退还链路，提高了资源退还时效，提升了用户体验。

图8是根据一示例性实施例示出的一种消息处理装置800的框图。如图8所示，该消息处理装置800包括接收单元801、确定单元802和调用单元803。

其中，接收单元801，被配置为接收信息处理请求。

确定单元802，被配置为解析所述信息处理请求，确定所述信息处理请求对应的第一账户和第二账户，根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户；所述第一账户为所述信息处理请求对应的资源提供方的账户，所述第二账户为所述信息处理请求对应的资源交互平台的账户。

调用单元803，被配置为调用支付渠道的资源退还接口，向所述目标出资账户发起资源退还操作。

在本公开一示例性实施例中，所述确定单元被配置为：确定所述信息处理请求对应的信息队列，将所述信息处理请求添加至所述信息队列中；按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求；所述聚合信息处理请求的资源交互总额等于所述至少一个信息处理请求的资源交互额之和；从所述第一账户和所述第二账户中确定所述聚合信息处理请求对应的目标出资账户。

在本公开一示例性实施例中，所述确定单元被配置为：基于预设的聚合周期，定时对所述信息队列中的至少一个信息处理请求进行聚合。

在本公开一示例性实施例中，所述确定单元被配置为：实时统计所述信息队列中的信息处理请求的数量；当所述信息队列中的信息处理请求的数量达到目标阈值时，对所述信息队列中的信息处理请求进行聚合，生成聚合信息处理请求。

在本公开一示例性实施例中，所述确定单元被配置为：实时记录所述信息处理请求的入队时长：在所述信息队列中信息处理请求的数量未达到目标阈值的情况下，确定所述信息队列中的信息处理请求的入队时长是否达到预设时长；在所述信息队列中的信息处理请求的入队时长达到预设时长的情况下，对所述信息队列中入队时长达到预设时长的信息处理请求进行聚合，生成聚合信息处理请求。

在本公开一示例性实施例中，所述确定单元被配置为：解析所述信息处理请求，确定所述信息处理请求对应的第一资源提供方标识；确定所述第一资源提供方标识对应的第一存余账户，确定所述第一存余账户内的资源余存值是否小于所述信息处理请求的资源交互额，获得第一确定结果；根据所述第一确定结果，从第一账户和第二账户中确定所述信息处理请求对应的目标出资账户。

在本公开一示例性实施例中，所述确定单元被配置为：响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第一账户；响应于所述第一存余账户内的资源余存值小于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第二账户。

在本公开一示例性实施例中，所述装置还包括扣减单元，被配置为：响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，基于所述资源交互额，扣减所述第一存余账户内的资源余存值。

在本公开一示例性实施例中，所述装置还包括增调单元，被配置为：接收资源支付请求；响应于所述资源支付请求，确定所述资源支付请求对应的第二资源提供方标识；确定所述第二资源提供方标识对应的第二存余账户，基于所述资源支付请求的资源支付额，增加所述第二存余账户内的资源余存值。

在本公开一示例性实施例中，所述装置还包括重置单元，被配置为：按照预设的重置周期，重置所述第一存余账户内的资源余存值，并设置更新后的所述第一存余账户内的资源余存值为初始值。

在本公开一示例性实施例中，所述确定单元被配置为：解析所述信息处理请求，确定所述信息处理请求对应的订单支付时间；确定所述订单支付时间是否满足预设条件，获得第二确定结果；根据所述第二确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户。

在本公开一示例性实施例中，所述确定单元被配置为：确定所述订单支付时间与所述信息处理请求的接收时间是否属于同一计费周期。

可选地，所述确定单元被配置为：响应于所述订单支付时间与所述信息处理请求的接收时间属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第一账户；响应于所述订单支付时间与所述信息处理请求的接收时间不属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第二账户。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图9是根据一示例性实施例示出的一种电子设备如服务器的结构示意图。参照图9，服务器900包括处理组件901，其进一步包括一个或多个处理器，以及由存储器902所代表的存储器资源，用于存储可由处理组件901的执行的指令，例如应用程序。存储器902中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件901被配置为执行指令，以执行上述消息处理的实现方法。

服务器900还可以包括一个电源组件903被配置为执行服务器900的电源管理，一个有线或无线网络接口904被配置为将服务器900连接到网络，和一个输入输出(I/O)接口905。电子设备900可以操作基于存储在存储器902的操作系统，例如WindowsServerTM，MacOS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

在示例性实施例中，还提供了一种包括指令的存储介质，当所述存储介质中的指令由服务器的处理器执行时，使得服务器能够执行如上述任一方法所述消息处理方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品，该计算机程序产品包括可读性程序代码，该可读性程序代码可由服务器的处理器执行以完成上述消息处理方法。可选地，该程序代码可以存储在终端或服务器的存储介质中，该存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。在本公开中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

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

Claims (17)

1.一种消息处理方法，其特征在于，包括：

接收信息处理请求；

解析所述信息处理请求，确定所述信息处理请求对应的第一账户和第二账户，根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户；所述第一账户为所述信息处理请求对应的资源提供方的账户，所述第二账户为所述信息处理请求对应的资源交互平台的账户；

调用支付渠道的资源退还接口，向所述目标出资账户发起资源退还操作。

2.根据权利要求1所述的方法，其特征在于，所述从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：

确定所述信息处理请求对应的信息队列，将所述信息处理请求添加至所述信息队列中；

按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求；所述聚合信息处理请求的资源交互总额等于所述至少一个信息处理请求的资源交互额之和；

从所述第一账户和所述第二账户中确定所述聚合信息处理请求对应的目标出资账户。

3.根据权利要求2所述的方法，其特征在于，所述按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求，包括：

基于预设的聚合周期，定时对所述信息队列中的至少一个信息处理请求进行聚合。

4.根据权利要求2所述的方法，其特征在于，所述按照第二预设规则，对所述信息队列中的至少一个信息处理请求进行聚合，生成聚合信息处理请求，包括：

实时统计所述信息队列中的信息处理请求的数量；

当所述信息队列中的信息处理请求的数量达到目标阈值时，对所述信息队列中的信息处理请求进行聚合，生成聚合信息处理请求。

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

实时记录所述信息处理请求的入队时长：

在所述信息队列中信息处理请求的数量未达到目标阈值的情况下，确定所述信息队列中的信息处理请求的入队时长是否达到预设时长；

在所述信息队列中的信息处理请求的入队时长达到预设时长的情况下，对所述信息队列中入队时长达到预设时长的信息处理请求进行聚合，生成聚合信息处理请求。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：

解析所述信息处理请求，确定所述信息处理请求对应的第一资源提供方标识；

确定所述第一资源提供方标识对应的第一存余账户，确定所述第一存余账户内的资源余存值是否小于所述信息处理请求的资源交互额，获得第一确定结果；

根据所述第一确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户。

7.根据权利要求6所述的方法，其特征在于，所述根据所述第一确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：

响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第一账户；

响应于所述第一存余账户内的资源余存值小于所述信息处理请求的资源交互额，确定所述信息处理请求对应的目标出资账户为第二账户。

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

响应于所述第一存余账户内的资源余存值大于或等于所述信息处理请求的资源交互额，基于所述资源交互额，扣减所述第一存余账户内的资源余存值。

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

接收资源支付请求；

响应于所述资源支付请求，确定所述资源支付请求对应的第二资源提供方标识；

确定所述第二资源提供方标识对应的第二存余账户，基于所述资源支付请求的资源支付额，增加所述第二存余账户内的资源余存值。

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

按照预设的重置周期，重置所述第一存余账户内的资源余存值，并设置更新后的所述第一存余账户内的资源余存值为初始值。

11.根据权利要求1-5任一项所述的方法，其特征在于，所述根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：

解析所述信息处理请求，确定所述信息处理请求对应的订单支付时间；

确定所述订单支付时间是否满足预设条件，获得第二确定结果；

根据所述第二确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户。

12.根据权利要求11所述的方法，其特征在于，所述确定所述订单支付时间是否满足预设条件，包括：

确定所述订单支付时间与所述信息处理请求的接收时间是否属于同一计费周期。

13.根据权利要求12所述的方法，其特征在于，所述根据第二确定结果，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户，包括：

响应于所述订单支付时间与所述信息处理请求的接收时间属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第一账户；

响应于所述订单支付时间与所述信息处理请求的接收时间不属于同一计费周期，确定所述信息处理请求对应的目标出资账户为第二账户。

14.一种消息处理装置，其特征在于，包括：

接收单元，被配置为接收信息处理请求；

确定单元，被配置为解析所述信息处理请求，确定所述信息处理请求对应的第一账户和第二账户，根据第一预设规则，从所述第一账户和所述第二账户中确定所述信息处理请求对应的目标出资账户；所述第一账户为所述信息处理请求对应的资源提供方的账户，所述第二账户为所述资源提供方对应的平台账户；

调用单元，被配置为调用支付渠道的资源退还接口，向所述目标出资账户发起资源退还操作。

15.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至13中任一项所述的消息处理方法。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行，以使计算机实现如权利要求1至13中任一项所述的消息处理方法。

17.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序或计算机指令，所述计算机程序或计算机指令由处理器加载并执行，以使计算机实现如权利要求1至13中任一项所述的消息处理方法。