CN111914149A - 一种请求处理方法、装置、存储介质及电子设备 - Google Patents

一种请求处理方法、装置、存储介质及电子设备 Download PDF

Info

Publication number
CN111914149A
CN111914149A CN202010436261.3A CN202010436261A CN111914149A CN 111914149 A CN111914149 A CN 111914149A CN 202010436261 A CN202010436261 A CN 202010436261A CN 111914149 A CN111914149 A CN 111914149A
Authority
CN
China
Prior art keywords
service
service request
request
processing
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010436261.3A
Other languages
English (en)
Inventor
黄禹
谈少华
贺睿
张飞鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Dami Technology Co Ltd
Original Assignee
Beijing Dami Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Dami Technology Co Ltd filed Critical Beijing Dami Technology Co Ltd
Priority to CN202010436261.3A priority Critical patent/CN111914149A/zh
Publication of CN111914149A publication Critical patent/CN111914149A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/953Querying, e.g. by the use of web search engines
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/957Browsing optimisation, e.g. caching or content distillation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请实施例公开了一种请求处理方法、装置、存储介质及电子设备,其中,方法包括:获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应,将所述服务请求发送至服务平台,当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。采用本申请实施例,可以避免服务请求丢失的情况。

Description

一种请求处理方法、装置、存储介质及电子设备
技术领域
本申请涉及计算机技术领域,尤其涉及一种请求处理方法、装置、存储介质及电子设备。
背景技术
随着互联网技术的发展,目前网络已基本实现普及,用户可以方便的通过智能手机、笔记本电脑、平板电脑等各种类型的终端来访问网络。其中,适合终端访问APP、H5页面等越来越受到青睐和重视。服务提供商、内容提供商等服务平台可以基于提供丰富资源和服务,来满足用户的使用需要。
一般,用户可以在终端的显示页面上触发相应的服务来生成服务请求(如点击某个服务对应的页面控件),并发送至服务平台进行相应的处理,从而在对服务请求处理成功的情况下为终端提供相应的资源或服务。
目前对服务请求的处理过程中,在终端与服务平台间的通信状态不佳情况下(例如晚上是用网高峰期,网络可能卡顿、延迟等)或在服务平台对服务请求处理过程中用户在终端上关闭生成服务请求时的界面的情况下,服务平台的处理就会中断,从而导致服务请求丢失的现象。
发明内容
本申请实施例提供了一种请求处理方法、装置、存储介质及电子设备,可以为业务线程分配到合适的处理器集群。本申请实施例的技术方案如下:
第一方面,本申请实施例提供了一种请求处理方法,所述方法包括:
获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应;
将所述服务请求发送至服务平台;
当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
第二方面,本申请实施例提供了另一种请求处理方法,所述方法包括:
接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地;
响应于所述服务请求,对所述请求参数进行处理;
基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;
接收所述终端基于所述处理失败信息发送的所述服务请求。
第三方面,本申请实施例提供了一种请求处理装置,所述装置包括:
服务请求生成模块,用于获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应;
服务请求发送模块,用于将所述服务请求发送至服务平台;
服务请求重新模块,用于发送当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
第四方面,本申请实施例提供了另一种请求处理装置,所述装置包括:
服务请求接收模块,用于接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地;
服务请求处理模块,用于响应于所述服务请求,对所述请求参数进行处理;
处理信息发送模块,用于基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;
所述服务请求接收模块,还用于接收所述终端基于所述处理失败信息发送的所述服务请求。
第五方面,本申请实施例提供一种计算机存储介质,所述计算机存储介质存储有多条指令,所述指令适于由处理器加载并执行上述的方法步骤。
第六方面,本申请实施例提供一种电子设备,可包括:处理器和存储器;其中,所述存储器存储有计算机程序,所述计算机程序适于由所述处理器加载并执行上述的方法步骤。
本申请一些实施例提供的技术方案带来的有益效果至少包括:
在本申请一个或多个实施例中,终端获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应,将所述服务请求发送至服务平台,当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。通过在生成服务请求是就将服务请求在本地进行保存,即使在服务平台对服务请求的过程中,由于通信状态不佳或用户在终端上关闭生成服务请求时的对应界面,造成服务平台的处理失败时服务请求丢失的现象,终端在接收到处理失败信息之后,可以在本地获取已保存的服务请求重新发送至服务平台进行处理,从而避免了服务请求的丢失现象,同时可以在处理是失败的情况下重新发送服务请求,可以使服务请求快速得到服务平台响应,进行处理,提高了服务平台处理服务请求的效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种请求处理方法的流程示意图;
图2是本申请实施例提供的请求处理方法所涉及到的一种在线教育场景下的推荐课程的界面示意图;
图3是本申请实施例提供的另一种请求处理方法的流程示意图;
图4是本申请实施例提供的请求处理方法所涉及到的一种课程内容数据的界面示意图;
图5是本申请实施例提供的请求处理方法所涉及到的一种课程试听界面的界面示意图;
图6是本申请实施例提供的另一种请求处理方法的流程示意图;
图7是本申请实施例提供的一种请求处理装置的结构示意图;
图8是本申请实施例提供的一种服务请求获取模块的结构示意图;
图9是本申请实施例提供的一种通信状态确定单元的结构示意图;
图10是本申请实施例提供的另一种请求处理装置的结构示意图;
图11是本申请实施例提供的另一种请求处理装置的结构示意图;
图12是本申请实施例提供的一种服务请求处理模块的结构示意图;
图13是本申请实施例提供的另一种请求处理装置的结构示意图;
图14是本申请实施例提供的一种电子设备的结构示意图;
图15是本申请实施例提供的操作系统和用户空间的结构示意图;
图16是图14中安卓操作系统的架构图;
图17是图14中IOS操作系统的架构图;
图18是本申请实施例提供的另一种电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在本申请的描述中,需要理解的是,术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性。在本申请的描述中,需要说明的是,除非另有明确的规定和限定,“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。对于本领域的普通技术人员而言,可以具体情况理解上述术语在本申请中的具体含义。此外,在本申请的描述中,除非另有说明,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
下面结合具体的实施例对本申请进行详细说明。
在一个实施例中,如图1所示,特提出了一种请求处理方法,该方法可依赖于计算机程序实现,可运行于基于冯诺依曼体系的请求处理装置上。该计算机程序可集成在应用中,也可作为独立的工具类应用运行。以下将以请求处理装置为终端对所述请求处理方法进行详细释义,如下:
终端可以是具有请求处理功能的电子设备,该电子设备包括但不限于:可穿戴设备、手持设备、个人电脑、平板电脑、车载设备、智能手机、计算设备或连接到无线调制解调器的其它处理设备等。在不同的网络中终端设备可以叫做不同的名称,例如:用户设备、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置、蜂窝电话、无绳电话、个人数字处理(personaldigital assistant,PDA)、5G网络或未来演进网络中的终端设备等。
具体的,该请求处理方法包括:
步骤S101:获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应。
所述服务请求操作用于请求或指示终端生成针对某业务服务的服务请求的输入操作,可以理解的是用户可以在终端的显示界面上针对某一业务服务的服务请求(即请求该业务服务)的输入操作,常见的服务请求操作可以是服务请求点击操作、服务请求滑动操作、服务请求拖拽操作,等等。以下以在线教育场景为例,对相关操作进行详细释义。
其中,服务请求点击操作可以是在某在线教育的应用页面中,用户针对点击服务对象(图片、文本、图标等)的点击,点击服务对象与某业务服务相对应或相关联,如查看图片的服务、复制文本的服务、打开图标对应的页面服务,进一步的,所述服务请求点击操作可以是单次点击某个图标或文本查看详情、双次点击某个图标或文字开启页面等,当所述服务请求点击操作为用户通过外部设备诸如鼠标输入时,所述服务请求点击操作具体形式还包括左键单击、左键双击、中键单击、中键双击、右键单击、右键双击等操作,进一步的,
服务请求滑动操作可以是在某在线教育的应用页面中,用户在应用页面中亮点之间的滑动,如九宫格滑动操作、连续拖动课程图片进行滑动、连续拖动页面播放试听课程的小视频等场景,进一步的,如用户在应用页面中连续拖动页面课程图片输入的服务请求滑动操作,此时通常会涉及到终端向服务平台请求课程图片数据,终端通过获取到服务请求滑动操作,进而生成针对课程图片数据的服务请求(如向服务平台请求图片资源等)。
服务请求拖拽操作可以是在某在线教育的应用页面中,用户在应用页面选中拖拽对象(图片、文本、图标等)后,手指不离开屏幕的拖拽操作,且在手指拖拽的过程中,被拖拽对象随着手指移动而移动。拖拽服务对象与某业务服务相对应或相关联,需要说明的是所述拖拽操作可以是通过外部设备诸如鼠标、电子教鞭、激光笔等设备完成的。
进一步的,服务请求操作通常与其操作产生时对应的业务服务相关联或相对应,服务平台可以向终端上的用户提供特定的服务(如在线教育场景下的视频播放服务、课程答疑服务、课程销售服务等等),所述特定的服务可以是以应用软件为载体,终端可以安装该应用软件(如在线教育软件),业务服务为终端上自动触发或由用户所触发的一种特定的服务,在触发时即由用户针对业务服务在显示页面上的载体(图标、文字、图片、视频、控件等),具体服务类型可根据实际应用环境中服务平台的开发者开发并确定,服务平台可以实时对周期性对终端上的应用软件上的特定的服务进行维护、对产生的服务请求进行响应等等,此处不作具体限定。
具体的,终端可以向用户提供服务平台的相关业务服务(在线教育场景涉及的订课服务、续课服务、答疑服务等等),用户可以在终端上针对服务平台提供的多种业务服务中选择所需的目标服务,如用户通过手指触控的方式选中目标服务对应的控件(图标、按钮等等)来输入服务请求操作,服务请求操作用于请求或指示终端生成相应的服务请求,以请求服务平台提供相应的目标服务,此时终端可以检测到目标服务被用户所触发时所输入的服务请求操作,随之获取服务请求操作的操作数据,终端基于操作数据可以确定生成服务请求时的请求参数,然后基于请求参数来生成服务请求,即服务请求操作对应的服务请求,并将所述服务请求保存至本地。
其中,服务请求操作的操作数据在本申请实施例中基于用户的行为操作而生成,操作数据可以是当前表征用户所触发的业务服务的数据,如当前操作的时间点、触发的控件名、向服务平台所请求的业务服务名等等,可以是用户的历史行为数据,如历史观看多媒体的时长、开启多媒体的次数、多媒体的内容量等等,可以理解的是,请求参数与用户的服务请求操作的操作数据相对应,可以是操作数据中的全部或部分数据,具体根据服务请求操作对应生成的服务请求类型确定,可以理解的是不同的服务请求对应着不同的请求参数。
如,该服务请求为用于请求服务平台进行推荐视频的视频推荐类服务请求,则视频推荐类服务请求的请求参数可以是历史观看视频的时长、开启视频的次数、视频的内容量等参数。
如,该服务请求为用于请求服务平台建立会话连接的会话建立类服务请求,则会话建立类服务请求的请求参数可以是用户当前的ID、待建立会话的服务人员(如在线教育场景中的课程顾问类、课程销售类、问题答疑类的服务人员)等参数。以使服务平台可以基于包含请求参数的服务请求,建立请求参数相匹配的服务终端与用户的终端之间的会话连接。
具体的,终端在基于请求参数生成服务请求之后,可以将服务请求保存在本地存储空间中,可以理解的是,通常终端在向服务平台发送服务请求,和/或服务请求收到服务请求进行处理的过程,会存在请求丢失的情况,在本申请实施例中,终端在生成服务请求之后,先将服务请求存储至本地,避免服务请求服务平台处理失败时,可以基于本地存储的服务请求重新请求服务平台进行处理。
步骤S102:将所述服务请求发送至服务平台。
具体的,终端预先建立与服务平台之间的通信连接,终端可以基于通信连接将生成的服务请求发送至服务平台。可以理解的是,服务平台通过与终端之间的通信连接建立之后,可以接收到终端发送的服务请求,服务平台可以对服务请求进行响应,对服务请求进行处理,基于处理结果可以向终端反馈处理信息,如处理成功信息以及处理失败信息。
在一个具体的实施场景中,以在线教育下基于课程推荐建立会话连接的为了,所述终端可以是电脑、手机、平板等智能设备,为了描述的方便,以终端为平板举例,所手机可以搭载有服务平台提供的在线教育的应用程序,所述在线教育的应用程序具备向用户提供推荐课程进行播放的功能,用户打开手机的应用程序显示界面,如图2所示,图2是一种在线教育场景下的推荐课程的界面示意图,用户在图2中试听某一节在线教育提供的推荐课程,图2的显示界面上显示有本节推荐课程的一些课程介绍和课程图案,若用户通过对推荐课程的了解觉得对该节课程感兴趣,想进一步的了解该节课程的详细介绍以及课程服务(如要购买该课程服务)时,可以通过手指触控图2显示界面中的服务控件-“感兴趣”按钮,进一步的,终端可以具有触摸屏,所述触摸屏可以是能够实现单一触摸功能的触摸屏,例如:电容触摸屏、电磁触摸屏,也可以是能够同时实现电容感应、电磁感应和红外感应的触摸屏。当用户通过手指触摸终端上的触摸屏时,触摸位置的电容参数发生变化,触摸框根据电容的变化,确定手指在终端触摸屏的触摸位置;或者,手指在接触触摸框时,阻挡了红外的接收端接收红外信号,触摸框根据被阻挡的红外信号确定手指的触摸位置,通过识别所述触摸位置对应的逻辑控制指令对应的代码,终端可以检测到用户针对服务控件-“感兴趣”按钮输入的服务请求操作,然后获取服务请求操作的操作数据,根据“感兴趣”按钮对应的会话建立类服务请求,可以将操作数据中的用户当前的ID、待建立会话的服务人员(课程顾问类)作为请求参数,生成包含请求参数的服务请求并保存至本地,以使服务平台可以基于包含请求参数的服务请求,建立请求参数相匹配的服务终端与用户的终端之间的会话连接。服务平台可以对服务请求进行响应,向终端上的用户提供所需的会话连接类服务,如为用户终端分配一个服务终端,并建立用户的终端与服务终端之间的会话连接,可以理解的是在会话连接建立之后,终端上的用户可以基于该会话连接向服务终端咨询“该推荐课程”对应的详细介绍以及课程服务,等等,更进一步,当服务平台基于请求参数对服务请求处理失败时即会返回处理失败信息。
进一步的,用户的终端与服务平台之间的通信连接通常为采用预设通信架构建立的通信连接服务,所述通信架构是指进行数据通信的一种通信结构,通信架构定义了数据网络通信系统的各个方面,包含通信的接口类型、使用的网络协议、实现的数据框架、通信布线的类型等。常用的通信架构可以是TCP/IP架构,Netty架构、C/S架构、SOA架构等。如,一种所述通信架构可以是为采用基于java开源的Netty框架,并配合WebSocket技术从而实现通信网络中服务平台与用户终端之间建立一种长连接(或短连接)的通信连接,并基于通信连接实现两端之间的通信数据的交互。以下将对基于长连接的通信链路以及基于短连接的通信连接进行详细释义,如下:
其中,所述所建立的通信连接可以为http长连接的通信链路或http短连接的通信链路。
长连接,指在一个连接上可以连续发送多个数据包,在连接保持期间,如果没有数据包发送,需要双方发链路检测包。
长连接的操作步骤是:建立连接——数据传输...(保持连接)...数据传输——关闭连接。
短连接是指通讯双方有数据交互时,就建立一个连接,数据发送完成后,则断开此连接,即每次连接只完成一项业务的发送。
短连接的操作步骤是:建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接。
长连接多用于操作频繁,点对点的通讯。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是短连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,下次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接,如果用短连接频繁的通信会造成socket错误,而且频繁的socket创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。所以并发量大,但每个用户无需频繁操作情况下需用短链接好。
长连接可以省去较多的TCP建立和关闭的操作,减少浪费,节约时间。在实际应用中,当通信链路传输的通信数据为对通信传输质量要求高的实时在线教学视频数据时,可以采用基于长连接的通信链路,如服务平台与终端之间采用基于长连接的通信链路
此时,长连接对于服务平台来说管理较为简单,存在的连接都是有用的连接,不需要额外的控制手段。但如果客户请求频繁,将在TCP的建立和关闭操作上浪费时间和带宽。因此,本申请实施例中,服务平台可以根据实际通信数据传输的环境,合适的方式来建立服务平台与用户的终端之间的通信连接。
步骤S103:当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
具体的,终端可以基于通信连接将生成的服务请求发送至服务平台之后,服务平台通过所述通信连接接收到终端发送的服务请求,服务平台可以对服务请求进行响应,对服务请求进行处理,基于处理结果可以向终端反馈处理信息,如处理成功信息以及处理失败信息,以在线教育为例,服务请求所请求的业务服务至少包括:提供授课服务的业务服务、提供课程销售的业务服务、提供课程答疑的业务服务、提供课程售后的业务服务,等等。
具体的,通常终端在向服务平台发送服务请求,和/或服务请求收到服务请求进行处理的过程,会存在请求丢失的情况,如终端与服务平台之间的通信连接中断,此时,服务平台可能会对服务请求处理失败,或,终端难以即时收到服务平台返回的信息,又如,若用户所输入的服务请求操作为在终端的A显示界面触发的,而在服务平台对服务请求处理过程中,用户从终端的A显示界面退出到B显示界面上,此时就可能存在由于服务请求与A显示界面强相关,如会话连接类服务请求、视频推荐类服务请求等等,就会导致终端的A显示界面上的服务请求处理失败的情况,在相干技术中,通常该服务请求就会被丢失,而导致终端或服务平台不能及时对服务请求进行处理或进行响应的情况,在本申请实施例中,在服务平台对服务请求处理过程中,若服务平台对服务请求处理,会向终端反馈处理失败信息,当接收到所述服务平台基于所述服务请求返回的处理失败信息时,由于终端在生成服务请求之后,先将服务请求存储至本地,避免服务请求服务平台处理失败时,可以基于本地存储的服务请求重新请求服务平台进行处理。
在一种可行的实施方式,终端可以预先设置一预设时长,当在预设时长接收到服务平台基于所述服务请求处理返回的处理成功信息时,终端即可根据处理成功信息确定服务请求处理成功;当在预设时长接收到服务平台基于所述服务请求处理返回的处理成功信息或所述处理失败信息时,终端即可确定服务请求处理失败,此时,一方面,终端与服务平台之间的通信连接可能中断导致未能成功返回处理成功信息或所述处理失败信息,一方面,终端与服务平台之间的通信连接的通信状况不佳以及服务平台的服务处理处于负载状态,如以在线教育为例,此时会由于通信链路的网络带宽不足和/或服务平台处理能力不够的情形下(例如晚上上课是用网高峰期,网络可能卡顿),此时当前通信链路间的数据传输受阻(服务请求传输受阻、返回信息传输受阻),例如产生延迟、卡顿乃至掉线等等,从而导致服务请求处理失败,此时由于终端在生成服务请求之后,先将服务请求存储至本地,终端在服务请求服务平台处理失败时,可以基于本地存储的服务请求重新请求服务平台进行处理,即重新通过通信连接向服务平台发送服务请求,可以直至接收到服务平台返回的处理成功信息。
在本申请实施例中,终端获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应,将所述服务请求发送至服务平台,当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。通过在生成服务请求是就将服务请求在本地进行保存,即使在服务平台对服务请求的过程中,由于通信状态不佳或用户在终端上关闭生成服务请求时的对应界面,造成服务平台的处理失败时服务请求丢失的现象,终端在接收到处理失败信息之后,可以在本地获取已保存的服务请求重新发送至服务平台进行处理,从而避免了服务请求的丢失现象,同时可以在处理是失败的情况下重新发送服务请求,可以使服务请求快速得到服务平台响应,进行处理,提高了服务平台处理服务请求的效率。
请参见图3,图3是本申请提出的一种请求处理方法的另一种实施例的流程示意图。具体的:
步骤S201:获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应。
在一种具体的实施场景中,所述服务请求操作可以是目标服务对应的服务控件被触发时生成的,终端可以获取用户针对目标服务对应的服务控件所触发的服务请求操作,所述服务控件为所述用户终端的多媒体课程界面上设置的控件。
所述多媒体课程界面中通常可以包含与课程教学相关的显示文字、图片、动画、表格、图标等显示元素的界面,在实际应用中,终端上的显示页面通常可以为提供课程教学功能的应用程序对应的显示页面(如基于H5编程语言开发的页面),所述应用程序包括但不限于第三方开发、终端操作系统本身自带的应用,以及包括一些由第三方开发、用户终端操作系统本身自带的应用、小程序、插件等。
所述控件可以理解为用于开发构建用户终端用户显示界面(即UI界面)的显示内容所对应的“数据和方法的封装”,通过控件可以实现一定的方法功能,如可以提供视窗、文本框、按钮、下拉式菜单等界面元素的功能,通常控件可分为四个类型:
命令控件(imperative control):用于启动特定的功能,常见的命令控件有按钮控件、图标控件、超链接控件等;
选择控件(selection control):用于选择选项或数据,常见的选择控件有复选框控件、列表框控件、列表控件、文本编辑控件等;
输入控件(entry control):用于输入数据,常见的输入控件有微调器控件、刻度盘控件、滑块控件等;
显示控件(display control):用于控制应用“如何”及“在哪里”展示特定的数据,常用的显示控件有显示文字的文字控件、显示图像的图像控件等。
在本申请实施例中,所述服务控件可以理解用于实现对与课程教学相关的目标服务对应的控件,通常所述服务控件可以为命令控件,用于启动服务平台上与服务终端间相应的目标服务的功能,在实际应用中,述服务控件通常以某一指定图像(如圆形、三角形)显示在终端的显示界面上,当用户在终端上针对述服务控件进行相应的触控操作时,即可触发服务控件对应的目标服务。更进一步的,在目标服务对应的服务控件被触发时,终端可以获取到用户所输入的服务请求操作,进而获取服务请求操作的操作数据,基于操作数据确定请求参数,生成包含请求参数的服务请求。
根据一些实施例中,终端可以向用户提供服务平台的相关业务服务(在线教育场景涉及的订课服务、续课服务、答疑服务等等),用户可以在终端上针对服务平台提供的多种业务服务中选择所需的目标服务,如用户通过手指触控的方式选中目标服务对应的控件(图标、按钮等等),以达到在终端上选择目标业务的目的,此时终端可以检测目标服务被用户所触发,随之获取到目标服务对应的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地。
其中,所述基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地可参考步骤S101步骤,此处不再赘述
步骤S202:将所述服务请求发送至服务平台,接收到所述服务平台基于所述服务请求返回的处理失败信息。
具体可参见步骤S102,此处不再赘述。
步骤S203:确定与所述服务平台之间的通信链路为通信异常状态。
具体的,终端当接收到所述服务平台基于所述服务请求返回的处理失败信息时,对终端与所述服务平台之间的通信链路进行通信状态检测,以确定与所述服务平台之间的通信链路的通信状态。所述通信状态至少包括通信正常状态和通信异常状态。所述通信正常状态可以理解为所述通信链路的当前通信状态优良,传输延迟较低,可以满足终端与服务平台之间上行和下行数据的传输;所述通信异常状态可以理解为所述通信链路的当前通信状态不佳,数据通信链路传输延迟较高,链路负荷过重、网络带宽不足等。(例如晚上上课是用网高峰期,网络可能卡顿),此时当前通信链路间的数据传输受阻(服务请求传输受阻、返回信息传输受阻),例如产生延迟、卡顿乃至掉线等等,从而导致服务请求处理失败。可以理解的是,当服务请求对应的向服务平台所请求的服务与通信链路的链路状态强相关时,如视频类服务请求,即时通讯类服务请求,此时,服务平台通常在处理该服务请求时就会处理失败,从而向终端返回处理失败消息。
步骤S204:对所述通信链路的通信状态进行监测,以及确定与所述服务平台之间通信链路为通信正常状态,从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台。
具体的,终端可以获取所述通信链路的至少一个通信参数来实现对通信状态的监测,根据所述通信参数确定所述通信链路的通信质量;然后获取所述服务请求对应的请求服务类型,确定所述请求服务类型对应的预设通信条件;当所述通信质量符合预设通信条件时,终端可以确定与所述服务平台之间通信链路为通信正常状态。从而从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台。
在一种具体的实施场景中,终端具有通信状态监测机制,可以对当前通信链路的通信状进行监测;终端在建立与服务平台之间的通信链路之后,终端可以通过通信状态监测机制,对当前通信链路进行监测,具体为终端可以获取通信链路的至少一个通信参数,根据所述通信参数确定所述通信链路的通信质量,当所述通信质量符合预设条件时,确定所述通信链路的通信链路状态为通信正常状态。反之,当所述通信质量不符合预设条件时,确定所述通信链路的通信链路状态为通信异常状态。
其中所述预设条件根据实际应用环境中获取的通信参数而定,而针对不同请求服务类型的服务请求可以对应不同的预设条件,如,常见的请求服务类型可以是按照数据类型分类,可以是视频类服务请求类型、音频类服务请求类型、文本类服务请求类型等等,又如,常见的请求服务类型可以是按照业务种类划分,如订课类服务请求类型、续课类服务请求类型、答疑类服务请求类型等等,具体划分可以结合实际需要,对不同类型的服务请求进行划分,此处不作具体限定。
进一步的,某一预设条件可以是针对至少一个通信参数设置,一种是对各通信参数分贝设置参数范围,当一个或多个通信参数落入到各自对应的参数范围内时,确定所述通信链路的通信链路状态为通信正常状态;一种是设置参数阈值,当一个或多个通信参数达到参数阈值时,确定所述通信链路的通信链路状态为通信正常状态。其中,通信参数达到参数阈值可以理解为:通信参数大于或等于参数阈值时,确定所述通信链路的通信链路状态为通信正常状态;或,通信参数小于或等于参数阈值时,确定所述通信链路的通信链路状态为通信正常状态。具体根据通信参数所表征的通信评判指标而定,如通信数据的丢包率,当丢包率小于丢包率阈值时,确定所述通信链路的通信链路状态为通信正常状态。又如数据传输的延迟时间,当延迟时间小于时间阈值时,确定所述通信链路的通信链路状态为通信正常状态。
在一种可行的实施方式中,终端可以根据各所述通信参数计算通信质量分;基于通信质量分来评判通信链路的通信链路状态,具体为:
终端可以通过对当前通信链路的通信质量进行评测,根据各所述通信参数计算通信质量分,以来通信质量分确定终端与服务平台之间通信链路上行或下行数据的通信状况,所述通信参数可以是发射/接收速率、信号能量、通信过程中的数据丢包率、通信过程中的数据重传率等通信参数中的一个或多个,根据各通信参数来计算通信质量分,从而衡量当前的通信质量。
更进一步的,终端设置有质量分阈值,所述质量分阈值通常在实际应用环境中,采集大量通信样本数据运用统计学方法得到。
1、当计算得到的所述通信质量分小于质量分阈值时,终端可以确定所述通信链路的通信链路状态为通信负载状态;
2、当计算得到的所述通信质量分小于质量分阈值时,终端可以确定所述通信链路的通信链路状态为通信正常状态。
其中,一种计算方法可以是对各通信参数设置不同或相同的权重值,基于各通信参数以及所述权重值进行加权计算,可以得到当前通信质量分;
其中,一种计算方法可以是对各通信参数设置参考参数特征(如参考指示值、参考指示范围、参考指示距离等),将至少一个网络通信参数中各网络通信参数与其对应的参数特征计算差异特征信息(如差异通信参数值),根据差异特征信息进行评分,根据差异特征信息进行评分时,可以是设置评分等级,例如设置三个等级:等级A>等级B>C,以上述数据连接类参数包含两个通信参数为例进行释义:计算通信参数A1与参考指示值A的差异通信值a,当差异通信值a达到等级B对应的数值时,此时即将等级B对应的分数作为当前通信质量分。
其中,所述通信参数包括但不限于当前通信天线上行/下行数据信号的参考信号接收功率(Reference Signal Receiving Power,RSRP)、接收信号码功率(receivedsignal code power,RSCP)、天线接收的信号的接收码片信号强度和噪声强度的比例(EcIo)/每调制比特功率和噪声频谱密度的比率(EcNo)/信噪比(Signal-to-Noise Ratio,SNR)/参考信号接收质量(Reference Signal Receivingquality,RSRQ)、天线接收的信号的误码率(Bit Error Ratio,BER)/误块率(Blockerror Rate,BLER)/数据包差错率(Packet Error Ratio,PER)等参数中的至少一种参数来实现对当前通信链路的通信链路状态的评估,当然也可以通过测量其他的参数来实现对当前通信链路的通信链路状态的评估。
需要说明的是,所述测量通信链路的通信参数有多种,可以是上述提及的一种或多种的拟合,此处不作具体的限定。
在一种可行的实施方式中,终端可以将获取到的各项通信参数输入至训练好的评分确定模型中,输出通信链路的通信质量分。其中,通过获取实际应用环境中的通信样本数据,提取特征信息,并对所述通信样本数据对应的分值进行标注,所述特征信息包含至少一个通信参数(RSSI、SNR、RSCP等),创建信息类型确定模型。所述评分确定模型可以是使用大量的通信样本训练出来的,如评分确定模型可以是基于卷积神经网络(ConvolutionalNeural Network,CNN)模型,深度神经网络(Deep Neural Network,DNN)模型、循环神经网络(RecurrentNeuralNetworks,RNN)、模型、嵌入(embedding)模型、梯度提升决策树(Gradient Boosting Decision Tree,GBDT)模型、逻辑回归(LogisticRegression,LR)模型中的至少一种实现的,基于已经标注分值的样本数据对评分确定模型进行训练,可以得到训练好的评分确定模型。
在本申请实施例中,所述评分确定模型可以采用引入误差反向传播算法的隐马尔可夫模型(DNN-HMM模型)创建初始模型,在提取所述通信样本数据的特征信息之后,将所述特征信息输入到所述DNN-HMM模型中,所述DNN-HMM模型的训练过程通常由正向传播和反向传播两部分组成,在正向传播过程中,终端输入样本-通信样本数据对应的特征信息从所述神经网络模型的输入层经过隐层神经元(也称节点)的传递函数(又称激活函数、转换函数)运算后,传向输出层,其中每一层神经元状态影响下一层神经元状态,在输出层计算实际输出值-异常信息类型,计算所述实际输出值与期望输出值的期望误差,基于所述期望误差调整所述DNN-HMM模型的参数,所述参数包含每一层的权重值和阈值,训练完成后,生成评分确定模型。
具体的,所述期望误差可以是计算实际输出值与期望输出值的均方误差MSE,均方误差MSE,所述均方误差MSE可以采用如下的公式:
Figure BDA0002502361750000161
其中,m为输出节点个数,p为训练样本数目,为期望输出值,为实际输出值。
其中,在本申请实施例中,当接收到所述服务平台基于所述服务请求返回的处理失败信息时,终端可以先检测与服务平台之间的通信链路的通信状态,根据通信状态来确定接收到处理失败信息的原由,如服务请求与通信链路的通信质量强相关的视频推荐类服务请求,通常服务平台会处理失败。
步骤S205:确定与所述服务平台之间的通信链路为通信正常状态。
所述确定与所述服务平台之间的通信链路为通信正常状态步骤可以参考步骤S204,此处不再赘述。
步骤S206:在检测到当前显示界面处于所述目标服务对应的目标显示界面时,从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台。
具体的,通常终端在向服务平台发送服务请求,和/或服务请求收到服务请求进行处理的过程,会存在请求丢失的情况,若用户所输入的服务请求操作为在终端的A显示界面针对目标服务的服务控件触发的,而在服务平台对服务请求处理过程中,用户从终端的A显示界面退出到B显示界面上,此时就可能存在由于服务请求与A显示界面上的目标服务强相关,当终端当前显示界面为B显示界面而不是A显示界面时,就可能导致服务平台无法对A显示界面上的目标服务触发时的服务请求进行处理,从而导致服务请求处理失败,从而接收到服务平台基于所述服务请求返回的处理失败信息。
如,假设终端在与服务平台之间的会话连接建立之后,终端向服务平台请求某一节课程的课程数据,如图4所示,图4是一种课程内容数据的界面示意图,在图4中,终端在与服务平台之间的会话连接建立之后,在当前显示界面上显示如图4所示的对话窗口,用户可以是在对话窗口显示界面中针对课程数据获取服务的获取控件输入触控操作,然后生成服务请求发送至服务平台以使服务平台对服务请求进行处理,针对课程数据获取服务的服务请求通常与该对话窗口显示界面强相关,当用户退出这个对话窗口时,通常会话连接会中断,如用户在服务平台对服务请求处理的过程中,退出到某课程试听界面,如图5所示,图5是一种课程试听界面的示意图,此时服务平台由于终端此时不再对话窗口显示界面就无法对服务请求进行处理,如无法向终端传输课程数据,就会收到终端发送的处理失败信息,进一步的,当用户再次进入到该对话窗口显示界面时,终端可以在如图4所示的界面上输出处理失败信息,即如图4中显示处理失败的标志“包含感叹号的圆形标志”,在相干技术中通常这个时候就会会存在用户上次的服务请求进行丢失的情况;在本申请实施例中,终端在生成服务请求是即在本地进行备份,终端可以实时或周期性对当前显示界面进行检测,检测当前显示界面是否为目标服务对应的目标显示界面(如对话窗口显示界面),当在检测到当前显示界面处于所述目标服务对应的目标显示界面时,即用户操作终端重新进入到目标服务对应的目标显示界面,终端可以从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台,从而避免在相干技术中服务请求丢失,造成服务请求不能及时响应的状况。
步骤S207:接收所述服务平台基于所述服务请求处理返回的处理成功信息。
具体的,终端重新将所述服务请求发送至服务平台进行处理,所述服务请求包含请求参数,服务平台基于与终端的通信连接可以重新接收到终端发送的服务请求,服务平台可以对服务请求进行响应,对服务请求进行处理,基于处理结果在处理成功的情况下可以向终端反馈处理成功信息。此时终端在接收到服务平台反馈的处理成功信息之后,即可确定服务请求处理成功。
步骤S208:确定所述服务请求为请求成功状态,对所述本地已保存的所述服务请求进行清除。
具体的,终端接收所述服务平台基于所述服务请求处理返回的处理成功信息之后,即可确定所述服务请求为请求成功状态,然后终端可以在本地对已保存的服务请求进行清除,以节省终端的内存资源,实现资源利用的最大化。
在一种可行的实施方式,终端可以预先设置一预设时长,当在预设时长接收到服务平台基于所述服务请求处理返回的处理成功信息时,终端即可根据处理成功信息确定服务请求处理成功;然后对所述本地已保存的所述服务请求进行清除。
在本申请实施例中,终端获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应,将所述服务请求发送至服务平台,当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。通过在生成服务请求是就将服务请求在本地进行保存,即使在服务平台对服务请求的过程中,由于通信状态不佳或用户在终端上关闭生成服务请求时的对应界面,造成服务平台的处理失败时服务请求丢失的现象,终端在接收到处理失败信息之后,可以在本地获取已保存的服务请求重新发送至服务平台进行处理,从而避免了服务请求的丢失现象,同时可以在处理是失败的情况下重新发送服务请求,可以使服务请求快速得到服务平台响应,进行处理,提高了服务平台处理服务请求的效率;以及根据通信链路的通信状态,选择适当的时机重新发送服务请求,可以实现对服务请求的精准发送,提高服务请求的处理效率,以及在处理成功之后,将本地保存的服务请求清除可以节省终端的内存资源。
在一个实施例中,如图6所示,特提出了另一种请求处理方法,该方法可依赖于计算机程序实现,可运行于基于冯诺依曼体系的请求处理装置上。该计算机程序可集成在应用中,也可作为独立的工具类应用运行。以下将以请求处理装置为服务平台对所述请求处理方法进行详细释义。
所述服务平台可以是单独的服务器设备,例如:机架式、刀片、塔式、或者机柜式的服务器设备,也可以采用工作站、大型计算机、等具备较强计算能力硬件设备,也可以采用多个服务器组成的服务器集群,所述服务集群中的各服务器可以是以对称方式组成的,其中每台服务器在业务链路中功能等价、地位等价,各服务器均可单独对外提供服务,所述单独提供服务可以理解为无需另外的服务器的辅助。
具体的,该请求处理方法包括:
步骤S301:接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地。
根据一些实施例中,服务平台可以向终端上的用户提供的相关业务服务(在线教育场景涉及的订课服务、续课服务、答疑服务等等),以使用户可以在终端上针对服务平台提供的多种业务服务中选择所需的目标服务,如用户通过手指触控的方式选中目标服务对应的控件(图标、按钮等等)来输入服务请求操作,服务请求操作用于请求或指示终端生成相应的服务请求,以请求服务平台提供相应的目标服务,此时终端可以检测到目标服务被用户所触发时所输入的服务请求操作,随之获取服务请求操作的操作数据,终端基于操作数据可以确定生成服务请求时的请求参数,然后基于请求参数来生成服务请求,即服务请求操作对应的服务请求,并将所述服务请求保存至本地。终端在保存之后即可将服务请求发送至服务平台;服务平台通常可以通过与终端之间的通信连接从而接收到终端发送的服务请求。
步骤S302:响应于所述服务请求,对所述请求参数进行处理。
根据一些实施例中,服务请求携带有请求参数,请求参数基于服务请求操作的操作数据生成,操作数据在本申请实施例中基于用户在终端上的行为操作而生成,操作数据可以是当前表征用户所触发的业务服务的数据,如当前操作的时间点、触发的控件名、向服务平台所请求的业务服务名等等,可以是用户的历史行为数据,如历史观看多媒体的时长、开启多媒体的次数、多媒体的内容量等等,可以理解的是,请求参数与用户的服务请求操作的操作数据相对应,可以是操作数据中的全部或部分数据,具体根据服务请求操作对应生成的服务请求类型确定,可以理解的是不同的服务请求对应着不同的请求参数。
如,该服务请求为用于请求服务平台进行推荐视频的视频推荐类服务请求,则视频推荐类服务请求的请求参数可以是历史观看视频的时长、开启视频的次数、视频的内容量等参数,则服务平台响应与服务请求,基于请求参数进行处理,以确定需要向终端推荐的视频。
如,该服务请求为用于请求服务平台建立会话连接的会话建立类服务请求,则会话建立类服务请求的请求参数可以是用户当前的ID、待建立会话的服务人员(如在线教育场景中的课程顾问类、课程销售类、问题答疑类的服务人员)等参数。服务平台可以基于包含请求参数的服务请求,建立请求参数相匹配的服务终端与用户的终端之间的会话连接。
进一步的,服务平台通常对请求参数进行处理时,一般采用两种方式,一种是同步处理。
一种是异步处理;同步处理是用户在操作时,作为前端的终端会获取到用户所输入的服务请求操作(如用户针对某一界面上目标服务对应的服务控件输入的),然后生成服务请求,并将服务请求发送至服务平台,服务平台若采用同步处理的方式,作为后端的服务平台必须处理完服务请求的内容,才会返回给前端结果,如向终端返回基于处理结果的处理成功信息或处理失败信息。
在后端的服务平台响应服务请求期间,用户如果在终端上关闭界面,服务平台的处理就会中断了,这个过程中用户只能被动的等待,如果请求的响应时间较长,用户体验会不够友好。因此,在本申请实施例中,服务平台若采用同步处理的方式,往往在终端和服务平台会对应着响应超时的判断机制,一方面,当服务请求的响应时间超出了设定的最大响应时长,即使服务请求并没有被服务平台处理完,后端的服务平台也会即刻返回一个处理信息,通常为处理失败信息(操作失败等异常状态时反馈),避免用户长时间等待。一方面,作为前端的终端侧会对应有一个服务请求的响应时间超出了设定的最大响应时长,在这个最大响应时长内未接收到服务平台反馈的处理信息时,即认为服务平台对服务请求处理失败。在相干技术中,在这种情况下就会出现服务请求处理失败的情况,而通常终端由于请求处理机制的限制,当处理请求发送之后通常就默认为该事务处理完成,不会去再次请求服务平台对服务请求进行处理(通常服务请求在处理失败之后就会丢失),在本申请实施例中,服务平台在对服务请求处理失败之后,会再次接收到终端重新在本地获取到的服务请求,以对服务请求再次进行处理,在处理成功时即会向终端返回处理成功信息。可以理解的是,由于服务请求在生成时已经在终端侧的本地进行备份,当终端确定服务平台再次处理失败时,服务平台会接收终端再次发送的服务请求,直至对服务请求正确响应,处理成功。从而避免了服务请求丢失的现象。
一种是异步处理,异步处理是用户在操作时,作为前端的终端会获取到用户所输入的服务请求操作(如用户针对某一界面上目标服务对应的服务控件输入的),然后生成服务请求,并将服务请求发送至服务平台,服务平台若采用异步处理的方式,作为后端的服务平台可以在处理完服务请求的内容之后,再返回给前端结果,如向终端返回基于处理结果的处理成功信息或处理失败信息。采用异步处理时,终端可以不需要等待后方的服务平台处理完成就可以去完成其他其它事务,终端上的所有事务可以并发处理。同时,服务平台在对服务请求进行异步处理时,服务平台可以根据终端的调用请求(如服务请求)的实际情况,对一些操作同一资源(如视频资源)的调用请求进行合并或者优化处理,减少整体处理量,从而提高服务平台处理性能。如多个终端对同一个资源进行更新时,可以对这些更新操作合并处理,只进行最后一次更新即可。采用异步处理的方式可以让服务平台上的请求处理系统以最少的计算资源实现最大的处理能力。具体在实施中,服务平台响应与终端发送的服务请求,从服务平台的线程池中为所述服务请求分配业务处理线程,在业务处理线程确定后,服务平台即可调用服务平台上线程池中的计算资源,对服务请求携带的请求参数进行异步处理。
在实际应用中,服务平台的任务调度器通常不清楚具体的被调用者(发起请求的一端),服务平台的任务调度器针对至少一个异步处理请求的实际情况,对一些操作同一资源(如视频资源)的调用请求进行合并或者优化处理,减少整体处理量,从而提高服务平台处理性能。如多个终端对同一个资源进行更新时,可以对这些更新操作合并处理,只进行最后一次更新即可。可以理解的是,在进行合并或者删减优化处理后,服务平台就把规整后的服务请求通过消息的发布订阅的方式告诉被调用者(发起请求的一端,如终端)。示意性的,作为调用者的终端只需要订阅对应的异步处理消息(如服务请求的消息)即可。进一步的,服务平台在对服务请求处理完之后,会对应一个处理结果,处理失败即对应处理失败的处理结果,处理成功即对应处理成功的处理结果。
步骤S303:基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求。
具体的,服务平台在对服务请求处理完之后,会对应一个处理结果,处理失败即对应处理失败的处理结果,处理成功即对应处理成功的处理结果。服务平台基于处理后的处理结果生成处理失败后的处理失败信息。
具体的,服务平台对服务请求处理后,在处理失败的情况下,服务平台可以基于处理后的处理结果生成处理失败后的处理失败信息,然后将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求。
在一种可行的实施方式中,服务平台在处理失败之后,可以将将所述处理结果以及所述服务请求记录至错误日志中,从服务平台运维的角度来看,服务平台可以实时获周期性监控服务请求的积压情况以及服务平台对服务请求处理失败的情况,即服务平台可以从错误日志中对服务请求以及服务请求的处理结构进行分析,从而根据分析机构,可以做到快速地扩容或者对其它业务服务限流、降级、熔断等运维处理。
步骤S304:接收所述终端基于所述处理失败信息发送的所述服务请求,响应于所述服务请求,对所述请求参数进行处理。
根据一些实施例中,服务平台在对服务请求处理失败之后,会再次接收到终端重新在本地获取到的服务请求,以对服务请求再次进行处理,在处理成功时即会向终端返回处理成功信息。可以理解的是,由于服务请求在生成时已经在终端侧的本地进行备份,当终端确定服务平台处理失败时,服务平台会接收终端再次发送的服务请求,然后响应于所述服务请求,对所述请求参数进行再次处理,直至对服务请求正确响应,处理成功。从而避免了服务请求丢失的现象。
其中,所述对所述请求参数进行处理具体可参考步骤S302,此处不再赘述。
步骤S305:基于处理后的处理结果生成处理成功后的处理成功信息,将所述处理成功信息发送至所述终端。
根据一些实施例中,服务平台在对服务请求处理完之后,会对应一个处理结果,处理失败即对应处理失败的处理结果,处理成功即对应处理成功的处理结果。服务平台基于处理后的处理结果生成处理成功后的处理成功信息,然后基于与终端之间的通信连接将处理成功信息发送至所述终端。终端接收到所述处理成功信息即可确定服务请求处理成功,终端可以将在本地已保存的服务请求进行清除。
在本申请实施例中,服务平台接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地,响应于所述服务请求,对所述请求参数进行处理;基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;接收所述终端基于所述处理失败信息发送的所述服务请求。服务平台可以在对服务请求处理失败的情况下,能够接收到终端发送的本地已保存的服务请求,避免了由于通信状态不佳或用户在终端上关闭生成服务请求时的对应界面,造成服务平台的处理失败时服务请求丢失的现象,同时,服务平台可以在处理失败的情况下基于重新发送的服务请求进行处理,提高了服务平台处理服务请求的效率。
下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。
请参见图7,其示出了本申请一个示例性实施例提供的请求处理装置的结构示意图。该请求处理装置可以通过软件、硬件或者两者的结合实现成为装置的全部或一部分。该装置1包括服务请求生成模块11、服务请求发送模块12和服务请求重新模块13。
服务请求生成模块11,用于获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应;
服务请求发送模块12,用于将所述服务请求发送至服务平台;
服务请求获取模块13,用于发送当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
可选的,所述服务请求获取模块13,具体用于:
当预设时长内未接收到所述服务平台基于所述服务请求处理返回的处理成功信息或所述处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
可选的,如图10所示,所述装置1,包括:
处理成功信息接收模块14,用于接收所述服务平台基于所述服务请求处理返回的处理成功信息;
服务请求清除模块15,用于确定所述服务请求为请求成功状态,对所述本地已保存的所述服务请求进行清除。
可选的,所述服务请求生成模块11,具体用于:
获取针对目标服务对应的服务控件所触发的服务请求操作,所述服务控件为所述用户终端的多媒体课程界面上设置的控件。
可选的,如图8所示,所述服务请求获取模块13,包括:
通信状态确定单元131,用于确定与所述服务平台之间的通信链路为通信异常状态;
通信状态监测单元132,用于对所述通信链路的通信状态进行监测,以及确定与所述服务平台之间通信链路为通信正常状态;
服务请求重新发送单元133,用于从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台;
所述通信状态确定单元131,还用于确定与所述服务平台之间的通信链路为通信正常状态;
所述服务请求重新发送单元133,还用于在检测到当前显示界面处于所述目标服务对应的目标显示界面时,从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台。
可选的,如图9所示,所述通信状态确定单元131,包括:
通信质量确定子单元1311,用于获取所述通信链路的至少一个通信参数,根据所述通信参数确定所述通信链路的通信质量;
预设通信条件确定子单元1312,用于获取所述服务请求对应的请求服务类型,确定所述请求服务类型对应的预设通信条件;
通信正常状态确定子单元1313,用于当所述通信质量符合预设通信条件时,确定与所述服务平台之间通信链路为通信正常状态。
需要说明的是,上述实施例提供的请求处理装置在执行请求处理方法时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的请求处理装置与请求处理方法实施例属于同一构思,其体现实现过程详见方法实施例,这里不再赘述。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
在本申请实施例中,终端获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应,将所述服务请求发送至服务平台,当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。通过在生成服务请求是就将服务请求在本地进行保存,即使在服务平台对服务请求的过程中,由于通信状态不佳或用户在终端上关闭生成服务请求时的对应界面,造成服务平台的处理失败时服务请求丢失的现象,终端在接收到处理失败信息之后,可以在本地获取已保存的服务请求重新发送至服务平台进行处理,从而避免了服务请求的丢失现象,同时可以在处理是失败的情况下重新发送服务请求,可以使服务请求快速得到服务平台响应,进行处理,提高了服务平台处理服务请求的效率;以及根据通信链路的通信状态,选择适当的时机重新发送服务请求,可以实现对服务请求的精准发送,提高服务请求的处理效率,以及在处理成功之后,将本地保存的服务请求清除可以节省终端的内存资源。
请参见图11,其示出了本申请一个示例性实施例提供的请求处理装置的结构示意图。该请求处理装置可以通过软件、硬件或者两者的结合实现成为装置的全部或一部分。该装置2包括服务请求接收模块21、服务请求处理模块22和处理失败信息发送模块23。
服务请求接收模块21,用于接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地;
服务请求处理模块22,用于响应于所述服务请求,对所述请求参数进行处理;
处理信息发送模块23,用于基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;
所述服务请求接收模块21,还用于接收所述终端基于所述处理失败信息发送的所述服务请求。
可选的,如图12所示,所述服务请求处理模块22,包括:
业务处理线程分配单元221,用于响应于所述服务请求,从线程池中为所述服务请求分配的业务处理线程;
服务请求处理单元222,用于为所述业务处理线程调用所述线程池中的计算资源,对所述请求参数进行异步处理。
可选的,如图13所示,所述装置2,包括:
错误日志记录模块24,用于将所述处理结果以及所述服务请求记录至错误日志中。
可选的,所述装置2,包括:
所示服务请求处理模块22,还用于响应于所述服务请求,对所述请求参数进行处理;
所述处理信息发送模块23,还用于基于处理后的处理结果生成处理成功后的处理成功信息,将所述处理成功信息发送至所述终端。
需要说明的是,上述实施例提供的请求处理装置在执行请求处理方法时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的请求处理装置与请求处理方法实施例属于同一构思,其体现实现过程详见方法实施例,这里不再赘述。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
在本申请实施例中,服务平台接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地,响应于所述服务请求,对所述请求参数进行处理;基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;接收所述终端基于所述处理失败信息发送的所述服务请求。服务平台可以在对服务请求处理失败的情况下,能够接收到终端发送的本地已保存的服务请求,避免了由于通信状态不佳或用户在终端上关闭生成服务请求时的对应界面,造成服务平台的处理失败时服务请求丢失的现象,同时,服务平台可以在处理失败的情况下基于重新发送的服务请求进行处理,提高了服务平台处理服务请求的效率。
本申请实施例还提供了一种计算机存储介质,所述计算机存储介质可以存储有多条指令,所述指令适于由处理器加载并执行如上述图1-图6所示实施例的所述请求处理方法,具体执行过程可以参见图1-图6所示实施例的具体说明,在此不进行赘述。
本申请还提供了一种计算机程序产品,该计算机程序产品存储有至少一条指令,所述至少一条指令由所述处理器加载并执行如上述图1-图6所示实施例的所述请求处理方法,具体执行过程可以参见图1-图6所示实施例的具体说明,在此不进行赘述。
请参考图14,其示出了本申请一个示例性实施例提供的电子设备的结构方框图。本申请中的电子设备可以包括一个或多个如下部件:处理器110、存储器120、输入装置130、输出装置140和总线150。处理器110、存储器120、输入装置130和输出装置140之间可以通过总线150连接。
处理器110可以包括一个或者多个处理核心。处理器110利用各种接口和线路连接整个电子设备内的各个部分,通过运行或执行存储在存储器120内的指令、程序、代码集或指令集,以及调用存储在存储器120内的数据,执行电子设备100的各种功能和处理数据。可选地,处理器110可以采用数字信号处理(digital signal processing,DSP)、现场可编程门阵列(field-programmable gate array,FPGA)、可编程逻辑阵列(programmable logicArray,PLA)中的至少一种硬件形式来实现。处理器110可集成中央处理器(centralprocessing unit,CPU)、图像处理器(graphics processing unit,GPU)和调制解调器等中的一种或几种的组合。其中,CPU主要处理操作系统、用户界面和应用程序等;GPU用于负责显示内容的渲染和绘制;调制解调器用于处理无线通信。可以理解的是,上述调制解调器也可以不集成到处理器110中,单独通过一块通信芯片进行实现。
存储器120可以包括随机存储器(random Access Memory,RAM),也可以包括只读存储器(read-only memory,ROM)。可选地,该存储器120包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区,其中,存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等,该操作系统可以是安卓(Android)系统,包括基于Android系统深度开发的系统、苹果公司开发的IOS系统,包括基于IOS系统深度开发的系统或其它系统。存储数据区还可以存储电子设备在使用中所创建的数据比如电话本、音视频数据、聊天记录数据,等。
参见图15所示,存储器120可分为操作系统空间和用户空间,操作系统即运行于操作系统空间,原生及第三方应用程序即运行于用户空间。为了保证不同第三方应用程序均能够达到较好的运行效果,操作系统针对不同第三方应用程序为其分配相应的系统资源。然而,同一第三方应用程序中不同应用场景对系统资源的需求也存在差异,比如,在本地资源加载场景下,第三方应用程序对磁盘读取速度的要求较高;在动画渲染场景下,第三方应用程序则对GPU性能的要求较高。而操作系统与第三方应用程序之间相互独立,操作系统往往不能及时感知第三方应用程序当前的应用场景,导致操作系统无法根据第三方应用程序的具体应用场景进行针对性的系统资源适配。
为了使操作系统能够区分第三方应用程序的具体应用场景,需要打通第三方应用程序与操作系统之间的数据通信,使得操作系统能够随时获取第三方应用程序当前的场景信息,进而基于当前场景进行针对性的系统资源适配。
以操作系统为Android系统为例,存储器120中存储的程序和数据如图16所示,存储器120中可存储有Linux内核层320、系统运行时库层340、应用框架层360和应用层380,其中,Linux内核层320、系统运行库层340和应用框架层360属于操作系统空间,应用层380属于用户空间。Linux内核层320为电子设备的各种硬件提供了底层的驱动,如显示驱动、音频驱动、摄像头驱动、蓝牙驱动、Wi-Fi驱动、电源管理等。系统运行库层340通过一些C/C++库来为Android系统提供了主要的特性支持。如SQLite库提供了数据库的支持,OpenGL/ES库提供了3D绘图的支持,Webkit库提供了浏览器内核的支持等。在系统运行时库层340中还提供有安卓运行时库(Android runtime),它主要提供了一些核心库,能够允许开发者使用Java语言来编写Android应用。应用框架层360提供了构建应用程序时可能用到的各种API,开发者也可以通过使用这些API来构建自己的应用程序,比如活动管理、窗口管理、视图管理、通知管理、内容提供者、包管理、通话管理、资源管理、定位管理。应用层380中运行有至少一个应用程序,这些应用程序可以是操作系统自带的原生应用程序,比如联系人程序、短信程序、时钟程序、相机应用等;也可以是第三方开发者所开发的第三方应用程序,比如游戏类应用程序、即时通信程序、相片美化程序、请求处理程序等。
以操作系统为IOS系统为例,存储器120中存储的程序和数据如图12所示,IOS系统包括:核心操作系统层420(Core OS layer)、核心服务层440(Core Services layer)、媒体层460(Media layer)、可触摸层480(Cocoa Touch Layer)。核心操作系统层420包括了操作系统内核、驱动程序以及底层程序框架,这些底层程序框架提供更接近硬件的功能,以供位于核心服务层440的程序框架所使用。核心服务层440提供给应用程序所需要的系统服务和/或程序框架,比如基础(Foundation)框架、账户框架、广告框架、数据存储框架、网络连接框架、地理位置框架、运动框架等等。媒体层460为应用程序提供有关视听方面的接口,如图形图像相关的接口、音频技术相关的接口、视频技术相关的接口、音视频传输技术的无线播放(AirPlay)接口等。可触摸层480为应用程序开发提供了各种常用的界面相关的框架,可触摸层480负责用户在电子设备上的触摸交互操作。比如本地通知服务、远程推送服务、广告框架、游戏工具框架、消息用户界面接口(User Interface,UI)框架、用户界面UIKit框架、地图框架等等。
在图17所示出的框架中,与大部分应用程序有关的框架包括但不限于:核心服务层440中的基础框架和可触摸层480中的UIKit框架。基础框架提供许多基本的对象类和数据类型,为所有应用程序提供最基本的系统服务,和UI无关。而UIKit框架提供的类是基础的UI类库,用于创建基于触摸的用户界面,iOS应用程序可以基于UIKit框架来提供UI,所以它提供了应用程序的基础架构,用于构建用户界面,绘图、处理和用户交互事件,响应手势等等。
其中,在IOS系统中实现第三方应用程序与操作系统数据通信的方式以及原理可参考Android系统,本申请在此不再赘述。
其中,输入装置130用于接收输入的指令或数据,输入装置130包括但不限于键盘、鼠标、摄像头、麦克风或触控设备。输出装置140用于输出指令或数据,输出装置140包括但不限于显示设备和扬声器等。在一个示例中,输入装置130和输出装置140可以合设,输入装置130和输出装置140为触摸显示屏,该触摸显示屏用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作,以及显示各个应用程序的用户界面。触摸显示屏通常设置在电子设备的前面板。触摸显示屏可被设计成为全面屏、曲面屏或异型屏。触摸显示屏还可被设计成为全面屏与曲面屏的结合,异型屏与曲面屏的结合,本申请实施例对此不加以限定。
除此之外,本领域技术人员可以理解,上述附图所示出的电子设备的结构并不构成对电子设备的限定,电子设备可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。比如,电子设备中还包括射频电路、输入单元、传感器、音频电路、无线保真(wireless fidelity,WiFi)模块、电源、蓝牙模块等部件,在此不再赘述。
在本申请实施例中,各步骤的执行主体可以是上文介绍的电子设备。可选地,各步骤的执行主体为电子设备的操作系统。操作系统可以是安卓系统,也可以是IOS系统,或者其它操作系统,本申请实施例对此不作限定。
本申请实施例的电子设备,其上还可以安装有显示设备,显示设备可以是各种能实现显示功能的设备,例如:阴极射线管显示器(cathode ray tubedisplay,简称CR)、发光二极管显示器(light-emitting diode display,简称LED)、电子墨水屏、液晶显示屏(liquid crystal display,简称LCD)、等离子显示面板(plasma display panel,简称PDP)等。用户可以利用电子设备101上的显示设备,来查看显示的文字、图像、视频等信息。所述电子设备可以是智能手机、平板电脑、游戏设备、AR(Augmented Reality,增强现实)设备、汽车、数据存储装置、音频播放装置、视频播放装置、笔记本、桌面计算设备、可穿戴设备诸如电子手表、电子眼镜、电子头盔、电子手链、电子项链、电子衣物等设备。
在图14所示的电子设备中,其中电子设备可以是一种终端,处理器110可以用于调用存储器120中存储的请求处理应用程序,并具体执行以下操作:
获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应;
将所述服务请求发送至服务平台;
当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
在一个实施例中,所述处理器110在执行所述请求处理方法时,具体执行以下操作:
当预设时长内未接收到所述服务平台基于所述服务请求处理返回的处理成功信息或所述处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
在一个实施例中,所述处理器110在执行所述并重新将所述服务请求发送至服务平台之后,还执行以下操作:
接收所述服务平台基于所述服务请求处理返回的处理成功信息;
确定所述服务请求为请求成功状态,对所述本地已保存的所述服务请求进行清除。
在一个实施例中,所述处理器110在执行所述获取所输入的服务请求操作时,具体执行以下操作:
获取针对目标服务对应的服务控件所触发的服务请求操作,所述服务控件为所述用户终端的多媒体课程界面上设置的控件。
在一个实施例中,所述处理器110在执行所述从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台时,具体执行以下操作:
确定与所述服务平台之间的通信链路为通信异常状态;对所述通信链路的通信状态进行监测,以及确定与所述服务平台之间通信链路为通信正常状态,从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台;和/或,
确定与所述服务平台之间的通信链路为通信正常状态;在检测到当前显示界面处于所述目标服务对应的目标显示界面时,从所述本地获取已保存的所述服务请求,并重新将所述服务请求发送至服务平台。
在一个实施例中,所述处理器110在执行所述所述确定与所述服务平台之间的通信链路为通信正常状态时,具体执行以下操作:
获取所述通信链路的至少一个通信参数,根据所述通信参数确定所述通信链路的通信质量;
获取所述服务请求对应的请求服务类型,确定所述请求服务类型对应的预设通信条件;
当所述通信质量符合预设通信条件时,确定与所述服务平台之间通信链路为通信正常状态。
在本申请实施例中,终端
提高了业务线程的运行效率。
请参见图18,为本申请实施例提供了另一种电子设备的结构示意图。如图18所示,所述电子设备2000可以包括:至少一个处理器2001,至少一个网络接口2004,用户接口2003,存储器2005,至少一个通信总线2002。
其中,通信总线2002用于实现这些组件之间的连接通信。
其中,用户接口2003可以包括显示屏(Display),可选用户接口2003还可以包括标准的有线接口、无线接口。
其中,网络接口2004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。
其中,处理器2001可以包括一个或者多个处理核心。处理器2001利用各种借口和线路连接整个服务器2000内的各个部分,通过运行或执行存储在存储器2005内的指令、程序、代码集或指令集,以及调用存储在存储器2005内的数据,执行服务器2000的各种功能和处理数据。可选的,处理器2001可以采用数字信号处理(Digital Signal Processing,DSP)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)、可编程逻辑阵列(Programmable Logic Array,PLA)中的至少一种硬件形式来实现。处理器2001可集成中央处理器(Central Processing Unit,CPU)、图像处理器(Graphics Processing Unit,GPU)和调制解调器等中的一种或几种的组合。其中,CPU主要处理操作系统、用户界面和应用程序等;GPU用于负责显示屏所需要显示的内容的渲染和绘制;调制解调器用于处理无线通信。可以理解的是,上述调制解调器也可以不集成到处理器2001中,单独通过一块芯片进行实现。
其中,存储器2005可以包括随机存储器(Random Access Memory,RAM),也可以包括只读存储器(Read-Only Memory)。可选的,该存储器2005包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器2005可用于存储指令、程序、代码、代码集或指令集。存储器1005可包括存储程序区和存储数据区,其中,存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现上述各个方法实施例的指令等;存储数据区可存储上面各个方法实施例中涉及到的数据等。存储器2005可选的还可以是至少一个位于远离前述处理器2001的存储装置。如图18所示,作为一种计算机存储介质的存储器2005中可以包括操作系统、网络通信模块、用户接口模块以及请求处理应用程序。
在图18所示的电子设备2000中,用户接口2003主要用于为用户提供输入的接口,获取用户输入的数据;而处理器2001可以用于调用存储器2005中存储的请求处理应用程序,并具体执行以下操作:
接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地;
响应于所述服务请求,对所述请求参数进行处理;
基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;
接收所述终端基于所述处理失败信息发送的所述服务请求。
在一个实施例中,所述处理器2001在执行所述响应于所述服务请求,对所述请求参数进行处理时,具体执行以下操作:
响应于所述服务请求,从线程池中为所述服务请求分配的业务处理线程;
为所述业务处理线程调用所述线程池中的计算资源,对所述请求参数进行异步处理。
在一个实施例中,所述处理器2001在执行所述基于处理后的处理结果生成处理失败后的返回信息之后,还执行以下操作:
将所述处理结果以及所述服务请求记录至错误日志中。
在一个实施例中,所述处理器2001在执行所述接收所述终端基于所述处理失败信息发送的所述服务请求之后,还执行以下操作:
响应于所述服务请求,对所述请求参数进行处理;
基于处理后的处理结果生成处理成功后的处理成功信息,将所述处理成功信息发送至所述终端。
在本申请实施例中,服务平台接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地,响应于所述服务请求,对所述请求参数进行处理;基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;接收所述终端基于所述处理失败信息发送的所述服务请求。服务平台可以在对服务请求处理失败的情况下,能够接收到终端发送的本地已保存的服务请求,避免了由于通信状态不佳或用户在终端上关闭生成服务请求时的对应界面,造成服务平台的处理失败时服务请求丢失的现象,同时,服务平台可以在处理失败的情况下基于重新发送的服务请求进行处理,提高了服务平台处理服务请求的效率。
本领域的技术人员可以清楚地了解到本申请的技术方案可借助软件和/或硬件来实现。本说明书中的“单元”和“模块”是指能够独立完成或与其他部件配合完成特定功能的软件和/或硬件,其中硬件例如可以是现场可编程门阵列(Field-ProgrammaBLE GateArray,FPGA)、集成电路(Integrated Circuit,IC)等。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置,可通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些服务接口,装置或单元的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储器中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储器中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务平台或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储器包括:U盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通进程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储器中,存储器可以包括:闪存盘、只读存储器(Read-Only Memory,ROM)、随机存取器(Random AccessMemory,RAM)、磁盘或光盘等。
以上所述者,仅为本公开的示例性实施例,不能以此限定本公开的范围。即但凡依本公开教导所作的等效变化与修饰,皆仍属本公开涵盖的范围内。本领域技术人员在考虑说明书及实践这里的公开后,将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未记载的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的范围和精神由权利要求限定。

