掌桥专利:专业的专利平台
掌桥专利
首页

数据处理方法、存储介质及电子设备

文献发布时间:2023-06-19 11:17:41


数据处理方法、存储介质及电子设备

技术领域

本申请涉及计算机技术领域,尤其涉及数据处理领域,具体涉及一种数据处理方法、存储介质及电子设备。

背景技术

对于游戏应用,延迟是评估玩家游戏体验的一项重要指标,在现代游戏引擎设计中都会尽可能的减少游戏主进程的同步操作、优化耗时逻辑等设计处理。目前,对于游戏内部的业务指标等数据的采集,一般采用以下两种方式:

方式一,以异步输入输出(IO)的方式,将需要采集的数据写入日志中,然后通过系统的系统日志(syslog)再进行提取。这种方式的问题在于,当游戏应用的负载较高或者有大量日志产生时,磁盘的IO开销会大幅度提升,大量的读写操作会影响到CPU的利用率,从而影响到游戏业务,产生延迟。

方式二,类似Prometheus的采集,Prometheus是一个开源的服务监控系统和时间序列数据库,以http服务的方式暴露数据接口。当需要采集数据时,由客户端主动访问http接口并拉取数据。这种方式有两点问题,其一是http的方式进行数据传输的开销较大,而且会阻塞游戏主进程;其二是当有新指标需要采集时,要配合服务发现机制,进行新指标的注册,操作复杂度较高,开发成本较大。

因此,现有技术存在缺陷,有待改进与发展。

发明内容

本申请实施例提供一种数据处理方法、存储介质及电子设备,可以降低游戏业务的数据采集开销,同时不阻塞游戏进程的运行,减少玩家请求延时,提升游戏的数据采集效率。

本申请实施例提供了一种数据处理方法,应用于作为游戏主机设备的电子设备,所述电子设备配置有数据接收端和植入游戏进程的数据采集通信器SDK,所述SDK内配置有远程过程调用RPC接口,所述方法包括:

通过所述数据接收端接收用户设备上的应用程序编程接口API发送的数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;

控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求;

将所述SDK执行所述数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;

控制所述数据接收端从所述回环网卡的固定端口接收所述数据处理结果,并将所述数据处理结果发送至所述用户设备上的API。

本申请实施例还提供了一种数据处理方法,应用于作为用户设备的电子设备,所述电子设备配置有应用程序编程接口API,所述方法包括:

控制所述API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;

将所述数据处理请求发送至游戏主机设备;

接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果。

本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序适于处理器进行加载,以执行如上任一实施例所述的数据处理方法。

本申请实施例还提供一种电子设备,所述电子设备包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器通过调用所述存储器中存储的所述计算机程序,执行如上任一实施例所述的数据处理方法。

本申请实施例提供的数据处理方法、存储介质及电子设备,通过游戏主机设备的数据接收端接收用户设备上的API发送的数据处理请求,数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;控制数据接收端基于SDK的RPC接口请求SDK执行数据处理请求;将SDK执行数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;然后控制数据接收端从回环网卡的固定端口接收数据处理结果,并将数据处理结果发送至用户设备上的API。本申请实施例可以降低游戏业务的数据采集开销,同时不阻塞游戏进程的运行,减少玩家请求延时,提升游戏的数据采集效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的数据处理系统的结构示意图。

图2为本申请实施例提供的数据处理方法的第一流程示意图。

图3为本申请实施例提供的数据处理方法的第二流程示意图。

图4为本申请实施例提供的数据处理装置的第一结构示意图。

图5为本申请实施例提供的数据处理装置的第二结构示意图。

图6为本申请实施例提供的电子设备的结构示意图。

具体实施方式

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

首先,在对本申请实施例进行描述的过程中出现的部分名词或者术语作如下解释:

伯克利包过滤器(Berkeley Packet Filter,BPF):是类UNIX系统上数据链路层的一种原始接口,提供原始链路层封包的收发。用户态的进程可以提供一个过滤程序来声明它想收到哪些数据包。通过这种过滤可以避免从操作系统内核向用户态复制其他对用户态程序无用的数据包,从而极大地提高性能。

远程过程调用(Remote Procedure Call,RPC):是一种计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间(通常为一个开放网络的一台计算机)的子程序,而程序员就像调用本地程序一样,无需额外地为这个交互作用编程,无需关注细节。

应用程序编程接口(application programming interface,API):提供用户编程时的接口,是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。

用户数据报协议(User Data Protocol,UDP):为一种无连接不可靠的传输层协议,常见于对延迟比较敏感的联机游戏中。

软件开发工具包(Software Development Kit,SDK):SDK是一系列程序接口、文档、开发工具的集合。比如一个完整的SDK应该包括以下内容:接口文件和库文件,帮助文档,开发示例,实用工具。接口文件和库文件用于将底层的代码进行封装保护,提供给用户一个调用底层代码的接口;帮助文档用于解释接口文件和库文件功能,以及介绍相关的开发工具,操作示例等;开发示例就是做出来的一个DEMO展示,也要包括源代码;实用工具是用来协助用户进行二次开发的工具,比如二次开发向导、API搜索工具、软件打包工具等。在本申请实施例中,SDK为植入游戏进程的数据采集通信器,以RPC协议方式进行通信。

tick:是游戏引擎中游戏进程执行游戏逻辑的一种常见函数。该函数周期性的执行一些游戏内固定逻辑,类似于时钟“嘀嗒”。

