CN111176866A

CN111176866A - 数据交互方法和电子设备

Info

Publication number: CN111176866A
Application number: CN202010009122.2A
Authority: CN
Inventors: 陈杰
Original assignee: Admaster Technology Beijing Co ltd
Current assignee: Beijing second hand Artificial Intelligence Technology Co.,Ltd.
Priority date: 2020-01-03
Filing date: 2020-01-03
Publication date: 2020-05-19

Abstract

本申请实施例提供一种数据交互方法和电子设备，该方法可包括：在当前网络为通畅状态时，向目标设备上的服务端发送交互请求；判断该目标设备上的服务端对于该交互请求是否正确响应；在该目标设备上的服务端对于该交互请求未正确响应时，根据该交互请求向该目标设备上的服务端发起轮询请求；在轮询失败次数达到预设次数时，根据该交互请求的类型存储该交互请求或将该交互请求对应的服务关闭。以此有利于改善现有技术中难以得知数据请求响应失败原因的问题。

Description

数据交互方法和电子设备

技术领域

本申请涉及通讯技术领域，具体而言，涉及一种数据交互方法和电子设备。

背景技术

随着科技的发展和时代的需要，网络中实时数据的交互变得越来越频繁。然而在实际网络交互场景中，常常会出现一方发起了数据请求，但等不到数据返回的现象，这给实时性数据交互造成了不可估量的损失。

现有技术的一种做法是：在请求超时或请求失败时提示相关错误码,让调用方得知当前请求响应详情，但这种做法仅能告知调用方最终的调用结果，实际上用户需要耗费大量的精力去寻找故障原因，在此期间还会因大量请求失败的情况引起更多数据问题。

发明内容

本申请实施例的目的在于提供一种数据交互方法和电子设备，用以改善现有技术中难以得知数据请求响应失败原因的问题。

第一方面，本申请实施例提供一种数据交互方法，应用于第一终端，所述方法包括：

在当前网络为通畅状态时，向目标设备上的服务端发送交互请求；

判断所述目标设备上的服务端对于所述交互请求是否正确响应；

在所述目标设备上的服务端对于所述交互请求未正确响应时，根据所述交互请求向所述目标设备上的服务端发起轮询请求；

在轮询失败次数达到预设次数时，根据所述交互请求的类型存储所述交互请求或将所述交互请求对应的服务关闭。

通过上述方法，可以降低因带宽或其他网络问题带来的外部因素对请求的响应影响，还可以通过交互请求侦测服务端的运行情况是否正常，有利于后续故障排除，还可以在轮询失败次数过多时降低因服务端问题造成的应用端损失。以此不仅可以降低交互请求响应失败的概率，还可以在交互请求未能正确响应且轮询失败次数过多时，避免因服务端的问题造成应用端的请求数据丢失或引起更严重的服务雪崩效应。

在可选的实施方式中，所述方法还包括：

在轮询失败次数达到预设次数时，根据所述交互请求的类型向预设的用户终端发送预警提示消息；

或，在当前网络未处于通畅状态时，向预设的用户终端发送预警提示消息。

通过上述实施方式，可以针对不同的情况分别向预设的用户终端发送对应的预警提示消息，有利于故障排查，有利于缩短应用端的等待时间。

在可选的实施方式中，在所述向目标设备上的服务端发送交互请求之前，所述方法还包括：

按照预设时间间隔，定时向所述目标设备的网络地址发送测试数据；

根据所述目标设备对于所述测试数据的响应情况确定当前网络状态。

通过上述实施方式，有利于对部署有服务端的目标设备当前的网络状态进行监测，从而及时得知服务端的当前网络状态，尽可能避免因服务端的部署设备网络问题造成更多的请求响应失败现象。

在可选的实施方式中，所述按照预设时间间隔，定时向目标设备的网络地址发送测试数据，包括：

按照预设时间间隔，定时通过因特网包探索器向所述目标设备的网络地址发送指定字节的测试数据包；

所述根据所述目标设备对于所述测试数据的响应情况确定当前网络状态，包括：

