CN106033304A - 数据交互方法及装置 - Google Patents

Abstract

本申请提供一种数据交互方法及装置，该方法包括：检测到数据交互需求；确定支持所述数据交互需求的所有预设交互对象；获取每一预设交互对象对所述数据交互需求的实时处理能力信息；将每一预设交互对象与相应的实时处理能力信息进行关联展示。通过本申请的技术方案，可以对每一交互对象的实时交互能力进行展示，便于用户查看并选择恰当的交互对象，有助于缩短交互时长、提升交互效率。

Description

数据交互方法及装置

技术领域

本申请涉及数据交互技术领域，尤其涉及数据交互方法及装置。

背景技术

在诸多应用场景下，终端均需要与对应的功能平台实现数据交互。功能平台的处理能力往往十分强大，可以同时处理大量终端发起的数据交互需求；然而，当终端数量巨大、数据交互需求剧增时，功能平台也可能出现处理瓶颈，造成数据交互的体验迟滞、不流畅。

发明内容

有鉴于此，本申请提供一种数据交互方法及装置，以解决相关技术中的不足。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种数据交互方法，包括：

检测到数据交互需求；

确定支持所述数据交互需求的所有预设交互对象；

获取每一预设交互对象对所述数据交互需求的实时处理能力信息；

将每一预设交互对象与相应的实时处理能力信息进行关联展示。

根据本申请的第二方面，提出了一种数据交互装置，包括：

检测单元，检测到数据交互需求；

确定单元，确定支持所述数据交互需求的所有预设交互对象；

获取单元，获取每一预设交互对象对所述数据交互需求的实时处理能力信息；

展示单元，将每一预设交互对象与相应的实时处理能力信息进行关联展示。

由以上技术方案可见，本申请通过获取每一预设交互对象的实时处理能力信息，实际上是了解到每一预设交互对象在处理当前检测到的数据交互需求时的预估处理效果，比如流畅、延迟、无法处理等，从而通过展示每一预设交互对象的实时处理能力信息，便于用户选取恰当的预设交互对象，顺利实现对数据交互需求的处理，有助于提升用户体验。

附图说明

图1是根据本申请一示例性实施例提供的一种数据交互方法的流程图；

图2是根据本申请一示例性实施例提供的另一种数据交互方法的流程图；

图3是根据本申请一示例性实施例提供的数据交互的应用场景示意图；

图4-8是根据本申请一示例性实施例提供的终端界面示意图；

图9是根据本申请一示例性实施例提供的一种电子设备的结构示意图；

图10是根据本申请一示例性实施例提供的一种数据交互装置的框图。

具体实施方式

图1是根据本申请一示例性实施例提供的一种数据交互方法的流程图，如图1所示，该方法应用于终端，可以包括以下步骤：

步骤102，检测到数据交互需求。

在本实施例中，当数据交互需求同时涉及多个可用的预设交互对象时，相应的场景均可以应用本申请的技术方案，本申请对此并不进行限制。比如作为一示例性实施例，数据交互需求可以为支付需求，则相应的预设交互对象为多个支付渠道，比如银行系统或支付平台等。

步骤104，确定支持所述数据交互需求的所有预设交互对象。

在本实施例中，基于当前发出数据交互需求的应用程序、网页或应用功能，即可查找到对应的预设交互对象；比如当电子支付应用程序发出支付需求时，相应的预设交互对象可能包括：支付平台的余额管理平台以及各银行等。

步骤106，获取每一预设交互对象对所述数据交互需求的实时处理能力信息。

在本实施例中，实时处理能力信息是指相应的预设交互对象在实时(即当前时刻)处理数据交互需求时的能力；其中，当能力越强时，表明对数据交互需求的处理过程越顺利(比如延迟更小、出错概率更低)。换言之，实时处理能力信息可以认为是基于相应的预设交互对象在当前或某个历史时间段内的表现，预估其对当前存在的数据交互需求进行处理时可能的状况，比如流畅、延迟、无法处理等。