回环网卡(Loopback adaptor):简称lo网卡,是一种特殊的网络接口,不与任何实际设备连接,而是完全由软件实现。比如微软回环网卡(Microsoft Loopback Adapter),类似一个虚拟网卡,能够被安装在一个没有网卡或者要用于测试多个宿主环境的Windows上。lo网卡是一块虚拟网卡,将数据发送到lo网卡,相比发送到真实网卡,其优势是,只会经过内核协议栈处理,从应用层到会话层,再到网络层即可完成数据传输,而无需通过传输层和物理层,减少了传输成本。

etcd:是一个分布式的、高可用的、一致的键值(key-value)存储数据库。

iowait:用于表示系统等待IO的时间,经常用于反映系统IO压力。

本申请实施例提供了一种数据处理方法、存储介质及电子设备,通过采用植入式的SDK,SDK植入游戏进程后,暴露RPC接口;SDK通过RPC接口为数据接收端提供数据交互服务,其中RPC接口包含数据请求接口及新增采集指标接口,数据接收端通过RPC接口,请求SDK进行相应的数据采集;SDK采集数据后,通过非阻塞UDP接口向本地主机(localhost)的回环网卡(Loopback adaptor)的固定端口发送数据;数据接收端从上述lo网卡的固定端口接收数据,比如数据接收端通过BPF从上述lo网卡的固定端口接收数据。采集逻辑为在每次游戏主进程tick时执行,通过RPC的方式对外暴露数据接口,以及通过非阻塞UDP的方式进行数据发送,相比于通过http的方式进程数据采集发送,开销更小;另外,由于对外暴露的RPC接口还包含新增采集指标接口,当有新指标需要采集时,通过数据处理请求,每个SDK会根据数据处理请求自动进行数据采集,从而避免了服务发现机制的引入,减少了开发部署成本;同时,通过非阻塞UDP接口发送数据,相比于写日志的方式,磁盘开销更小,IO延迟更低,并且还通过BPF实现的数据接收方式,完全独立于游戏进程,其读写能力不会对游戏进程产生任何影响,可以大幅度的减少数据采集时的IO开销,减少处理时延,优化玩家体验。

本申请实施例提供一种数据处理方法、存储介质及电子设备。具体地,本申请实施例的数据处理方法可以由电子设备执行,其中,该电子设备可以为终端或者服务器等设备。该终端可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、个人计算机(PersonalComputer,PC)、个人数字助理(Personal Digital Assistant,PDA)等终端设备,终端还可以包括客户端,该客户端可以是游戏应用客户端、携带有游戏程序的浏览器客户端或即时通信客户端等。服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。

请参阅图1,图1为本申请实施例提供的数据处理系统的结构示意图。本申请实施例提供一种数据处理系统,包括游戏主机设备10、缓存设备20和用户设备30。

其中,游戏主机设备10内部署有SDK、lo网卡和数据接收端,游戏应用部署在游戏主机设备10上,SDK为植入游戏进程的数据采集通信器,SDK通过RPC接口进行通信;数据接收端为独立运行的数据收集进程,从lo网卡的固定端口过滤出所需要的数据,比如通过BPF从lo网卡的固定端口过滤出所需要的数据,并负责与缓存设备20及用户设备30中的API进行交互。

其中,每个游戏应用都会部署在多台独立的游戏主机设备10上,该游戏主机设备10也可以称为游戏应用的宿主,该游戏主机设备10可以为安装有游戏应用的服务器或者终端。

其中,缓存设备20负责缓存各个游戏主机设备10上的数据接收端所采集的数据,避免同一请求短时间内多次执行,减少游戏进程压力。用户设备30中的API用于与各个游戏主机设备10上的数据接收端进行通信,以发起数据收集请求。

其中,用户设备30可以为用户使用的该终端可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、PC、PDA等终端设备,终端还可以包括客户端,该客户端可以是游戏应用客户端、携带有游戏程序的浏览器客户端或即时通信客户端等。用户设备30上设有API,比如该API可以以UI界面的形式来展示,用户可以通过UI界面进行一些触控操作,通过UI界面发起的接口调用即向API发起请求。

例如,游戏主机设备10与用户设备30可以为同一个设备,也可以为不同的设备。缓存设备20可以为任意具备数据缓存能力的设备。比如缓存设备20与游戏主机设备10可以为同一个设备,也可以为不同的设备;比如缓存设备20与用户设备30可以为同一个设备,也可以为不同的设备。

具体的,数据处理系统的主要交互流程如下:

(1)用户设备30上的API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种。

例如,用户设备30上设有API,该API以UI界面的形式来展示,用户可以通过在UI界面输入的触控操作,来调用API,API响应于在UI界面输入的触控操作,生成数据处理请求。

(2)将所述数据处理请求发送至游戏主机设备10。

(3)通过游戏主机设备10上的数据接收端接收用户设备上的API发送的数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种。

(4)游戏主机设备10控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求。

(5)游戏主机设备10将所述SDK执行所述数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口。

(6)控制所述数据接收端通过BPF从所述回环网卡的固定端口接收所述数据处理结果,并将所述数据处理结果发送至所述用户设备10上的API。

(7)用户设备30上的API接收游戏主机设备10响应所述数据处理请求后返回的数据处理结果。