在接收到所述目标设备根据所述测试数据包返回的响应数据包时，判断所述响应数据包的字节数是否与所述测试数据包的字节数相同；

在所述响应数据包的字节数与所述测试数据包的字节数相同时，确定当前网络为通畅状态。

通过上述实施方式，可以快速得知服务端的部署设备当前的网络情况。

在可选的实施方式中，所述交互请求包括业务请求，所述在轮询失败次数达到预设次数时，根据所述交互请求的类型存储所述交互请求或将所述交互请求对应的服务关闭，包括：

在轮询失败次数达到预设次数时，将所述业务请求存储在消息队列中。

通过上述实施方式，可以避免因服务端问题造成应用端的业务请求数据丢失。

在可选的实施方式中，所述方法还包括：

响应对于所述业务请求的恢复操作，将存储在所述消息队列中的业务请求重新发送给所述目标设备。

通过上述实施方式，可以快速将原本中断的业务请求重新发送给目标设备，尽快让服务端继续处理原本终端的业务。

在可选的实施方式中，所述交互请求包括约定请求，所述在当前网络为通畅状态时，向目标设备上的服务端发送交互请求，包括：

在当前网络为通畅状态时，获取闲置时长，所述闲置时长表示从上一次向所述目标设备发送数据时至当前时刻的时间长度；

判断所述闲置时长是否达到第一时间阈值；

在所述闲置时长达到第一时间阈值时，向所述目标设备上的服务端发送所述约定请求。

通过上述实施方式，有利于根据约定请求检测目标设备上部署的服务端的服务是否可用，及时得知服务端的服务运行状况。

在可选的实施方式中，所述判断所述目标设备上的服务端对于所述交互请求是否正确响应，包括：

判断所述目标设备上的服务端是否在指定时间段内根据所述约定请求返回约定数据；

当所述目标设备上的服务端在指定时间段内根据所述约定请求返回约定数据时，确定所述目标设备上的服务端对于所述约定请求正确响应，以此确定所述目标设备上的服务端处于服务可用状态。

通过上述实施方式，能够及时得知服务端的服务运行状况。

在可选的实施方式中，所述在轮询失败次数达到预设次数时，根据所述交互请求的类型存储所述交互请求或将所述交互请求对应的服务关闭，包括：

在轮询失败次数达到预设次数时，根据所述约定请求将所述第一终端的指定服务关闭，所述指定服务为与所述约定请求对应的服务。

通过上述实施方式，有利于避免因服务端的问题引起应用端的服务雪崩效应。

第二方面，本申请实施还提供一种数据交互装置，包括：

交互模块，用于在当前网络为通畅状态时，向目标设备上的服务端发送交互请求；

判断模块，用于判断所述目标设备上的服务端对于所述交互请求是否正确响应；

轮询模块，用于在所述目标设备上的服务端对于所述交互请求未正确响应时，根据所述交互请求向所述目标设备上的服务端发起轮询请求；

执行模块，用于在轮询失败次数达到预设次数时，根据所述交互请求的类型存储所述交互请求或将所述交互请求对应的服务关闭。

通过上述装置可以执行前述第一方面提供的方法，不仅可以降低交互请求响应失败的概率，还可以在交互请求未能正确响应且轮询失败次数过多时，避免因服务端的问题造成应用端的请求数据丢失或引起更严重的服务雪崩效应。

第三方面，本申请实施例提供一种电子设备，所述电子设备包括：

存储器；

处理器；

所述存储器存储有所述处理器可执行的计算机程序，所述计算机程序被所述处理器执行时执行前述的第一方面提供的方法。

第四方面，本申请实施例还提供一种存储介质，该存储介质上存储有计算机程序，所述计算机程序被处理器执行时执行前述的第一方面提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种应用端与服务端之间的交互示意图。

图2为本申请实施例提供的一种电子设备的结构框图。

图3为本申请实施例提供的一种数据交互方法的流程图。

图4为本申请实施例提供的一种数据交互装置的功能模块框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