在本实施例中，作为一示例性实施例，可以获取每一预设交互对象的预设能力参数的实时数值，并根据所述实时数值所属的预设数值范围，将该预设数值范围对应的能力等级作为所述实时处理能力信息。其中，任一预设交互对象的所述预设能力参数包括以下至少之一：

单位时间内增加的数据交互需求数量、向所述任一预设交互对象的请求发起数量与响应接收数量之比、每一数据交互需求的平均处理时长、剩余的未处理数据交互需求数量。

步骤108，将每一预设交互对象与相应的实时处理能力信息进行关联展示。

在本实施例中，“关联展示”可以理解为：当多个预设交互对象同时显示在终端页面上时，用户在视觉上能够明确区分出每一预设交互对象对应的实时处理能力信息。举例而言，可以将实时处理能力信息显示于相应的预设交互对象的关联展示区域内，比如当多个预设交互对象显示为一列时，实时处理能力信息可以与相应的预设交互对象显示于同一行。

在本实施例中，在已经展示出实时处理能力信息的情况下，针对检测到的用户对预设交互对象的选择命令，可以执行下述处理：

作为一示例性实施方式，可以根据接收到的第一用户选择命令，确定被选中的预设交互对象；若根据所述实时处理能力信息，判定所述被选中的预设交互对象的实时处理能力低于预设处理能力，则展示预设警告信息和操作选项；以及，根据接收到的针对所述操作选项的第二用户选择命令，取消对所述被选中的预设交互对象的选择，或者向所述被选中的预设交互对象发起所述数据交互需求。

作为另一示例性实施方式，若根据所述实时处理能力信息，判定所述任一预设交互对象的实时处理能力低于预设处理能力，则可以停止接收向所述任一预设交互对象发起的数据交互需求。

由上述实施例可知，本申请通过获取每一预设交互对象的实时处理能力信息，实际上是了解到每一预设交互对象在处理当前检测到的数据交互需求时的预估处理效果，比如流畅、延迟、无法处理等，从而通过展示每一预设交互对象的实时处理能力信息，便于用户选取恰当的预设交互对象，顺利实现对数据交互需求的处理，有助于提升用户体验。

如上文所述，本申请的技术方案可以应用于任意类型的数据交互需求的处理过程中；下面以数据交互需求为“支付需求”为例，具体说明本申请的技术方案如何通过对支付渠道的监控，实现对支付需求的处理过程。其中，图2是根据本申请一示例性实施例提供的另一种数据交互方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤202，监控渠道的能力参数。

在本实施例中，以图3所示的应用场景示意图为例，对监控渠道能力的过程进行描述。如图3所示，假定用户通过手机APP进行购物的过程中，触发了支付需求，则该手机APP将支付需求发送至相应的服务器，并从服务器处获取每一预设支付渠道的预设能力参数的实时数值(以用于进一步确定每一支付渠道对支付需求的实时处理能力信息，即实时支付能力信息)。比如图3所示，支付渠道包括A银行、B银行、C平台和D平台等；其中，支付渠道是与相应的APP关联预设的，即每个APP对应的支付渠道可能存在差异。

举例而言，预设能力参数可以包括以下至少之一：单位时间内增加的支付需求数量、向所述任一预设支付渠道的请求发起数量与响应接收数量之比、每一支付需求的平均处理时长、剩余的未处理支付需求数量。

其中，“单位时间内增加的支付需求数量”体现了支付需求的增长情况。比如某一支付渠道的处理能力为m件/单位时间，则当单位时间内增加的支付需求数量n＞m时，即便原本不存在排队等待处理的支付需求，但新增的支付需求也将导致该支付渠道无法顺利处理掉所有增加的支付需求，造成支付需求的堆积(即排队等待处理)，也就说明该支付渠道的实时支付处理能力可能较弱。