在一些实施例中,当数据处理请求为数据采集请求时,数据处理系统的具体交互流程如下:

(1)用户通过用户设备30上的API发起数据采集请求,所述数据采集请求包括待采集的目标数据对应的目标进程、待采集的目标实体以及所述目标实体的采集指标。其中,实体是指游戏内部抽象的具体对象,例如,若玩家是一种实体类型,则每个玩家就是一个实体;若怪物是一种实体类型,则每个怪物就是一个实体;目标实体即为要采集的实体。指标是指一个实体的指标信息,比如玩家的等级、血量、金钱等;采集指标即为要采集的指标。

(2)缓存设备20获取用户设备30上的API发送的数据采集请求,所述数据采集请求用于指示缓存设备20查找缓存数据中是否存在与所述数据采集请求对应的目标数据。缓存设备20根据所述数据采集请求,查找缓存数据中是否存在与所述数据采集请求对应的目标数据,并将查找结果发送至用户设备30上的API。若查找结果为缓存数据中存在与所述数据采集请求对应的目标数据,则将携带有所述目标数据的查找结果发送至用户设备30上的API。若查找结果为缓存数据中不存在与所述数据采集请求对应的目标数据,则将携带有不存在目标数据的提示信息的查找结果发送至用户设备30上的API。即先在缓存设备30内查找缓存数据中是否存在与所述数据采集请求对应的目标数据,如果查找结果为存在则直接返回目标数据给用户。

例如,用户设备30上的API可以与缓存设备20直接交互,用户设备30上的API直接将数据采集请求发送至缓存设备20,然后由缓存设备20直接将响应于数据采集请求的查找结果返回至用户设备30上的API。

例如,用户设备30上的API可以通过游戏主机设备10上的数据接收端与缓存设备20间接交互,用户设备30上的API将数据采集请求发送至游戏主机设备10上的数据接收端,游戏主机设备10上的数据接收端获取API发送的数据采集请求,然后游戏主机设备10上的数据接收端将获取的所述数据采集请求发送至缓存设备20,缓存设备20获取用户设备30上的API通过游戏主机设备10上的数据接收端发送的数据采集请求,然后根据所述数据采集请求,查找缓存数据中是否存在与所述数据采集请求对应的目标数据,并将查找结果通过游戏主机设备10上的数据接收端发送至用户设备30上的API。

(3)若用户设备30上的API接收到携带有不存在目标数据的提示信息的查找结果,则对所有游戏主机设备10发起数据处理请求,所述数据处理请求携带有所述数据采集请求,与所述数据采集请求相关的游戏进程所在的游戏主机设备10上的数据接收端接收并响应所述数据采集请求。即API收到数据采集请求后,如果在缓存设备20中内没有搜索到相应的目标数据,则对所有宿主发起数据处理请求,与数据采集请求相关的游戏进程所在的宿主的数据接收端将会接收该数据采集请求。

比如,与用户设备30建立通信连接的游戏主机设备包括A游戏主机、B游戏主机和C游戏主机,每台游戏主机上面具有三个游戏进程:游戏进程1、游戏进程2和游戏进程3,比如用户需要查找的目标数据为A游戏主机中的游戏进程2中的玩家X的金钱数据,则首先会查缓存设备20中的缓存数据是否存在上述目标数据,如果缓存数据中不存在目标数据。则会发起数据处理请求,当A游戏主机的游戏进程2与所述数据处理请求中的数据采集请求相匹配时,即A游戏主机的游戏进程2发现数据采集请求中的请求对象为自己时,则A游戏主机的游戏进程2会进行响应,其他进程则忽略该数据处理请求。

(4)游戏主机设备10上的数据接收端获取API发送的所述数据采集请求,并向目标进程中的SDK的RPC接口发送所述数据采集请求。

(5)RPC接口接收数据采集请求后,在每次目标进程执行目标函数时,进行目标数据的采集。例如,在每次目标进程执行tick函数时,根据所述数据采集请求进行目标数据的采集。

具体的,根据所述数据采集请求进行目标数据的采集,包括:

A、当SDK的RPC接口收到所述数据接收端发送的所述数据采集请求时,执行采集逻辑,进行目标数据的采集。

B、SDK采集到与所述数据采集请求对应的目标数据后,通过UDP进行异步非阻塞数据传输将所述目标数据传输至lo网卡;其中,SDK的传输对端为lo网卡及固定端口号,同时SDK在进行数据传输过程中不需要等待结果返回及进行错误处理。其中,上述异步非阻塞中的非阻塞是指非阻塞UDP,异步是指整个数据传输采集过程是异步的,无需同步等待。通过非阻塞的UDP接口发送目标数据,相比于日志采集方式,IO延迟更低,同时不需要监听和处理UDP接口的发送结果,即SDK通过非阻塞UDP进行数据发送,同时无需关心数据发送结果是否成功,无需重传,调用相关send函数后即可继续执行其他逻辑,而无需等待数据发送结果。其中,通常在游戏进程负载较高时,出现延迟的概率会更高,这时如果采用日志采集方式,则会大幅度增加CPU的系统等待IO时间(iowait),影响用户体验。另一种情况,当游戏出现异常问题时,日志量会大幅度增加,这时如果采用日志采集方式,会增加异常问题对游戏进程的影响,同时增加了日志处理的复杂度。本申请实施例通过非阻塞UDP接口发送数据,可以最小化游戏进程负载较高或者出现问题时对数据采集的影响。比如对比日志采集方式,虽然linux系统支持异步IO,但是日志写入至少需要write和fsync两种系统调用,以保证日志落盘,而且写磁盘必定会带来IO开销,影响到游戏进程的CPU占用;对比http方式,虽然有异步http支持的类库,但是http协议比较复杂,依赖的TCP有三次握手、重传等操作,http方式相对于本案的UDP方式,开销比较大,传输能力较弱;因此,相比于已有的日志采集方式和http方式,本申请实施例可以减少玩家请求延时。

C、所述数据接收端通过BPF拦截lo网卡及固定端口号接收到的所述目标数据,并还原所述目标数据的数据包。通过BPF技术拦截目标数据,一方面可以提升目标数据的获取效率,减少目标数据丢失或者异常的可能,另一方面在云原生的网络隔离场景下,可以减少数据流转路径,节省带宽。

(6)数据收集端接收到所述目标数据后,将所述目标数据发送至缓存设备20进行缓存,同时将所述目标数据发送至用户设备30上的API,以完成该次的数据采集请求。

其中,在实际场景中,排查游戏问题时,经常有多个用户会在短暂的间隔中请求相同的目标数据,将采集到的目标数据缓存至缓存设备20中,可以减少了游戏进程的数据采集次数,进而减少了游戏进程的采集开销。

在一些实施例中,当数据处理请求为新增采集指标请求时,数据处理系统的具体交互流程如下:

(1)用户通过用户设备30上的API发起新增采集指标请求,所述新增采集指标请求包括新增采集指标以及待新增的实体类型。其中,游戏进程中的每个实体会包含有非常多的指标,不可能每次都对所有指标进行采集,这样开销比较大,为了可以动态增删采集的指标数据,可以暴露一个接口,通过该接口可以让SDK采集新的指标。

(2)用户设备30上的API对所有游戏主机设备10发起数据处理请求,每一游戏主机设备10接收所述数据处理请求,所述数据处理请求携带有所述新增采集指标请求。即API对所有宿主发起数据处理请求,每个宿主的数据收集端将接收该数据处理请求。

(3)数据收集端向游戏主机设备10内所有游戏进程中每一游戏进程的SDK的RPC接口发送所述数据处理请求。

(4)当每一游戏进程的SDK的RPC接口接收到所述数据处理请求时,调用每一游戏进程的SDK中与新增采集指标请求对应的新增采集指标逻辑,以使所述新增采集指标生效,以保障下次采集时所述新增采集指标可访问,以完成该次的新增采集指标请求。

其中,由于SDK内置了新增采集指标逻辑,即内置了服务注册逻辑,并不需要额外部署ETCD等组件,同时减少了外部接口的监听依赖,节省了开发及部署成本。

本申请实施例提供的数据处理系统,通过游戏主机设备的数据接收端接收用户设备上的API发送的数据处理请求,数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;控制数据接收端基于SDK的RPC接口请求SDK执行数据处理请求;将SDK执行数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;然后控制数据接收端从回环网卡的固定端口接收数据处理结果,并将数据处理结果发送至用户设备上的API。本申请实施例可以降低游戏业务的数据采集开销,同时不阻塞游戏进程的运行,减少玩家请求延时,提升游戏的数据采集效率。

为了进一步说明本申请实施例,以下分别从游戏主机设备一侧以及用户设备一侧对本申请的数据处理方法进行说明。

请参阅图2,图2为本申请实施例提供的数据处理方法的第一流程示意图。本申请实施例提供了一种数据处理方法,应用于作为游戏主机设备的电子设备,所述电子设备配置有数据接收端和植入游戏进程的数据采集通信器SDK,所述SDK内配置有远程过程调用RPC接口。可选的,所述电子设备可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、PC机、PDA等终端设备。该方法的具体流程可以如下:

步骤201,通过所述数据接收端接收用户设备上的API发送的数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种。

例如,用户设备30上设有API,该API以UI界面的形式来展示,用户可以通过在UI界面输入的触控操作,来调用API,API响应于在UI界面输入的触控操作,生成数据处理请求。然后用户设备30上的API将数据处理请求发送至游戏主机设备10上的数据接收端,以使得游戏主机设备10通过所述数据接收端接收用户设备上的API发送的数据处理请求。

步骤202,控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求。

在一些实施例中,当所述数据处理请求为数据采集请求时,所述控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求,包括:

控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据采集请求,所述数据采集请求包括待采集的目标数据对应的目标进程、待采集的目标实体以及所述目标实体的采集指标;

控制所述SDK根据所述数据采集请求进行目标数据的采集,以得到包含有所述目标数据的数据处理结果。

在一些实施例中,在所述控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据采集请求之前,还包括:

判断所述电子设备内的所有游戏进程中是否存在与所述数据采集请求中的目标进程相关的目标游戏进程;

若所述电子设备内的所有游戏进程中存在与所述数据采集请求中的目标进程相关的目标游戏进程,则控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据采集请求。

在一些实施例中,在所述判断所述电子设备内的所有游戏进程中是否存在与所述数据采集请求中的目标进程相关的目标游戏进程之后,还包括:

若所述电子设备内的所有游戏进程中不存在与所述数据采集请求中的目标进程相关的目标游戏进程,则禁止所述数据接收端响应所述数据采集请求。

在一些实施例中,所述控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据采集请求,包括:

从所述电子设备内的所有游戏进程中确定出与所述数据采集请求中的目标进程对应的目标游戏进程;

控制所述数据接收端基于所述目标游戏进程的SDK的RPC接口,请求所述目标游戏进程的SDK执行所述数据采集请求;

所述控制所述SDK根据所述数据采集请求进行目标数据的采集,以得到包含有所述目标数据的数据处理结果,包括:

控制所述目标游戏进程的SDK根据所述数据采集请求进行目标数据的采集,以得到所述目标游戏进程的SDK对应的包含有所述目标数据的数据处理结果。

其中,当数据处理请求为数据采集请求时,步骤202对应的技术方案的实施例可参考数据处理系统对应的实施例,在此不再一一赘述。

在一些实施例中,当所述数据处理请求为新增采集指标请求时,所述控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求,包括:

控制所述数据接收端基于所述电子设备内的所有游戏进程中每一游戏进程的SDK的RPC接口,请求每一游戏进程的SDK执行所述新增采集指标请求,所述新增采集指标请求包括新增采集指标以及待新增的实体类型;

调用每一游戏进程的SDK中与所述新增采集指标请求对应的新增采集指标逻辑,以使所述新增采集指标生效,以得到每一游戏进程的SDK对应的包含有所述新增采集指标的生效信息的数据处理结果。

其中,当数据处理请求为数据采集请求时,步骤202对应的技术方案的实施例可参考数据处理系统对应的实施例,在此不再一一赘述。

步骤203,将所述SDK执行所述数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口。

在一些实施例中,所述UDP接口为非阻塞UDP接口,将所述SDK执行所述数据处理请求的数据处理结果,通过非阻塞UDP接口发送至回环网卡的固定端口。

在一些实施例中,所述UDP接口为异步非阻塞UDP接口,将所述SDK执行所述数据处理请求的数据处理结果,通过异步非阻塞UDP接口发送至回环网卡的固定端口。

其中,SDK的传输对端为lo网卡及固定端口号,同时SDK在进行数据传输过程中不需要等待结果返回及进行错误处理。其中,上述异步非阻塞中的非阻塞是指非阻塞UDP,异步是指整个数据传输采集过程是异步的,无需同步等待。通过非阻塞的UDP接口发送目标数据,相比于日志采集方式,IO延迟更低,同时不需要监听和处理UDP接口的发送结果,即SDK通过非阻塞UDP进行数据发送,同时无需关心数据发送结果是否成功,无需重传,调用相关send函数后即可继续执行其他逻辑,而无需等待数据发送结果。其中,通常在游戏进程负载较高时,出现延迟的概率会更高,这时如果采用日志采集方式,则会大幅度增加CPU的系统等待IO时间(iowait),影响用户体验。另一种情况,当游戏出现异常问题时,日志量会大幅度增加,这时如果采用日志采集方式,会增加异常问题对游戏进程的影响,同时增加了日志处理的复杂度。本申请实施例通过非阻塞UDP接口发送数据,可以最小化游戏进程负载较高或者出现问题时对数据采集的影响。比如对比日志采集方式,虽然linux系统支持异步IO,但是日志写入至少需要write和fsync两种系统调用,以保证日志落盘,而且写磁盘必定会带来IO开销,影响到游戏进程的CPU占用;对比http方式,虽然有异步http支持的类库,但是http协议比较复杂,依赖的TCP有三次握手、重传等操作,http方式相对于本案的UDP方式,开销比较大,传输能力较弱;因此,相比于已有的日志采集方式和http方式,本申请实施例可以减少玩家请求延时。

步骤204,控制所述数据接收端从所述回环网卡的固定端口接收所述数据处理结果,并将所述数据处理结果发送至所述用户设备上的API。

例如,通过BPF技术拦截目标数据,一方面可以提升目标数据的获取效率,减少目标数据丢失或者异常的可能,另一方面在云原生的网络隔离场景下,可以减少数据流转路径,节省带宽。

在一些实施例中,当所述数据处理结果包含有所述目标数据时,所述控制所述数据接收端从所述回环网卡的固定端口接收所述数据处理结果之后,还包括:

通过所述数据接收端将所述目标数据发送至缓存设备进行缓存。

其中,在实际场景中,排查游戏问题时,经常有多个用户会在短暂的间隔中请求相同的目标数据,将采集到的目标数据缓存至缓存设备20中,可以减少了游戏进程的数据采集次数,进而减少了游戏进程的采集开销。

上述所有的技术方案,可以采用任意结合形成本申请的可选实施例,在此不再一一赘述。

本申请实施例提供的数据处理方法,应用于作为游戏主机设备的电子设备,电子设备配置有数据接收端和植入游戏进程的数据采集通信器SDK,SDK内配置有远程过程调用RPC接口,通过数据接收端接收用户设备上的API发送的数据处理请求,数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;控制数据接收端基于SDK的RPC接口请求SDK执行数据处理请求;将SDK执行数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;然后控制数据接收端从回环网卡的固定端口接收数据处理结果,并将数据处理结果发送至用户设备上的API。本申请实施例可以降低游戏业务的数据采集开销,同时不阻塞游戏进程的运行,减少玩家请求延时,提升游戏的数据采集效率。

请参阅图3,图3为本申请实施例提供的数据处理方法的第二流程示意图。本申请实施例提供了一种数据处理方法,应用于作为用户设备的电子设备,电子设备配置有应用程序编程接口API。可选的,所述电子设备可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、PC机、PDA等终端设备。该方法的具体流程可以如下:

步骤301,控制所述API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种。

步骤302,将所述数据处理请求发送至游戏主机设备。

在一些实施例中,当所述数据处理请求为数据采集请求时,所述将所述数据处理请求发送至游戏主机设备,包括:

将所述数据采集请求发送至所有游戏主机设备,所述数据采集请求包括待采集的目标数据对应的目标进程、待采集的目标实体以及所述目标实体的采集指标;

所述接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果,包括:

接收与所述数据采集请求相关的游戏进程所在的游戏主机设备响应所述数据处理请求后返回的数据处理结果,其中所述数据处理结果包含有被采集到的目标数据。

在一些实施例中,在所述将所述数据采集请求发送至所有游戏主机设备之前,还包括:

将所述数据采集请求发送至缓存设备,所述数据采集请求用于指示所述缓存设备查找缓存数据中是否存在与所述数据采集请求对应的目标数据;

接收所述缓存设备返回的查找结果,并根据所述查找结果确实是否将所述数据采集请求发送至所有游戏主机设备。

所述接收所述缓存设备返回的查找结果,并根据所述查找结果确实是否将所述数据采集请求发送至所有游戏主机设备,包括:

在一些实施例中,若接收到的所述缓存设备返回的查找结果为不存在所述目标数据的提示信息,则将所述数据采集请求发送至所有游戏主机设备;或者

若接收到的所述缓存设备返回的查找结果为所述目标数据,则禁止将所述数据采集请求发送至所有游戏主机设备。

在一些实施例中,当所述数据处理请求为新增采集指标请求时,所述将所述数据处理请求发送至游戏主机设备,包括:

将所述新增采集指标请求发送至所有游戏主机设备,所述新增采集指标请求包括新增采集指标以及待新增的实体类型;

所述接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果,包括:

接收所有游戏主机设备响应所述数据处理请求后返回的数据处理结果,其中所述数据处理结果包含有所述新增采集指标的生效信息。

步骤303,接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果。

其中,当所述数据处理请求为数据采集请求时,接收到的所述游戏主机设备返回的所述数据处理结果包含有被采集到的目标数据。

其中,当所述数据处理请求为新增采集指标请求时,接收到的所述游戏主机设备返回的所述数据处理结果包含有所述新增采集指标的生效信息

上述所有的技术方案,可以采用任意结合形成本申请的可选实施例,本实施例中没有详述的部分,可以参见其他实施例的相关描述,在此不再一一赘述。

本申请实施例提供的数据处理方法,应用于作为用户设备的电子设备,电子设备配置有应用程序编程接口API,通过控制所述API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;将所述数据处理请求发送至游戏主机设备;接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果。本申请实施例可以降低游戏业务的数据采集开销,同时不阻塞游戏进程的运行,减少玩家请求延时,提升游戏的数据采集效率。

为便于更好的实施本申请实施例的数据处理方法,本申请实施例还提供一种数据处理装置,应用于作为游戏主机设备的电子设备,所述电子设备配置有数据接收端和植入游戏进程的数据采集通信器SDK,所述SDK内配置有远程过程调用RPC接口。请参阅图4,该数据处理装置400可以包括第一接收模块401,控制模块402,第一发送模块403以及处理模块404。

其中,所述第一接收模块401,用于通过所述数据接收端接收用户设备上的应用程序编程接口API发送的数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;

所述控制模块402,用于控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求;

所述第一发送模块403,用于将所述SDK执行所述数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;

所述处理模块404,用于控制所述数据接收端

从所述回环网卡的固定端口接收所述数据处理结果,并将所述数据处理结果发送至所述用户设备上的API。

在一些实施例中,当所述数据处理请求为数据采集请求时,所述控制模块402,包括:

第一控制单元,用于控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据采集请求,所述数据采集请求包括待采集的目标数据对应的目标进程、待采集的目标实体以及所述目标实体的采集指标;

第二控制单元,用于控制所述SDK根据所述数据采集请求进行目标数据的采集,以得到包含有所述目标数据的数据处理结果。

在一些实施例中,所述控制模块402,还包括:

判断单元,用于判断所述电子设备内的所有游戏进程中是否存在与所述数据采集请求中的目标进程相关的目标游戏进程;

所述第一控制单元,用于若所述电子设备内的所有游戏进程中存在与所述数据采集请求中的目标进程相关的目标游戏进程,则控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据采集请求。

在一些实施例中,所述第一控制单元,用于从所述电子设备内的所有游戏进程中确定出与所述数据采集请求中的目标进程对应的目标游戏进程,并控制所述数据接收端基于所述目标游戏进程的SDK的RPC接口,请求所述目标游戏进程的SDK执行所述数据采集请求;

所述第二控制单元,用于控制所述目标游戏进程的SDK根据所述数据采集请求进行目标数据的采集,以得到所述目标游戏进程的SDK对应的包含有所述目标数据的数据处理结果。

在一些实施例中,所述处理模块404用于控制所述数据接收端从所述回环网卡的固定端口接收所述数据处理结果之后,通过所述数据接收端将所述目标数据发送至缓存设备进行缓存。

在一些实施例中,所述第一控制单元,还用于若所述电子设备内的所有游戏进程中不存在与所述数据采集请求中的目标进程相关的目标游戏进程,则禁止所述数据接收端响应所述数据采集请求。

在一些实施例中,当所述数据处理请求为新增采集指标请求时,所述控制模块402,包括:

第三控制单元,用于控制所述数据接收端基于所述电子设备内的所有游戏进程中每一游戏进程的SDK的RPC接口,请求每一游戏进程的SDK执行所述新增采集指标请求,所述新增采集指标请求包括新增采集指标以及待新增的实体类型;

处理单元,用于调用每一游戏进程的SDK中与所述新增采集指标请求对应的新增采集指标逻辑,以使所述新增采集指标生效,以得到每一游戏进程的SDK对应的包含有所述新增采集指标的生效信息的数据处理结果。

在一些实施例中,所述UDP接口为非阻塞UDP接口,所述第一发送模块403,用于将所述SDK执行所述数据处理请求的数据处理结果,通过非阻塞UDP接口发送至回环网卡的固定端口。

上述所有的技术方案,可以采用任意结合形成本申请的可选实施例,在此不再一一赘述。

本申请实施例提供的数据处理装置400,通过第一接收模块401基于所述数据接收端接收用户设备上的应用程序编程接口API发送的数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;控制模块402控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求;第一发送模块403将所述SDK执行所述数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;处理模块404控制所述数据接收端从所述回环网卡的固定端口接收所述数据处理结果,并将所述数据处理结果发送至所述用户设备上的API。本申请实施例可以降低游戏业务的数据采集开销,同时不阻塞游戏进程的运行,减少玩家请求延时,提升游戏的数据采集效率。

本申请实施例还提供一种数据处理装置,应用于作为用户设备的电子设备,所述电子设备配置有应用程序编程接口API。请参阅图5,该数据处理装置500可以包括生成模块501,第二发送模块502,以及第二接收模块503。

其中,所述生成模块501,用于控制所述API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;

所述第二发送模块502,用于将所述数据处理请求发送至游戏主机设备;

所述第二接收模块503,用于接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果。

当所述数据处理请求为数据采集请求时,所述将所述数据处理请求发送至游戏主机设备,包括:

将所述数据采集请求发送至所有游戏主机设备,所述数据采集请求包括待采集的目标数据对应的目标进程、待采集的目标实体以及所述目标实体的采集指标;

所述接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果,包括:

接收与所述数据采集请求相关的游戏进程所在的游戏主机设备响应所述数据处理请求后返回的数据处理结果,其中所述数据处理结果包含有被采集到的目标数据。

在一些实施例中,所述第二发送模块502,用于将所述数据采集请求发送至所有游戏主机设备之前,还将所述数据采集请求发送至缓存设备,所述数据采集请求用于指示所述缓存设备查找缓存数据中是否存在与所述数据采集请求对应的目标数据;

所述第二接收模块503,还用于接收所述缓存设备返回的查找结果,并根据所述查找结果确实是否将所述数据采集请求发送至所有游戏主机设备。

在一些实施例中,所述第二接收模块503,还用于接收所述缓存设备返回的查找结果,并根据所述查找结果确实是否将所述数据采集请求发送至所有游戏主机设备,包括:

若接收到的所述缓存设备返回的查找结果为不存在所述目标数据的提示信息,则将所述数据采集请求发送至所有游戏主机设备;或者

若接收到的所述缓存设备返回的查找结果为所述目标数据,则禁止将所述数据采集请求发送至所有游戏主机设备。

在一些实施例中,当所述数据处理请求为新增采集指标请求时,所述第二发送模块502,用于将所述新增采集指标请求发送至所有游戏主机设备,所述新增采集指标请求包括新增采集指标以及待新增的实体类型;

所述第二接收模块503,用于接收所有游戏主机设备响应所述数据处理请求后返回的数据处理结果,其中所述数据处理结果包含有所述新增采集指标的生效信息。

上述所有的技术方案,可以采用任意结合形成本申请的可选实施例,在此不再一一赘述。

本申请实施例提供的数据处理装置500,通过所述生成模块501控制所述API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;所述第二发送模块502将所述数据处理请求发送至游戏主机设备;所述第二接收模块503接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果。本申请实施例可以降低游戏业务的数据采集开销,同时不阻塞游戏进程的运行,减少玩家请求延时,提升游戏的数据采集效率。

相应的,本申请实施例还提供一种电子设备,该电子设备可以为终端,该终端可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、个人计算机(Personal Computer,PC)、个人数字助理(Personal Digital Assistant,PDA)等终端设备。如图6所示,图6为本申请实施例提供的电子设备的结构示意图。该电子设备600包括有一个或者一个以上处理核心的处理器601、有一个或一个以上计算机可读存储介质的存储器602及存储在存储器602上并可在处理器上运行的计算机程序。其中,处理器601与存储器602电性连接。本领域技术人员可以理解,图中示出的电子设备结构并不构成对电子设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。

处理器601是电子设备600的控制中心,利用各种接口和线路连接整个电子设备600的各个部分,通过运行或加载存储在存储器602内的软件程序和/或模块,以及调用存储在存储器602内的数据,执行电子设备600的各种功能和处理数据,从而对电子设备600进行整体监控。

在本申请实施例中,电子设备600中的处理器601会按照如下的步骤,将一个或一个以上的应用程序的进程对应的指令加载到存储器602中,并由处理器601来运行存储在存储器602中的应用程序,从而实现各种功能:

通过所述数据接收端接收用户设备上的应用程序编程接口API发送的数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求;将所述SDK执行所述数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;控制所述数据接收端从所述回环网卡的固定端口接收所述数据处理结果,并将所述数据处理结果发送至所述用户设备上的API。

可选的,电子设备600中的处理器601还会按照如下的步骤,将一个或一个以上的应用程序的进程对应的指令加载到存储器602中,并由处理器601来运行存储在存储器602中的应用程序,从而实现各种功能:

控制所述API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;将所述数据处理请求发送至游戏主机设备;接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果。

以上各个操作的具体实施可参见前面的实施例,在此不再赘述。

可选的,如图6所示,电子设备600还包括:触控显示屏603、射频电路604、音频电路605、输入单元606以及电源607。其中,处理器601分别与触控显示屏603、射频电路604、音频电路605、输入单元606以及电源607电性连接。本领域技术人员可以理解,图6中示出的电子设备结构并不构成对电子设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。

触控显示屏603可用于显示图形用户界面以及接收用户作用于图形用户界面产生的操作指令。触控显示屏603可以包括显示面板和触控面板。其中,显示面板可用于显示由用户输入的信息或提供给用户的信息以及电子设备的各种图形用户接口,这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。可选的,可以采用液晶显示器(Liquid Crystal Display,LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板。触控面板可用于收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板上或在触控面板附近的操作),并生成相应的操作指令,且操作指令执行对应程序。可选的,触控面板可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测装置检测用户的触摸方位,并检测触摸操作带来的信号,将信号传送给触摸控制器;触摸控制器从触摸检测装置上接收触摸信息,并将它转换成触点坐标,再送给处理器601,并能接收处理器601发来的命令并加以执行。触控面板可覆盖显示面板,当触控面板检测到在其上或附近的触摸操作后,传送给处理器601以确定触摸事件的类型,随后处理器601根据触摸事件的类型在显示面板上提供相应的视觉输出。在本申请实施例中,可以将触控面板与显示面板集成到触控显示屏603而实现输入和输出功能。但是在某些实施例中,触控面板与触控面板可以作为两个独立的部件来实现输入和输出功能。即触控显示屏603也可以作为输入单元606的一部分实现输入功能。

射频电路604可用于收发射频信号,以通过无线通信与网络设备或其他电子设备建立无线通讯,与网络设备或其他电子设备之间收发信号。

音频电路605可以用于通过扬声器、传声器提供用户与电子设备之间的音频接口。音频电路605可将接收到的音频数据转换后的电信号,传输到扬声器,由扬声器转换为声音信号输出;另一方面,传声器将收集的声音信号转换为电信号,由音频电路605接收后转换为音频数据,再将音频数据输出处理器601处理后,经射频电路604以发送给比如另一电子设备,或者将音频数据输出至存储器602以便进一步处理。音频电路605还可能包括耳塞插孔,以提供外设耳机与电子设备的通信。

输入单元606可用于接收输入的数字、字符信息或用户特征信息(例如指纹、虹膜、面部信息等),以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

电源607用于给电子设备600的各个部件供电。可选的,电源607可以通过电源管理系统与处理器601逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源607还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管图6中未示出,电子设备600还可以包括摄像头、传感器、无线保真模块、蓝牙模块等,在此不再赘述。

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

本领域普通技术人员可以理解,上述实施例的各种方法中的全部或部分步骤可以通过指令来完成,或通过指令控制相关的硬件来完成,该指令可以存储于一计算机可读存储介质中,并由处理器进行加载和执行。

为此,本申请实施例提供一种计算机可读存储介质,其中存储有多条计算机程序,该计算机程序能够被处理器进行加载,以执行本申请实施例所提供的任一种数据处理方法中的步骤。例如,该计算机程序可以执行如下步骤:

通过所述数据接收端接收用户设备上的应用程序编程接口API发送的数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;控制所述数据接收端基于所述SDK的RPC接口请求所述SDK执行所述数据处理请求;将所述SDK执行所述数据处理请求的数据处理结果,通过UDP接口发送至回环网卡的固定端口;控制所述数据接收端从所述回环网卡的固定端口接收所述数据处理结果,并将所述数据处理结果发送至所述用户设备上的API。

例如,该计算机程序还可以执行如下步骤:

控制所述API响应于用户输入的触控操作,生成数据处理请求,所述数据处理请求包括数据采集请求和新增采集指标请求中的至少一种;将所述数据处理请求发送至游戏主机设备;接收所述游戏主机设备响应所述数据处理请求后返回的数据处理结果。

以上各个操作的具体实施可参见前面的实施例,在此不再赘述。

其中,该存储介质可以包括:只读存储器(Read Only Memory,ROM)、随机存取记忆体(Random Access Memory,RAM)、磁盘或光盘等。

由于存储介质中所存储的计算机程序,可以执行本申请实施例所提供的任一种数据处理方法中的步骤,因此,可以实现本申请实施例所提供的任一种数据处理方法所能实现的有益效果,详见前面的实施例,在此不再赘述。

以上对本申请实施例所提供的一种数据处理方法、存储介质及电子设备进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。

相关技术
  • 数据处理方法、装置、电子设备及存储介质
  • 一种数据处理方法、装置、电子设备和存储介质
技术分类

06120112873382