通常情况下，在实际网络交互过程中会因为各种未知原因而造成交互失败，例如可能会因为请求参数的格式错误、网络带宽问题、虚拟专用网络(VPN)的限制等问题而造成数据请求没有得到正常响应，也有可能出现由于服务端宕机等问题而造成数据请求没有得到正常响应。

考虑到对于应用端而言，因服务端一侧的原因而造成数据请求的响应失败是不可控的，且由服务端一侧的原因造成的响应失败所带来的损失是巨大的，发明人提出了一种针对服务端对请求数据响应不可控的解决方案。以此可以在出现响应失败时提供分析参考依据，从而帮助相关人员进行故障排查，尽可能降低因服务端一侧的问题而造成应用端的服务不可用所带来的损失。

请参阅图1，图1为本申请实施例提供的一种应用端100与服务端200之间的交互示意图。

如图1所示，应用端100与服务端200通过网络进行数据交互。应用端100可以是发起数据请求的一方，应用端100可以部署在第一终端上，同一个第一终端上可以有至少一个应用端100。服务端200是根据应用端100的数据请求进行响应的一方，服务端200可以部署在目标设备上。

在一个应用场景下，多个应用端100可以与同一个服务端200进行数据交互。例如，对于10个用于扫码支付的应用端100而言，10个应用端100都可以与同一个提供支付业务服务(例如支付宝等交易类服务)的服务端200进行数据交互。

在另一个应用场景下，同一个应用端100可以与多个服务端200进行数据交互。例如，对于一个用于即时通讯的应用端100而言，可以与用于提供聊天服务、邮件服务、游戏服务等服务的服务端200进行数据交互。

请参阅图2，图2为本申请实施例提供的一种电子设备300的结构框图。该电子设备300可以是部署有应用端100的第一终端。

如图2所示，该电子设备300包括：存储器301、处理器302、网络单元303。存储器301、处理器302、网络单元303等组件之间通过一条或多条通信总线/信号线进行通讯。

存储器301是一种存储介质，可以用来存储计算机程序，例如，可用于存储本申请实施例提供的数据交互方法对应的计算机程序。处理器302具有运算处理能力，处理器302可以通过运行存储器301中存储的计算机程序，从而实现本申请实施例提供的数据交互方法。

存储器301可以是但不限于：随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-Only Memory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

处理器302可以是但不限于：中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等通用处理器，还可以是数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立组件搭建的专用处理器。

电子设备300可以通过网络单元303实现与外部设备的网络连接。

可以理解的是，图2所示的结构仅作为示意，具体应用时，电子设备300还可以具有比图2所示更多的组件，或具有与图2所不同的配置。在本申请实施例中，电子设备300可以是个人计算机、服务器、移动设备、穿戴设备、车载设备等能够连接网络并具有运算处理能力的设备。

请参阅图3，图3为本申请实施例提供的一种数据交互方法的流程图。该数据交互方法可应用于应用端100，其中，本申请实施例中所有应用于应用端100的内容实质上也可以应用于部署有应用端100的第一终端，由第一终端实现。

如图3所示，该方法包括步骤S11-S14。

S11：在当前网络为通畅状态时，向目标设备上的服务端发送交互请求。

其中，目标设备上部署有服务端。第一终端在向目标设备发送交互请求之前可以进行网络检测，在进行网络检测时可以通过第一终端上的应用端程序实现。在检测确定出当前网络为通畅状态时，第一终端的应用端向该目标设备上部署的服务端发送交互请求，并等待服务端根据该交互请求返回响应内容。

交互请求可以是用于检测该目标设备上部署的服务端是否处于可用状态的约定请求，也可以是根据实际业务需求而向该服务端发起的业务请求。

S12：判断该目标设备上的服务端对于该交互请求是否正确响应。

其中，目标设备对于该交互请求的响应通过服务端实现，应用端可以结合服务端根据交互请求返回数据的时间、返回的具体内容，从而判断该目标设备对于交互请求是否正确响应。