Claims (12)

1.一种请求处理方法,其特征在于,所述方法包括:
获取所输入的服务请求操作,基于所述服务请求操作生成包含请求参数的服务请求,将所述服务请求保存至本地,所述请求参数与所述服务请求操作的操作数据相对应;
将所述服务请求发送至服务平台;
当接收到所述服务平台基于所述服务请求返回的处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
当预设时长内未接收到所述服务平台基于所述服务请求处理返回的处理成功信息或所述处理失败信息时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台。
3.根据权利要求1所述的方法,其特征在于,所述重新将所述服务请求发送至服务平台之后,还包括:
接收所述服务平台基于所述服务请求处理返回的处理成功信息;
确定所述服务请求为请求成功状态,对所述本地已保存的所述服务请求进行清除。
4.根据权利要求1所述的方法,其特征在于,所述获取所输入的服务请求操作,包括:
获取针对目标服务对应的服务控件所触发的服务请求操作,所述服务控件为所述用户终端的多媒体课程界面上设置的控件。
5.根据权利要求1所述的方法,其特征在于,所述从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至所述服务平台,包括:
确定与所述服务平台之间的通信链路为通信异常状态;对所述通信链路的通信状态进行监测,以及确定与所述服务平台之间通信链路为通信正常状态,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至服务平台;和/或,
确定与所述服务平台之间的通信链路为通信正常状态;在检测到当前显示界面处于所述目标服务对应的目标显示界面时,从所述本地获取已保存的所述服务请求,重新将所述服务请求发送至服务平台。
6.根据权利要求5所述的方法,其特征在于,所述确定与所述服务平台之间的通信链路为通信正常状态,包括:
获取所述通信链路的至少一个通信参数,根据所述通信参数确定所述通信链路的通信质量;
获取所述服务请求对应的请求服务类型,确定所述请求服务类型对应的预设通信条件;
当所述通信质量符合预设通信条件时,确定与所述服务平台之间通信链路为通信正常状态。
7.一种请求处理方法,其特征在于,所述方法包括:
接收终端发送的服务请求,所述服务请求包含请求参数,所述请求参数为所述终端基于所输入的服务请求操作生成,所述服务请求在所述终端生成时保存至本地;
响应于所述服务请求,对所述请求参数进行处理;
基于处理后的处理结果生成处理失败后的处理失败信息,将所述处理失败信息发送至所述终端,所述处理失败信息用于指示所述终端从本地获取已保存的所述服务请求;
接收所述终端基于所述处理失败信息发送的所述服务请求。
8.根据权利要求7所述的方法,其特征在于,所述响应于所述服务请求,对所述请求参数进行处理,包括:
响应于所述服务请求,从线程池中为所述服务请求分配的业务处理线程;
为所述业务处理线程调用所述线程池中的计算资源,对所述请求参数进行异步处理。
9.根据权利要求7所述的方法,其特征在于,所述基于处理后的处理结果生成处理失败后的返回信息之后,还包括:
将所述处理结果以及所述服务请求记录至错误日志中。
10.根据权利要求7所述的方法,其特征在于,所述接收所述终端基于所述处理失败信息发送的所述服务请求之后,包括:
响应于所述服务请求,对所述请求参数进行处理;
基于处理后的处理结果生成处理成功后的处理成功信息,将所述处理成功信息发送至所述终端。
11.一种计算机存储介质,其特征在于,所述计算机存储介质存储有多条指令,所述指令适于由处理器加载并执行如权利要求1~6、7~10任意一项的方法步骤。
12.一种电子设备,其特征在于,包括:处理器和存储器;其中,所述存储器存储有计算机程序,所述计算机程序适于由所述处理器加载并执行如权利要求1~6、7~10任意一项的方法步骤。
CN202010436261.3A 2020-05-21 2020-05-21 一种请求处理方法、装置、存储介质及电子设备 Pending CN111914149A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010436261.3A CN111914149A (zh) 2020-05-21 2020-05-21 一种请求处理方法、装置、存储介质及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010436261.3A CN111914149A (zh) 2020-05-21 2020-05-21 一种请求处理方法、装置、存储介质及电子设备