“向所述任一预设支付渠道的请求发起数量与响应接收数量之比”：在正常情况下，针对每个支付需求，由服务器向支付渠道发起一次支付请求并接收一次相应的响应消息，即请求发起数量等于响应接收数量；而当支付渠道异常时，将导致服务器向支付渠道发起的支付请求无法被正常响应，从而使得请求发起数量远大于响应接收数量。因此，当请求发起数量大于响应接收数量时，或者当请求发起数量超出响应接收数量较多时，说明该支付渠道的实时支付处理能力可能较弱。

“每一支付需求的平均处理时长”：当支付需求过多而造成排队等待处理时，或者支付渠道异常而导致无法正常处理支付需求时，将导致每一支付需求的平均处理时长增加，即用户需求等待更长时间，则说明相应的支付渠道的实时支付处理能力可能较弱。

“剩余的未处理支付需求数量”：当支付需求数量小于或等于支付渠道的可处理数量时，所有支付需求均会被及时处理，不会存在剩余的未处理支付需求；而当支付需求数量增加至大于支付渠道的可处理数量，或者支付渠道异常时，均可能导致支付需求剩余，且当剩余的支付需求数量越多时，说明当前的支付需求可能需要更长的处理时间。

在本实施例中，服务器在监控得到每一支付渠道的预设能力参数后，可以将该预设能力参数发送至手机侧，并由手机侧处理得到相应的实时支付能力信息；或者，可以由服务器直接将预设能力参数处理为对应的实时支付能力信息，并发送至手机侧。其中，下述的步骤204将具体描述预设能力参数与实时支付能力信息之间的关系。

在本实施例中，作为一示例性实施方式，服务器可以周期性地监控每一支付渠道的预设能力参数，则当服务器接收到来自手机侧的支付需求时，可以将最近一次监控到的预设能力参数或相应的实时支付能力信息反馈给手机侧。或者，作为另一示例性实施方式，服务器也可以在接收到来自手机侧的支付需求时，触发一次对支付渠道的预设能力参数的监控，并将得到的预设能力参数或实时支付能力信息反馈至手机侧。

以用户在手机上购买“特价电影券”为例。当手机生成或跳转至图4所示的订单支付页面时，即可生成支付需求并发送至服务器，以获取相应的每一支付渠道的预设能力参数或实时支付能力信息。

步骤204，判定渠道能力。

在本实施例中，基于每一支付渠道的预设能力参数的实时数值，可以根据所述实时数值所属的预设数值范围，将该预设数值范围对应的能力等级作为实时支付能力信息。

以预设能力参数为“剩余的未处理支付需求数量”为例，假定图3所示的支付渠道“A银行”对应的实时数值如表1所示。

支付渠道	流畅	延迟	不可处理	平均处理数量
					A银行	0～1500次	1500～3000次	>3000次	300次/秒
B银行	0～1750次	1750～3500次	>3500次	350次/秒
					C平台	0～2500次	2500～5000次	>5000次	500次/秒
D平台	0～1400次	1400～2800次	>2800次	280次/秒

表1

由表1可知：对于A银行，由于A银行对支付需求的处理能力为300次/秒，因而当剩余的未处理支付需求数量为0～1500次时，说明A银行对当前产生的支付需求的处理时间为0～5秒，即无需等待或仅需要短时间等待，对应的实时支付能力信息为“流畅”；当剩余的未处理支付需求数量为1500～3000次时，A银行所需要的处理时间为5～10秒，即当前产生的支付需求需要较长时间等待，对应的实时支付能力信息为“延迟”；当当剩余的未处理支付需求数量为3000次以上时，A银行所需要的处理时间大于10秒，即当前产生的支付需求需要很长时间等待，对应的实时支付能力信息为“无法处理”。对于其他支付渠道，与A银行类似，此处不再赘述。

步骤206，展示渠道能力。

如图4所示，以用户在手机上对“特价电影券”进行支付为例，则手机支付页面上示出了A银行、B银行、C平台和D平台等支付渠道，且每一支付渠道的右侧标注了对应的实时支付能力信息，比如A银行和D平台对应于“空闲”(支付渠道处于“空闲”时，相当于对支付需求的处理过程为“流畅”)、B银行对应于“拥堵”(支付渠道处于“拥堵”时，相当于对支付需求的处理过程为“不可处理”)、C平台对应于“繁忙”(支付渠道处于“繁忙”时，相当于对支付需求的处理过程为“延迟”)。

除了采用“空闲”、“繁忙”和“拥堵”等文字，还可以采用图案等其他类型的标识，或者多种标识的组合。如图5所示，可以同时通过文字和图案来标示出每一支付渠道对应的实时支付能力信息，比如“空闲”和“笑脸”图案，或者“拥堵”和“哭脸”图案。当然，本申请并不对实时支付能力信息的标示形式进行限制。

此外，当预设交互对象的实时处理能力信息不同时，针对用户操作而导致的处理方式也存在差异。下面以图5所示的支付页面为例，进行具体说明。

如图6(a)所示，当用户点击D平台右侧的圆形控件时，即发出了对D平台的选择操作。由于D平台的实时支付能力信息为“空闲”，即能够流畅地处理当前产生的支付需求，则如图6(b)所示，用户能够顺利完成对D平台的选择操作，以及后续的付款操作。

如图7(a)所示，当用户点击B银行右侧的圆形控件时，即发出了对B银行的第一用户选择命令。由于B银行的实时支付能力信息为“拥堵”，即无法正常处理当前产生的支付需求，需要用户长时间等待，则如图7(b)所示，可以展示预设警告信息“您当前选取的支付渠道十分拥堵，可能造成长时间等待或支付失败，推荐您选择其他支付渠道！”，以及操作选项“继续”和“返回”；根据接收到的针对操作选项的第二用户选择命令，若用户选择“继续”，则向B银行发起支付需求，若用户选择“返回”，则取消对B银行的选择。

当然，若根据实时支付能力信息，判定任一预设支付渠道的实时支付能力低于预设支付能力(比如预设支付能力为“繁忙”)，比如实时支付能力为“拥堵”的B银行，那么为了避免当前用户的支付体验受到影响，也避免对其他已经选用了B银行的用户造成影响，可以停止接收向该任一预设支付渠道发起的支付需求。比如图8所示，停止向用户提供对B银行的选项按钮；而用户可以通过点击“为什么不可用”，查看相应的原因和理由，避免用户不理解而造成的支付体验降低。

图9示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图9，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成数据交互装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图10，在软件实施方式中，该数据交互装置可以包括检测单元、确定单元、获取单元和展示单元。其中：

检测单元，检测到数据交互需求；

确定单元，确定支持所述数据交互需求的所有预设交互对象；

获取单元，获取每一预设交互对象对所述数据交互需求的实时处理能力信息；

展示单元，将每一预设交互对象与相应的实时处理能力信息进行关联展示。

可选的，所述获取单元具体用于：

获取每一预设交互对象的预设能力参数的实时数值；

根据所述实时数值所属的预设数值范围，将该预设数值范围对应的能力等级作为所述实时处理能力信息。

可选的，任一预设交互对象的所述预设能力参数包括以下至少之一：

单位时间内增加的数据交互需求数量、向所述任一预设交互对象的请求发起数量与响应接收数量之比、每一数据交互需求的平均处理时长、剩余的未处理数据交互需求数量。

可选的，还包括：

对象选择单元，根据接收到的第一用户选择命令，确定被选中的预设交互对象；

警告单元，若根据所述实时处理能力信息，判定所述被选中的预设交互对象的实时处理能力低于预设处理能力，则展示预设警告信息和操作选项；以及