S13：在该目标设备上的服务端对于该交互请求未正确响应时，根据该交互请求向该目标设备上的服务端发起轮询请求。

其中，正确响应是指目标设备上的服务端在规定的时间内返回了应用端所需的数据。在判定出该目标设备上的服务端对于交互请求没有进行正确响应的情况下，根据交互请求向该目标设备发起轮询请求，从而尝试重新进行数据请求。轮询请求的内容根据交互请求的内容确定。

其中，本领域技术人员可以任意配置轮询请求的频次和轮询的时间间隔。

S14：在轮询失败次数达到预设次数时，根据该交互请求的类型存储该交互请求或将该交互请求对应的服务关闭。

其中，本领域技术人员可以根据实际需要任意设定预设次数，预设次数可以是3次、5次、7次等。需要存储的交互请求可以存储在第一终端的消息队列(Message Queue，MQ)中。

在轮询失败次数达到预设次数时，确定本次交互请求失败，此时第一终端根据交互请求的具体类型对该应用端发起的交互请求进行处理或将交互请求所对应的服务进行处理，从而避免出现后续的更多未知损失。

在一个实例中，应用端A1与服务端B1之间可以进行支付数据交互。当应用端A1确定出当前网络为通畅状态时，部署有应用端A1的第一终端在扫描付款标识后向该服务端B1发起了付款请求，该付款请求作为交互请求中的业务请求。若服务端B2在指定时间段内同意该付款请求并返回扣款成功标识时，表示此次付款请求得到正确响应。而若服务端B2未在指定时间段内同意该付款请求，则根据该付款请求发起轮询请求，此时的轮询请求内容可以与该付款请求的内容相同。在轮询请求的失败次数达到2次时，确定应用端此次的付款请求未得到成功响应，可以将失败的付款请求存储在消息队列中，以便后续数据统计分析或重新根据该失败的付款请求再次发起请求。可以理解的是，消息队列中还可以存储更多类型的响应失败的业务请求。

在另一个实例中，应用端A2向服务端B2发起了数据迁移请求，该数据迁移请求作为交互请求，用以对***业务数据进行迁移、备份或合并。在服务端B2未在指定时间段内对该数据迁移请求进行正确响应时，应用端A2向该服务端B2发起轮询请求，若在轮询过程中，该服务端B2对轮询请求进行响应，则可以认为此次数据迁移请求有效，***业务数据可以进行迁移。

再一个实例中，在应用端A3与服务端B3长时间未进行通讯的情况下，为了确认此时的服务端B3提供的一种服务Y(例如聊天功能、邮件功能、音乐功能、游戏功能等功能对应的服务)还具有活性，应用端A3向该服务端B3发送了约定请求，该约定请求作为交互请求。若服务端A3对于该约定请求进行正确响应，则表明该服务端B3提供的服务目前是可用的。而若该服务端B3对于该约定请求未进行正确响应，则应用端A3根据该约定请求向服务端A3进行轮询，在轮询失败次数达到4次时，若该服务端B3仍然未能进行响应，则应用端A3可以将该约定请求对应的服务Y在应用端A3进行关闭，从而避免因为服务端B3一侧的问题而造成应用端A3出现服务雪崩效应。“服务雪崩效应”是一种因“服务提供者的不可用”(原因)导致“服务调用者不可用”(结果)，并将“不可用”情况逐渐放大的现象。

通过上述方法，第一终端在当前网络为通畅状态的情况下向目标设备发送交互请求，实质上是应用端在当前网络为通畅状态的情况下向服务端发送交互请求，在交互请求未得到服务端一侧的正确响应时，根据具体的交互请求向服务端发起轮询请求，并在轮询失败次数过多时根据交互请求的类型对交互请求进行存储或将交互请求对应的服务关闭。由于交互请求是在当前网络为通畅的状态下发送的，可以排除因带宽或其他网络问题带来的外部因素对请求的响应影响，有利于后续及时补救。且，通过在网络通畅的情况下对交互请求的响应情况进行判别，可以侦测到服务端的运行情况是否正常，有利于后续故障排除。且在根据交互请求所进行的轮询失败次数过多的情况下，对交互请求进行存储可以避免请求数据的丢失，在一些特定业务场景(例如支付类业务)下有利于数据核对，降低“坏账”的发生率。通过在轮询失败次数过多的情况下对交互请求对应的服务进行关闭，能够避免产生更严重的服务雪崩效应。以此可以从多方面降低因服务端问题造成的应用端损失，降低请求响应失败所带来的影响。

可选地，在轮询失败次数达到预设次数时，上述数据交互方法还可以包括：根据该交互请求的类型向预设的用户终端发送预警提示消息；或，在当前网络未处于通畅状态时，向预设的用户终端发送预警提示消息。

其中，发送预警提示消息的渠道包括但不限于邮件通知、短信通知、即时通信工具的消息推送等。

作为一种实现方式，可以在轮询失败次数达到预设次数时，判断当前的轮询请求对应的交互请求是否为业务请求。

若交互请求为业务请求，则可以确定服务端的部分业务处理出现故障，此时可以根据实际的业务请求获取预先配置的相关业务责任人的联系账号，并向这些联系账号对应的用户终端发送业务预警提示消息，以便于用户根据业务预警提示消息进行故障排查和处理。其中，应用端遇到业务性请求失败，由服务端问题导致业务请求响应失败的原因包括但不限于：服务端的代码问题、服务端对部分事务处理失败、服务端的任务超负荷等。

若交互请求不是业务请求，例如识别出该轮询请求对应的交互请求是用于测试服务端的服务是否可用的约定请求，则可以根据轮询情况确定该服务端出现运行异常。此时可以获取预先设置的联系账号(可以是运维人员、管理员的账号)，并向这些联系账号对应的用户终端发送服务预警提示消息，以便于用户根据服务预警提示消息进行后续处理。

作为另一种实现方式，在确定出当前网络未处于通畅状态时，应用端可以获取预先配置的网络维护人员的联系账号，并向这些联系账号对应的用户终端发送网络预警提示消息。

通过上述实施方式，对于可能造成响应失败的多种影响因素，针对不同的影响因素，在不同的情况下分别向对应的用户终端发送预警提示消息，有利于根据用户及时进行故障处理，有利于缩短应用端的等待时间。

可选地，在向目标设备发送交互请求之前，还包括网络测试阶段，数据交互方法还可以包括S101-S102。

S101：按照预设时间间隔，定时向该目标设备的网络地址发送测试数据。

本领域技术人员可以根据实际需要设置预设时间间隔，从而设置发送测试数据的时间点，例如预设时间间隔可以是0.5秒、1秒、2秒等。

S102：根据该目标设备对于该测试数据的响应情况确定当前网络状态。

其中，S101-S102是通过应用端程序定期向目标设备的网络地址发送测试数据从而确定当前网络状态的。相较于手动配置测试数据或临时调用测试脚本的方式，通过应用端程序可以监测服务端的网络通畅性，而不是在出现网络故障以后再去寻找异常原因，能够在服务端的网络出现故障时尽快(相较于临时手动查询或临时调用测试脚本的方式)获知服务端的网络出现异常，从而有利于应用端及时在服务端出现网络异常时关停一些与该服务端有关的服务。

作为一种实现方式，上述S101可以包括：按照预设时间间隔，定时通过因特网包探索器(Packet Internet Groper，ping)向该目标设备的网络地址发送指定字节的测试数据包。相应的，上述S102可以包括：在接收到该目标设备根据该测试数据包返回的响应数据包时，判断该响应数据包的字节数是否与该测试数据包的字节数相同；在该响应数据包的字节数与该测试数据包的字节数相同时，确定当前网络为通畅状态。

在一个实例中，应用端可以采取定时对目标设备(服务端所在的设备)的网络地址进行ping的方式，以向目标设备的网络地址发送32字节的测试数据包，并等待该目标设备返回一个32字节的数据包(无需了解该数据包的具体内容)。

若该目标设备未返回数据包或返回的数据包的字节不是32字节，则判定该目标设备当前的网络异常，即该目标设备当前未处于网络通畅状态，此时不适合向该目标设备上部署的服务端发送交互请求，及时停止向该服务端的交互请求访问，避免出现更多的数据问题。在具体实现时，可以通过声明处理类中的对象，在进行巡检(ping)后，将流的输入实例化，并转化成对应的字节流，然后读取该字节流文本，从而判断ping是否成功。实际上是通过应用端程序向服务端所在的目标设备的网络地址发送32字节数据，并在检测到服务端所在的目标设备返回的32字节数据回复内容时，确定该服务端当前处于网络通畅状态。

其中，ping是一种用于检测网络连通情况、分析网络速度的技术。通常情况下的ping操作是通过人为输入一些指令并进入磁盘操作***(DOS)环境，在DOS环境下通过输入的ping命令进行网络检测(用于本地设备的网络测试)，而本申请实施例中是通过应用端程序自动地定时采用ping的技术对服务端的网络进行监测，无需额外在应用端所在的第一终端上手动进行配置以实现ping，有利于及时得知服务端的网络情况。

其中，在多次进行Ping却仍然失败的情况下，可以获取预设的用户终端信息，向预设的用户终端发送预警提示消息。

作为一种可选的实施方式，在第一终端的消息队列中存储有响应失败的业务请求时，上述数据交互方法还可以包括：响应对于该业务请求的恢复操作，将存储在该消息队列中的业务请求重新发送给该目标设备。

其中，消息队列中可以存储一条或多条未得到服务端正确响应的业务请求，当接收到对于消息队列中的业务请求的恢复操作时，响应恢复操作，将消息队列中存储的指定业务请求重新发送给目标设备上的服务端。指定业务请求可以是用户选定的业务请求，也可以是队列中的首条请求。

在一个实例中，当在进行***迁移任务时，若部分数据对应的迁移业务请求未得到正确响应，且轮询次数达到预设次数时，这些迁移业务请求暂存于消息队列中。用户可以在消息队列中存储的请求量达到一定条件时(例如队列快装满时)，对消息队列中的部分迁移业务请求进行恢复操作，以便于将这些迁移业务请求尝试性重发给服务端，若此时服务端已经可以恢复正常工作，则迁移业务请求正常执行，继续执行原本被中断的业务，该部分请求对应的数据可以正常迁移；若重发的请求仍然未得到正确响应且轮询失败次数达到预设次数，这部分迁移业务请求再次进入消息队列或被存储至其他的存储空间，以待用户处理。

通过上述实施方式，可以避免由于服务端的问题而造成应用端的请求数据丢失，便于在一些对数据敏感度高的应用场景下(例如金融行业)进行后续数据核对。

可选地，上述的交互请求包括约定请求，作为一种发送约定请求的方式，上述S11可以包括S111-S113。

S111：在当前网络为通畅状态时，获取闲置时长，该闲置时长表示从上一次向该目标设备发送数据时至当前时刻的时间长度。

其中，上一次向目标设备发送的数据可以是前述用于进行监测服务端网络通畅性的测试数据包，也可以是交互请求中的约定请求，还可以是交互请求中的业务请求，还可以是轮询请求。

S112：判断该闲置时长是否达到第一时间阈值。

本领域技术人员可以根据实际需要对第一时间阈值进行设定，例如第一时间阈值可以是2秒、5秒、8秒等。

S113：在该闲置时长达到第一时间阈值时，向该目标设备上的服务端发送该约定请求。

为了保障服务端的服务活性，在闲置时长达到第一时间阈值时，向目标设备上部署的服务端发送约定请求，并等待服务端根据约定请求进行响应。

可选地，约定请求可以是心跳请求或定时请求，心跳请求与定时请求的区别在于直接请求的对象不同，约定请求是应用端经过中间的应用程序协调服务发送的，是间接测试服务端的服务是否可用，而定时请求可以由应用端直接向服务端发送，通过点对点的传输方式直接测试服务端的服务是否可用。

不论是约定请求的类型是心跳请求还是定时请求，在具体应用时，应用端都可以发送特定的请求参数发出约定请求，服务端在收到约定请求后根据约定返回约定的约定数据，应用端通过服务端返回的约定数据来判定该服务端当前是否处于服务可用状态，确定该服务端的运行状态是否正常。

相应的，在向服务端发送约定请求后，上述S12可以包括子步骤S121-S122。

S121：判断该目标设备上的服务端是否在指定时间段内根据该约定请求返回约定数据。

指定时间段可以是应用端、服务端之间事先约定的时间段。

约定数据可以是返回码，约定数据的表现形式可以是数字、字符串或二者的组合。

S122：当该目标设备上的服务端在指定时间段内根据该约定请求返回约定数据时，确定该目标设备上的服务端对于该约定请求能够正确响应，以此确定该目标设备上的服务端处于服务可用状态。

当目标设备未在指定时间段内返回约定数据或者返回的数据不是约定数据时，确定该约定数据当前未得到正确相应，根据该约定请求向服务端发起轮询请求。在轮询失败次数达到预设次数时，确定该目标设备上服务端的应用服务不可用，该服务端处于服务不可用状态。

相应的，上述S14可以包括：在轮询失败次数达到预设次数时，根据该约定请求将该第一终端的指定服务关闭，该指定服务为与该约定请求对应的服务。

其中，在应用端判定出服务端处于服务不可用状态时，第一终端可以按照应用端程序中已有的逻辑将该约定请求对应的服务关闭和/或作出友好性提示(例如，显示当前的E服务暂不可用等)，还可以在确定服务端处于服务不可用状态时，作出熔断处理，防止因服务端问题造成应用端宕机引发雪崩效应后果。

通过上述实现方式，可以在确保服务端所在的目标设备处于网络通畅的情况下，进一步确定该服务端部署的应用是否能够正常运行，并在服务端部署的应用出现故障时及时发出预警提示消息，以通知相关用户进行处理。在确定服务端处于服务不可用状态时，在应用端及时对相应的服务进行处理，避免服务雪崩效应。

综上该，在上述方法中，通过应用端程序定时对服务端所在的目标设备进行定时ping可以对部署有服务端的目标设备进行网络监测，迅速甄别服务端所在的目标设备当前的网络情况，排除因网络带宽等因素造成响应失败的概率。并且通过在网络通畅的情况下，向服务端发送交互请求中的约定请求，可以定期与服务端进行交互，从而及时侦测到服务端的当前服务运行状态，在识别出服务端的服务不可用时，及时关闭应用端的相应服务，避免因服务端的问题造成应用端的服务雪崩效应。此外，通过在网络通畅的情况下，向服务端发送交互请求中的业务请求，可以在业务请求响应失败时，通过轮询请求进行重新请求，避免因服务端暂时的故障而误让应用端的服务关停，即使轮询失败次数过多，也可以失败的请求暂存于应用端对应的消息队列中，避免失败的请求数据丢失，以此能够在服务端恢复正常后，将中断的业务请求再次发送给服务端进行处理。且不论是哪一个处理环节，在多次发送失败(轮询多次且失败后)都可以及时发出对应的预警提示消息，以及时通知工作人员进行处理。上述方法有利于在可能出现问题的各个环节进行把控，对应用端的处理日志、原请求参数进行保存，最大限度地降低因服务端问题造成应用端服务不可用的损失。

基于同一发明构思，请参阅图4，本申请实施例还提供一种数据交互装置400，包括：交互模块401、判断模块402、轮询模块403、执行模块404。该装置提供的软件功能模块可以被封装在一存储介质中，也可以被打包以导入一些组件中。

交互模块401，用于在当前网络为通畅状态时，向目标设备上的服务端发送交互请求。

判断模块402，用于判断所述目标设备上的服务端对于所述交互请求是否正确响应。

轮询模块403，用于在所述目标设备上的服务端对于所述交互请求未正确响应时，根据所述交互请求向所述目标设备上的服务端发起轮询请求。

执行模块404，用于在轮询失败次数达到预设次数时，根据该交互请求的类型存储该交互请求或将该交互请求对应的服务关闭。

通过上述装置可以执行前述的数据交互方法，可以降低因带宽或其他网络问题带来的外部因素对请求的响应影响，还可以侦测到服务端的运行情况是否正常，有利于后续故障排除，还可以降低因服务端问题造成的应用端损失。

可选地，上述装置还可包括预警提示模块，用于在轮询失败次数达到预设次数时，根据该交互请求的类型向预设的用户终端发送预警提示消息；或，在当前网络未处于通畅状态时，向预设的用户终端发送预警提示消息。

可选地，上述装置还可包括网络监测模块，用于按照预设时间间隔，定时向该目标设备的网络地址发送测试数据；根据该目标设备对于该测试数据的响应情况确定当前网络状态。

可选地，网络监测模块还可用于按照预设时间间隔，定时通过因特网包探索器向该目标设备的网络地址发送指定字节的测试数据包；在接收到该目标设备根据该测试数据包返回的响应数据包时，判断该响应数据包的字节数是否与该测试数据包的字节数相同；在该响应数据包的字节数与该测试数据包的字节数相同时，确定当前网络为通畅状态。

可选地，执行模块404还可用于在轮询失败次数达到预设次数时，将业务请求存储在消息队列中。

可选地，执行模块404还可用于响应对于该业务请求的恢复操作，将存储在该消息队列中的业务请求重新发送给该目标设备。

可选地，交互模块401还可用于在当前网络为通畅状态时，获取闲置时长，该闲置时长表示从上一次向该目标设备发送数据时至当前时刻的时间长度；判断该闲置时长是否达到第一时间阈值；在该闲置时长达到第一时间阈值时，向该目标设备上的服务端发送该约定请求。

可选地，判断模块402还可用于判断该目标设备上的服务端是否在指定时间段内根据该约定请求返回约定数据；当该目标设备上的服务端在指定时间段内根据该约定请求返回约定数据时，确定该目标设备上的服务端对于该约定请求正确响应，以此确定该目标设备上的服务端处于服务可用状态。

可选地，执行模块404还可用于在轮询失败次数达到预设次数时，根据该约定请求将该第一终端的指定服务关闭，该指定服务为与该约定请求对应的服务。

关于本申请实施例提供的数据交互装置400的其他细节，请进一步参考前述数据交互方法中的相关描述，在此不再赘述。

除了上述实施例，本申请实施例还提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器执行时执行前述的数据交互方法。存储介质可以包括：移动硬盘、存储器、磁碟或者光盘等各种可以存储程序代码的介质。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

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

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

以上该仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种数据交互方法，其特征在于，应用于第一终端，所述方法包括：

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

3.根据权利要求1所述的方法，其特征在于，在所述向目标设备上的服务端发送交互请求之前，所述方法还包括：

4.根据权利要求3所述的方法，其特征在于，所述按照预设时间间隔，定时向目标设备的网络地址发送测试数据，包括：

5.根据权利要求1所述的方法，其特征在于，所述交互请求包括业务请求，所述在轮询失败次数达到预设次数时，根据所述交互请求的类型存储所述交互请求或将所述交互请求对应的服务关闭，包括：

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

7.根据权利要求1所述的方法，其特征在于，所述交互请求包括约定请求，所述在当前网络为通畅状态时，向目标设备上的服务端发送交互请求，包括：

判断所述闲置时长是否达到第一时间阈值；

8.根据权利要求7所述的方法，其特征在于，所述判断所述目标设备上的服务端对于所述交互请求是否正确响应，包括：

9.根据权利要求7所述的方法，其特征在于，所述在轮询失败次数达到预设次数时，根据所述交互请求的类型存储所述交互请求或将所述交互请求对应的服务关闭，包括：

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

存储器；

处理器；

所述存储器存储有所述处理器可执行的计算机程序，所述计算机程序被所述处理器执行时执行权利要求1-9任一项所述的方法。