Publications (1)

Publication Number Publication Date
CN111914149A true CN111914149A (zh) 2020-11-10

Family

ID=73237561

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010436261.3A Pending CN111914149A (zh) 2020-05-21 2020-05-21 一种请求处理方法、装置、存储介质及电子设备

Country Status (1)

Country Link
CN (1) CN111914149A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111131392A (zh) * 2019-11-27 2020-05-08 北京文渊佳科技有限公司 处理消息的方法、装置、电子设备及介质
CN112437155A (zh) * 2020-11-20 2021-03-02 北京健康之家科技有限公司 服务数据的处理方法、装置以及服务端设备
CN112597022A (zh) * 2020-12-24 2021-04-02 Oppo(重庆)智能科技有限公司 远程诊断方法、装置、存储介质及电子设备
CN114449034A (zh) * 2022-01-28 2022-05-06 湖南快乐阳光互动娱乐传媒有限公司 一种服务调用系统及方法
CN114706820A (zh) * 2022-05-18 2022-07-05 北京卡普拉科技有限公司 异步i/o请求的调度方法、系统、电子设备及介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001079995A2 (en) * 2000-04-05 2001-10-25 Chicory Systems, Inc. Method for making efficient service calls to a hardware coprocessor using load and/or store instructions
CN107484144A (zh) * 2017-09-28 2017-12-15 努比亚技术有限公司 一种信息获取方法、终端、服务器及计算机存储介质
CN108471369A (zh) * 2018-06-27 2018-08-31 深圳创维数字技术有限公司 一种网络拨号方法、装置及存储介质
CN108900627A (zh) * 2018-07-19 2018-11-27 武汉斗鱼网络科技有限公司 一种网络请求方法、终端装置及存储介质
CN109286593A (zh) * 2017-07-19 2019-01-29 腾讯科技(深圳)有限公司 传输重连的方法及装置、计算机设备及存储介质
CN110233881A (zh) * 2019-05-22 2019-09-13 平安科技(深圳)有限公司 业务请求处理方法、装置、设备及存储介质
CN111176866A (zh) * 2020-01-03 2020-05-19 精硕科技(北京)股份有限公司 数据交互方法和电子设备

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001079995A2 (en) * 2000-04-05 2001-10-25 Chicory Systems, Inc. Method for making efficient service calls to a hardware coprocessor using load and/or store instructions
CN109286593A (zh) * 2017-07-19 2019-01-29 腾讯科技(深圳)有限公司 传输重连的方法及装置、计算机设备及存储介质
CN107484144A (zh) * 2017-09-28 2017-12-15 努比亚技术有限公司 一种信息获取方法、终端、服务器及计算机存储介质
CN108471369A (zh) * 2018-06-27 2018-08-31 深圳创维数字技术有限公司 一种网络拨号方法、装置及存储介质
CN108900627A (zh) * 2018-07-19 2018-11-27 武汉斗鱼网络科技有限公司 一种网络请求方法、终端装置及存储介质
CN110233881A (zh) * 2019-05-22 2019-09-13 平安科技(深圳)有限公司 业务请求处理方法、装置、设备及存储介质
CN111176866A (zh) * 2020-01-03 2020-05-19 精硕科技(北京)股份有限公司 数据交互方法和电子设备

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111131392A (zh) * 2019-11-27 2020-05-08 北京文渊佳科技有限公司 处理消息的方法、装置、电子设备及介质
CN112437155A (zh) * 2020-11-20 2021-03-02 北京健康之家科技有限公司 服务数据的处理方法、装置以及服务端设备
CN112437155B (zh) * 2020-11-20 2024-02-20 北京水滴科技集团有限公司 服务数据的处理方法、装置以及服务端设备
CN112597022A (zh) * 2020-12-24 2021-04-02 Oppo(重庆)智能科技有限公司 远程诊断方法、装置、存储介质及电子设备
CN114449034A (zh) * 2022-01-28 2022-05-06 湖南快乐阳光互动娱乐传媒有限公司 一种服务调用系统及方法
CN114706820A (zh) * 2022-05-18 2022-07-05 北京卡普拉科技有限公司 异步i/o请求的调度方法、系统、电子设备及介质
CN114706820B (zh) * 2022-05-18 2022-09-06 北京卡普拉科技有限公司 异步i/o请求的调度方法、系统、电子设备及介质