选择处理单元，根据接收到的针对所述操作选项的第二用户选择命令，取消对所述被选中的预设交互对象的选择，或者向所述被选中的预设交互对象发起所述数据交互需求。

可选的，还包括：

请求管理单元，若根据所述实时处理能力信息，判定所述任一预设交互对象的实时处理能力低于预设处理能力，则停止接收向所述任一预设交互对象发起的数据交互需求。

可选的，所述数据交互需求为支付需求，所述预设交互对象为支付渠道。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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

Claims (12)

1.一种数据交互方法，其特征在于，包括：

检测到数据交互需求；

确定支持所述数据交互需求的所有预设交互对象；

获取每一预设交互对象对所述数据交互需求的实时处理能力信息；

将每一预设交互对象与相应的实时处理能力信息进行关联展示。

2.根据权利要求1所述的方法，其特征在于，所述获取每一预设交互对象对所述数据交互需求的实时处理能力信息，包括：

获取每一预设交互对象的预设能力参数的实时数值；

根据所述实时数值所属的预设数值范围，将该预设数值范围对应的能力等级作为所述实时处理能力信息。

3.根据权利要求2所述的方法，其特征在于，任一预设交互对象的所述预设能力参数包括以下至少之一：

单位时间内增加的数据交互需求数量、向所述任一预设交互对象的请求发起数量与响应接收数量之比、每一数据交互需求的平均处理时长、剩余的未处理数据交互需求数量。

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

根据接收到的第一用户选择命令，确定被选中的预设交互对象；

若根据所述实时处理能力信息，判定所述被选中的预设交互对象的实时处理能力低于预设处理能力，则展示预设警告信息和操作选项；以及

根据接收到的针对所述操作选项的第二用户选择命令，取消对所述被选中的预设交互对象的选择，或者向所述被选中的预设交互对象发起所述数据交互需求。

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

若根据所述实时处理能力信息，判定所述任一预设交互对象的实时处理能力低于预设处理能力，则停止接收向所述任一预设交互对象发起的数据交互需求。

6.根据权利要求1所述的方法，其特征在于，所述数据交互需求为支付需求，所述预设交互对象为支付渠道。

7.一种数据交互装置，其特征在于，包括：

检测单元，检测到数据交互需求；

确定单元，确定支持所述数据交互需求的所有预设交互对象；

获取单元，获取每一预设交互对象对所述数据交互需求的实时处理能力信息；

展示单元，将每一预设交互对象与相应的实时处理能力信息进行关联展示。

8.根据权利要求7所述的装置，其特征在于，所述获取单元具体用于：

获取每一预设交互对象的预设能力参数的实时数值；

根据所述实时数值所属的预设数值范围，将该预设数值范围对应的能力等级作为所述实时处理能力信息。

9.根据权利要求8所述的装置，其特征在于，任一预设交互对象的所述预设能力参数包括以下至少之一：

单位时间内增加的数据交互需求数量、向所述任一预设交互对象的请求发起数量与响应接收数量之比、每一数据交互需求的平均处理时长、剩余的未处理数据交互需求数量。

10.根据权利要求7所述的装置，其特征在于，还包括：

对象选择单元，根据接收到的第一用户选择命令，确定被选中的预设交互对象；

警告单元，若根据所述实时处理能力信息，判定所述被选中的预设交互对象的实时处理能力低于预设处理能力，则展示预设警告信息和操作选项；以及

选择处理单元，根据接收到的针对所述操作选项的第二用户选择命令，取消对所述被选中的预设交互对象的选择，或者向所述被选中的预设交互对象发起所述数据交互需求。

11.根据权利要求7所述的装置，其特征在于，还包括：

请求管理单元，若根据所述实时处理能力信息，判定所述任一预设交互对象的实时处理能力低于预设处理能力，则停止接收向所述任一预设交互对象发起的数据交互需求。

12.根据权利要求7所述的装置，其特征在于，所述数据交互需求为支付需求，所述预设交互对象为支付渠道。