Similar Documents

Publication Publication Date Title
CN108647051B (zh) 优化策略获取方法、提供方法、装置及设备
CN110582017B (zh) 一种视频播放方法、装置、终端及存储介质
CN111914149A (zh) 一种请求处理方法、装置、存储介质及电子设备
CN113360238A (zh) 消息处理方法、装置、电子设备和存储介质
CN113157906A (zh) 推荐信息展示方法、装置、设备及存储介质
CN111447107B (zh) 网络状态确定方法、装置、存储介质及电子设备
CN110198484B (zh) 消息推送方法、装置及设备
CN108156508B (zh) 弹幕信息处理的方法、装置、移动终端、服务器及系统
CN113676741B (zh) 数据传输方法、装置、存储介质及电子设备
CN111078172B (zh) 一种显示流畅度的调整方法、装置、电子设备及存储介质
KR100700689B1 (ko) 메신저를 이용한 sms 전송 방법 및 시스템, 상기 방법을실행시키기 위한 프로그램을 기록한 컴퓨터 판독 가능한기록매체
CN111124668A (zh) 内存释放方法、装置、存储介质及终端
CN112788583B (zh) 设备寻找方法、装置、存储介质及电子设备
CN111918386A (zh) 定位方法、装置、存储介质及电子设备
CN108429668B (zh) 一种消息处理方法、装置、终端及系统
CN111986454A (zh) 无线耳机的查找方法、装置、存储介质以及终端
WO2022016981A1 (zh) 图像处理方法、装置、存储介质及电子设备
CN113010825A (zh) 一种数据处理方法和相关装置
CN115328725A (zh) 状态监测方法、装置、存储介质及电子设备
CN111770510B (zh) 网络体验状态确定方法、装置、存储介质及电子设备
CN111191143A (zh) 应用推荐方法及装置
CN115379005A (zh) 一种消息处理方法、装置、存储介质及电子设备
CN112597022A (zh) 远程诊断方法、装置、存储介质及电子设备
CN113891123A (zh) 一种推送虚拟空间信息的方法、装置及系统
CN109657173B (zh) 一种网络资源加载方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination