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

1.本公开涉及互联网和分布式服务技术领域，尤其涉及一种数据处理的方法、电子设备及存储介质。


背景技术：

2.随着互联网技术的广泛普及和用户数据的海量级增长,传统的服务架构不能满足海量用户发起的高并发请求，分布式服务架构应运而生。在分布式服务架构中，通常包括多个服务节点或多个服务集群，由同一个服务集群中的多个服务节点或者不同服务集群中的多个服务节点，以协同的方式对应用软件的任务处理(例如业务数据的处理、运维数据的处理等)进行支持。
3.然而，在接收到用户关于时效性很强(即，实时性要求较高)的服务项目的投诉请求时，例如为关于付费服务的投诉(比如充值账户未到账)，由于各个服务节点的日志数据进行同步时往往具有滞后性，无法实现投诉的及时处理和反馈，更无法进行条件筛选，使得投诉用户可能要等很长时间才能得到回复；如果采用人工客服在各个服务器的日志数据中轮询的方式，由于在分布式服务架构中，同一个任务的处理数据分散于各个服务节点，采用轮询的方式查找同一个任务的处理数据，既繁琐还容易出现遗漏，查找效率低下。


技术实现要素：

4.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开的实施例提供了一种数据处理的方法、电子设备及存储介质。
5.第一方面，本公开的实施例提供了一种数据处理的方法。上述方法包括：接收终端设备发送的投诉信息，上述投诉信息包括：用户标识和关于特定服务项目的投诉理由。根据上述投诉信息，在预先构建的操作日志数据库中查询：与上述用户标识和上述特定服务项目相关的候选操作日志。其中，上述操作日志数据库用于存储分布式的多个代理服务器在进行访问请求的接收和转发过程中的操作日志。根据上述候选操作日志，确定上述投诉理由是否成立，得到核实结果。根据上述核实结果，生成对应的投诉处理结果，并将上述投诉处理结果发送给上述终端设备。
6.第二方面，本公开的实施例提供了一种电子设备。上述电子设备包括：处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信。上述存储器用于存放至少一可执行指令，上述可执行指令使得上述处理器执行以下步骤：接收终端设备发送的投诉信息，上述投诉信息包括：用户标识和关于特定服务项目的投诉理由；根据上述投诉信息，在预先构建的操作日志数据库中查询：与上述用户标识和上述特定服务项目相关的候选操作日志；其中，上述操作日志数据库用于存储分布式的多个代理服务器在进行访问请求的接收和转发过程中的操作日志；根据上述候选操作日志，确定上述投诉理由是否成立，得到核实结果；以及根据上述核实结果，生成对应的投诉处理结果，并将上述投诉处理结果发送给上述终端设备。
7.根据本公开的实施例，上述方法或电子设备中，上述投诉理由包括：名义访问对象信息、特定服务项目下的名义操作信息和名义处理结果；上述候选操作日志包括：转发的访问请求信息。其中，上述根据上述候选操作日志，确定上述投诉理由是否成立，包括：根据上述访问请求信息，确定上述候选操作日志中是否存在与上述名义访问对象和上述名义操作匹配的目标操作日志；当确定上述候选操作日志中不存在上述目标操作日志时，确定上述投诉理由不成立。
8.根据本公开的实施例，上述方法或电子设备中，上述根据上述候选操作日志，确定上述投诉理由是否成立，还包括：当确定上述候选操作日志中存在上述目标操作日志时，校验上述目标操作日志对应的目标访问请求信息中，访问参数是否存在埋点配置错误；当校验得到上述目标访问请求信息中，特定访问参数存在埋点配置错误时，确定上述投诉理由成立，并生成上述特定访问参数存在埋点配置错误的提示信息。
9.根据本公开的实施例，上述方法或电子设备中，上述候选操作日志还包括：访问请求分发到的服务节点信息。其中，上述根据上述候选操作日志，确定上述投诉理由是否成立，还包括：当校验得到上述目标访问请求信息中，所有访问参数都不存在埋点配置错误时，根据上述目标操作日志对应的目标服务节点信息，从对应的目标服务节点获取关于上述目标访问请求的目标服务日志；根据上述目标服务日志，确定针对上述目标访问请求的实际处理结果与上述名义处理结果是否一致；当上述实际处理结果与上述名义处理结果一致时，确定上述投诉理由成立；当上述实际处理结果与上述名义处理结果不一致时，确定上述投诉理由不成立。
10.根据本公开的实施例，上述方法或电子设备中，上述校验上述目标操作日志对应的目标访问请求信息中，访问参数是否存在埋点配置错误，包括：校验上述目标访问请求信息中，对应上述特定服务项目的访问参数与后端的预定义参数是否一致；当对应上述特定服务项目的访问参数与预定义参数均一致时，确定所有访问参数都不存在埋点配置错误；当对应上述特定服务项目的访问参数中存在特定访问参数与预定义参数不一致时，确定上述特定访问参数存在埋点配置错误。
11.根据本公开的实施例，上述方法还包括：构建操作日志数据库。
12.根据本公开的实施例，上述电子设备中，上述可执行指令使得所述处理器还执行以下步骤：构建操作日志数据库。
13.其中，上述构建操作日志数据库，包括：定义用于与分布式的多个代理服务器进行操作日志的数据同步的目标数据接口，上述目标数据接口用于限定上述操作日志的上传地址；基于上述目标数据接口，接收并存储来自代理服务器上传的在访问请求接收和转发过程中的操作日志的数据。
14.根据本公开的实施例，同一个访问请求下，在多个代理服务器之间发生中转的访问请求所对应的操作日志中携带有冗余标识。
15.在一实施例中，上述构建操作日志数据库，还包括：基于上述目标数据接口，对待上传的、与上述冗余标识相关的冗余操作日志进行滤除。
16.在另一实施例中，上述构建操作日志数据库，还包括：在已经存储的操作日志的数据中，根据上述冗余标识，确定与上述冗余标识相关的冗余操作日志，并删除上述冗余操作日志。
17.在又一实施例中，上述构建操作日志数据库，还包括：基于上述目标数据接口，对待上传的、数据时效不满足预设的时效要求的操作日志的数据进行滤除；和/或，基于上述目标数据接口，对待上传的、数据时效要求等级小于预设标准的服务项目所对应的数据进行滤除。
18.在再一实施例中，上述构建构建操作日志数据库，还包括：在已经存储的操作日志的数据中，对数据时效不满足预设的时效要求的操作日志的数据进行滤除；和/或，在已经存储的操作日志的数据中，对数据时效要求等级小于预设标准的服务项目所对应的数据进行滤除。
19.根据本公开的实施例，上述访问请求中携带有预设埋点参数，上述预设埋点参数包括：软件版本号和渠道号。上述方法还包括：从预先构建的操作日志数据库中，获取上述软件版本号和上述渠道号相关的特定操作日志数据；根据上述特定操作日志数据，确定上述软件版本号和上述渠道号所对应的流量信息。
20.根据本公开的实施例，上述访问请求中携带有预设埋点参数，上述预设埋点参数包括：软件版本号和渠道号。上述电子设备中，上述可执行指令使得所述处理器还执行以下步骤：从预先构建的操作日志数据库中，获取上述软件版本号和上述渠道号相关的特定操作日志数据；根据上述特定操作日志数据，确定上述软件版本号和上述渠道号所对应的流量信息。
21.第三方面，本公开的实施例提供了一种计算机可读存储介质。上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时实现如上所述的数据处理的方法。
22.上述实施例中的一个或多个技术方案至少具有如下优点的部分或全部：
23.由于预先构建的操作日志数据库中存储有分布式的多个代理服务器在进行访问请求的接收和转发过程中的操作日志，在对投诉信息进行处理时，能够根据上述操作日志数据库中的操作日志来对投诉信息进行核实，从而得到实时的处理结果，能够实现对投诉信息的实时处理，有助于提升分布式服务架构的服务响应效率。
附图说明
24.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
25.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
26.图1示意性地示出了适用于本公开实施例的数据处理的方法的系统架构；
27.图2示意性地示出了根据本公开一实施例的数据处理的方法的流程图；
28.图3示意性地示出了根据本公开实施例的步骤s203的详细实施流程图；
29.图4示意性地示出了根据本公开另一实施例的数据处理的方法的流程图；
30.图5示意性地示出了根据本公开实施例的构建操作日志数据库的详细实施流程图；
31.图6示意性地示出了根据本公开实施例的对待上传数据进行滤除和对已有数据进
行删除的流程图；
32.图7示意性地示出了根据本公开实施例的数据处理的方法的时序图；
33.图8示意性地示出了根据本公开又一实施例的数据处理的方法的流程图；以及
34.图9示意性示出了本公开实施例提供的电子设备的结构框图。
具体实施方式
35.本公开的实施例提供了一种数据处理的方法、电子设备及存储介质，上述方法包括：接收终端设备发送的投诉信息，上述投诉信息包括：用户标识和关于特定服务项目的投诉理由。根据上述投诉信息，在预先构建的操作日志数据库中查询：与上述用户标识和上述特定服务项目相关的候选操作日志。其中，上述操作日志数据库用于存储分布式的多个代理服务器在进行访问请求的接收和转发过程中的操作日志。根据上述候选操作日志，确定上述投诉理由是否成立，得到核实结果。根据上述核实结果，生成对应的投诉处理结果，并将上述投诉处理结果发送给上述终端设备。
36.为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开的一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。
37.图1示意性地示出了适用于本公开实施例的数据处理的方法的系统架构。
38.参照图1所示，适用于本公开实施例的数据处理的方法的系统架构100包括：终端设备110，包含多个分布式的代理服务器的代理服务器集群120，多个代理服务器各自下属的多个服务集群。在图1中，以代理服务器集群120中的两个代理服务器121和122进行示例，相应的，代理服务器121下属的服务集群为第一服务集群130，代理服务器122下属的服务集群为第二服务集群140。
39.上述终端设备110可以是具有显示屏且支持网页浏览的各种类型的电子设备，诸如图1中示例的笔记本电脑111、平板电脑112、智能手机113、台式计算机114等。
40.上述代理服务器121、122可以是nginx代理服务器(一种高性能的http和反向代理服务器)或者其他类型的代理服务器。
41.第一服务集群130中包含多个服务节点，例如图1中示例的服务节点131、132、133、134、135和136；第二服务集群140包含多个服务节点，例如图1中示例的服务节点141、142、143、144、145和146，上述各个服务节点可以是提供服务的实体服务器，也可以是云服务器或者是联网的能够提供云计算服务的联网的终端设备。例如，上述各个服务节点可以是对用户利用终端设备110所浏览的应用界面或者网页提供服务支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的请求进行分析和处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备110。
42.上述终端设备110与上述代理服务器集群120中的各个代理服务器(例如为代理服务器121、122)之间、各个代理服务器与各自下属的服务集群(例如为第一服务集群130、第二服务集群140)之间均通过网络进行数据交互。
43.参照图1所示，以闪电形状来示意网络，网络为用于提供通信链路的介质，可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等。
44.终端设备110上可以安装有各种通讯客户端应用，诸如：电子书阅读类软件/应用、购物类应用、支付类应用、短视频应用、网页浏览器应用、搜索类应用、新闻客户端应用、即时通信工具、外卖类应用、社交平台软件等(仅为示例)。
45.在一应用场景中，用户通过操作终端设备110上的应用功能界面，产生访问请求，终端设备110将上述访问请求转发给代理服务器集群120中的一个代理服务器，例如为代理服务器121，则代理服务器121在接收到上述访问请求后，通过分析下属的第一服务集群130中各个服务节点131～136的负载量，确定将当前访问请求对应的流量所要分发到的服务节点，例如为服务节点131，以实现负载均衡。
46.上述访问请求可以是各种类型的请求，例如以用户操作电子书阅读app的场景为例，上述访问请求可以是账号登录请求、电子书购买请求、电子书服务(例如包月免费阅读服务)购买请求、电子书标记操作(例如为划线、收藏、转发等操作)请求等。
47.在分布式的服务架构中，各个代理服务器(例如图1示例的代理服务器121和122)将访问请求基于负载均衡转发至下属相应的服务节点，在各个服务节点中，会记录各自针对服务请求的处理过程和结果，并生成服务日志。然而，各个服务节点的服务日志进行数据同步时往往具有滞后性，例如，各个服务节点(例如为服务节点131～136)的服务日志一般不会实时向各自的代理服务器(对应为代理服务器121)同步，一般是同步上一天的服务日志数据。
48.在一些时效性要求很高的场景下，例如接收到用户对于付费服务这一服务项目的投诉(比如充值账户未到账)时，由于各个服务节点的日志数据进行同步时往往具有滞后性，无法实现投诉的及时处理和反馈，更无法进行条件筛选，使得投诉用户可能要等很长时间才能得到回复。如果采用人工客服在各个服务器的日志数据中轮询的方式，由于在分布式服务架构中，同一个任务的处理数据分散于各个服务节点，采用轮询的方式查找同一个任务的处理数据，既繁琐还容易出现遗漏，查找效率低下。
49.有鉴于此，参照图1所示，本公开实施例提供的系统架构100中还包括：用于处理投诉请求的服务端150，该服务端150中预先构建有操作日志数据库151。该操作日志数据库151存储有分布式的多个代理服务器(例如为代理服务器121和122)在进行访问请求的接收和转发过程中的操作日志。例如参照图1所示，代理服务器集群120中的代理服务器121和122将各自进行访问请求的接收和转发过程中的操作日志均实时同步至操作日志数据库151中。从而在服务端150对投诉信息进行处理时，能够基于上述操作日志数据库151中的操作日志来对投诉信息进行核实，从而得到实时的处理结果。
50.需要说明的是，本公开实施例所提供的数据处理的方法一般可以由上述系统框架100中的服务端150执行，或者其他能够与上述终端设备110通信、且对上述操作日志数据库151具有访问和创建权限的服务器或服务集群实施。
51.应该理解，图1中的终端设备、网络、代理服务器和服务节点的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络、代理服务器和服务节点。
52.尽管上述场景以电子阅读场景下的信息推荐作为示例，可以理解的是，本公开实施例提供的技术方案的应用场景不局限于电子阅读场景，可以拓展至任何需要进行实时数据处理的场景。
53.下面结合附图来对本公开的实施例进行详细介绍。
54.本公开的第一个示例性实施例提供了一种数据处理的方法。
55.图2示意性地示出了根据本公开一实施例的数据处理的方法的流程图。
56.参照图2所示，本公开实施例提供的数据处理的方法，包括以下步骤：s201、s202、s203和s204。上述步骤s201～s204可以由图1中示例的服务端150执行。
57.在步骤s201，接收终端设备发送的投诉信息，上述投诉信息包括：用户标识和关于特定服务项目的投诉理由。
58.示例性的，上述特定服务项目包括但不限于是：业务服务项目、运维服务项目、软件开发服务项目等。上述业务服务项目例如为充值业务。上述投诉理由可以是：已充值的账户未到账、无故扣款、享受服务与实际充值业务不符合等。
59.上述特定服务项目可以是终端设备上安装的应用软件附属的服务项目，例如终端设备上安装的为电子书阅读app，则上述特定服务项目可以是：在电子书阅读账号对应的账户充值、购买电子书、购买电子书服务(例如包月免费阅读服务)等。
60.下面以电子设备和客服主机分别作为步骤s201中的终端设备的两个示例。在一实施场景中，用户通过在一电子设备的安装有应用软件(例如为电子书阅读app)的客服界面上操作，以发起投诉请求。或者，在另一实施场景中，用户通过客服电话或者网络投诉等方式进行投诉，在对应的客服主机上接收到上述投诉请求。相应的，由电子设备或者客服主机(均对应于步骤s201中的终端设备)将上述投诉信息发送给用于处理投诉请求的服务端，例如为图1中示例的服务端150。则在上述服务端150中接收到上述终端设备发送的投诉信息。
61.上述投诉请求携带有投诉信息，上述投诉信息包括：用户标识和关于特定服务项目的投诉理由。用户标识例如为用户id、用户名字、用户账号等。
62.在一示例性实施例中，上述投诉信息包括：用户a(用户标识)，关于充值项目(特定服务项目)下的投诉理由，该投诉理由为：在电子书阅读app上的账户钱包中的充值项目下，于当天(投诉请求接收时对应的日期，例如为2021年8月29日)上午充值了100元，结果未到账。
63.在步骤s202，根据上述投诉信息，在预先构建的操作日志数据库中查询：与上述用户标识和上述特定服务项目相关的候选操作日志；其中，上述操作日志数据库用于存储分布式的多个代理服务器在进行访问请求的接收和转发过程中的操作日志。
64.参照图1所示，服务端150在接收到上述投诉信息之后，能够通过在操作日志数据库中查询与投诉信息相关的候选操作日志，具体而言，通过查询操作日志数据库，可以确定代理服务器所接收和转发的用户的历史访问请求中，关于用户a(用户标识)和充值项目(特定服务项目)相关的候选操作日志。
65.上述操作日志数据库中的操作日志包括：转发的访问请求信息和访问请求分发到的服务节点信息。在一实施例中，上述访问请求信息包括：url(统一资源定位符，也称网页地址，是互联网上标准的资源的地址。互联网上的每个文件都有一个唯一的url，它包含的信息指出文件的位置以及浏览器的处理方式)信息和后缀的埋点(用于用户信息统计)的访问参数。
66.示例性的，通过查询操作日志数据库，得到3条候选操作日志。对这3条候选操作日志进行解析，可以得到以下形式的候选操作日志1～3。候选操作日志1：{2021年3月5日转发一条充值请求，充值请求为：用户a对个人的账户钱包w
a
进行充值，充值金额为30元；代理服
务器121的ip地址：19
×
.163.
×
.
×
.
×
；发送到服务节点131}。候选操作日志2：{2021年6月1日转发一条充值请求，用户a对用户b的账户钱包w
b
进行充值，充值金额为100元；代理服务器122的ip地址：19
×
.168.
×
.
×
.
×
；发送到服务节点142}。候选操作日志3：{2021年8月29日转发一条充值请求，充值请求为：用户a对个人的账户钱包w
a
进行充值，充值金额为100元；代理服务器121的ip地址：19
×
.163.
×
.
×
.
×
；发送到服务节点135}。
67.在步骤s203，根据上述候选操作日志，确定上述投诉理由是否成立，得到核实结果。
68.参照图1所示，服务端150可以根据上述候选操作日志1～3，来确定上述投诉理由是否成立，得到核实结果。在一实施例中，根据上述候选操作日志1～3确定上述投诉理由成立，得到对应的核实结果；或者，在另一实施例中，根据上述候选操作日志1～3确定上述投诉理由不成立，得到对应的核实结果。
69.在步骤s204，根据上述核实结果，生成对应的投诉处理结果，并将上述投诉处理结果发送给上述终端设备。
70.在核实结果为投诉理由成立的情况下，生成的对应的投诉处理结果例如为：投诉请求已经受理，并在用户a的电子书阅读app上的账户钱包w
a
中已经成功充值100元。在核实结果为投诉理由不成立的情况下，生成的对应的投诉处理结果例如为：经核查投诉理由不成立，并告知用户请勿虚假投诉。
71.基于上述步骤s201～s204，由于预先构建的操作日志数据库中存储有分布式的多个代理服务器在进行访问请求的接收和转发过程中的操作日志，在对投诉信息进行处理时，能够根据上述操作日志数据库中的操作日志来对投诉信息进行核实，从而得到实时的处理结果，能够实现对投诉信息的实时处理，有助于提升分布式服务架构的服务响应效率。在应用至付费项目的投诉或查询场景中，能够显著提高分布式服务系统架构中账户日志的查询效率，能在用户发生账户充值问题而投诉时进行快速响应。
72.图3示意性地示出了根据本公开实施例的步骤s203的详细实施流程图。
73.根据本公开的实施例，上述投诉理由包括：名义访问对象信息、特定服务项目下的名义操作信息和名义处理结果。上述候选操作日志包括：转发的访问请求信息和访问请求分发到的服务节点信息。其中，对于服务端而言，接收到的用户的投诉理由属于未经核验的信息，因此将用户在投诉时声称的访问对象信息描述为名义访问对象信息，将用户在投诉时声称的操作信息描述为名义操作信息；将用户在投诉时声称的处理结果描述为名义处理结果。
74.示例性的，名义访问对象信息例如为：电子书阅读app，电子书阅读app上的某本书、电子书阅读app上的某个账户钱包等。特定服务项目下的名义操作信息例如为：在充值项目下，充值
××
元；在购买项目下，购买了某本书等。名义处理结果例如为：充值未到账、购买未生效、电子书阅读app宣称的服务时长与享受到的服务时长不一致等。
75.参照图3所示，根据上述候选操作日志，确定上述投诉理由是否成立，包括以下步骤：s301、s302b。在此基础上，还可以进一步包括以下步骤：s302a和s303a；进一步的，还可以包括以下步骤：s303b、s304b、s305a和s305b。
76.在步骤s301，根据上述访问请求信息，确定上述候选操作日志中是否存在与上述名义访问对象和上述名义操作匹配的目标操作日志。
77.在一实施例中，根据上述访问请求信息，确定上述候选操作日志中是否存在与上述名义访问对象和上述名义操作匹配的目标操作日志，包括：对上述访问请求信息进行解析，得到解析信息，上述解析信息包括：实际访问对象信息和实际操作信息；将上述解析信息与上述名义访问对象信息和上述名义操作信息对应进行匹配；在存在与上述名义访问对象信息和上述名义操作信息均匹配的目标解析信息的情况下，将上述目标解析信息所对应的候选操作日志确定为目标操作日志；在遍历上述解析信息，不存在与上述名义访问对象信息和上述名义操作信息均匹配的解析信息的情况下，确定上述候选操作日志中不存在目标操作日志。
78.在步骤s302b，当确定上述候选操作日志中不存在上述目标操作日志时，确定上述投诉理由不成立。
79.如果候选操作日志中不存在与上述名义访问对象和上述名义操作匹配的目标操作日志，说明投诉理由中的用户行为并没有发生，即，名义访问对象和名义操作并没有发生，是不真实的，说明用户可能在说谎或者用户发起投诉请求时输入的投诉信息是错误的；这种情况下可以视为投诉理由不成立。
80.在步骤s302a，当确定上述候选操作日志中存在上述目标操作日志时，校验上述目标操作日志对应的目标访问请求信息中，访问参数是否存在埋点配置错误。
81.考虑到客户端的埋点参数配置是前端研发人员，例如php研发人员去做的，前端研发人员与后台(后端服务器一侧)研发人员属于两拨人，可能会导致前端配置的埋点参数与后端配置的埋点参数存在不一致的情况，导致应用系统无法执行预期的步骤。例如，后台业务人员定义了“account”是“账户”才会触发服务节点进行充值操作，然而php人员在埋点时将账户参数定义成了“wallet”或“accout”，这种情况下会存在参数不匹配的情况，导致无法触发服务节点的充值操作。
82.基于上述，在存在目标操作日志的情况下，说明投诉理由中的名义访问对象和名义操作确实发生了，对应的用户行为是真实的，需要进一步核实目标访问请求信息中的访问参数是否存在埋点配置错误，以确定应用软件的执行过程是否正常。
83.在步骤s303a，当校验得到上述目标访问请求信息中，特定访问参数存在埋点配置错误时，确定上述投诉理由成立，并生成上述特定访问参数存在埋点配置错误的提示信息。
84.在存在某个访问参数(特定访问参数)有埋点配置错误的情况下，说明应用软件的执行过程存在异常，则会导致上述名义处理结果(例如，充值未到账)的产生，因此这种情况下，视为投诉理由成立。同时在服务端还会生成提示信息，以在前端(例如为终端设备)或者后端(例如为应用服务器)提示对应的研发人员来及时更正埋点配置错误。
85.在一实施例中，校验上述目标操作日志对应的目标访问请求信息中，访问参数是否存在埋点配置错误，包括：校验上述目标访问请求信息中，对应上述特定服务项目的访问参数与后端的预定义参数是否一致；当对应上述特定服务项目的访问参数与预定义参数均一致时，确定所有访问参数都不存在埋点配置错误；当对应上特定服务项目的访问参数中存在特定访问参数与预定义参数不一致时，确定上述特定访问参数存在埋点配置错误。
86.上述特定服务项目预先在后端预定义有对应的参数，将其描述为预定义参数；对应于上述特定服务项目的预定义参数可以是一个或多个，相应的，访问参数的个数也可以是一个或多个。示例性的，特定服务项目为充值项目，对应于上述特定服务项目的预定义的
参数为：“account”，在实际的目标访问请求信息中，对应上述充值项目的访问参数为：“wallet”。则存在访问参数“wallet”与预定义参数“account”不一致的情况，由此可以确定特定访问参数“wallet”存在埋点配置错误。具体埋点配置错误的原因可能是前端或后端所导致的，因此可以通过生成上述特定访问参数存在埋点配置错误的提示信息，来提示前端或后端研发人员及时更正埋点配置错误。
87.在步骤s303b，当校验得到上述目标访问请求信息中，所有访问参数都不存在埋点配置错误时，根据上述目标操作日志对应的目标服务节点信息，从对应的目标服务节点获取关于上述目标访问请求的目标服务日志。
88.在具体实施时，参照图1所示，服务端150(执行主体的一种示例)根据目标操作日志对应的目标服务节点信息，可以确定用于转发的目标代理服务器的ip地址信息和目标服务节点的相关信息(例如端口信息)；从而该服务端150可以通过与目标代理服务器通信，通过目标代理服务器获取/查询目标服务节点关于目标访问请求的服务日志，直接找到特定的服务节点来拉取服务日志，而无需在多个服务节点之间轮询。
89.在步骤s304b，根据上述目标服务日志，确定针对上述目标访问请求的实际处理结果与上述名义处理结果是否一致。
90.服务端150可以根据上述目标服务日志得到实际处理结果，并通过对比可以确定实际处理结果与名义处理结果是否一致。
91.在步骤s305a，当上述实际处理结果与上述名义处理结果一致时，确定上述投诉理由成立。
92.在步骤s305b，当上述实际处理结果与上述名义处理结果不一致时，确定上述投诉理由不成立。
93.基于上述各个实施例，采用了逐层递进的判断逻辑，先根据操作日志数据库中是否存在与投诉理由中的名义行为对应的目标操作日志来确定名义行为是否真实；在名义行为真实的前提下，进一步确定应用软件的执行过程是否正常；在应用软件的执行过程正常的情况下，基于操作日志中的服务节点信息来获取对应的服务日志，从而得到实际处理结果，再根据实际处理结果与名义处理结果进行比对，来确定投诉理由中的名义处理结果是否真实，在投诉理由中的名义行为和名义处理结果都真实的情况下，认定投诉理由成立。
94.图4示意性地示出了根据本公开另一实施例的数据处理的方法的流程图。
95.本公开实施例提供的数据处理的方法除了包括上述步骤s201～s204之外，还包括以下步骤s401，构建操作日志数据库，为了简化示意，在图4中仅示意了步骤s401和s202。
96.可以理解的是，上述步骤s401在步骤s201和s202之前执行，即，在接收投诉请求所对应的投诉信息之前，预先执行构建操作日志数据库的步骤。需要说明的是，构建操作日志数据库的步骤s401只需要执行一次即可，后续可以直接调用该操作日志数据库，无需每次处理投诉请求时都对操作日志数据库构建一遍；另外，上述操作日志数据库中的数据是根据代理服务器上传的数据来实时更新的。
97.图5示意性地示出了根据本公开实施例的构建操作日志数据库的详细实施流程图。
98.参照图5所示，上述步骤s401中，构建操作日志数据库，包括以下步骤：s501和s502。
99.在步骤s501，定义用于与分布式的多个代理服务器进行操作日志的数据同步的目标数据接口，上述目标数据接口用于限定上述操作日志的上传地址。
100.在步骤s502，基于上述目标数据接口，接收并存储来自代理服务器上传的在访问请求接收和转发过程中的操作日志的数据。
101.参照图1所示，步骤s501和步骤s502在服务端150执行。本实施例中，上传的操作日志进行存储后，便形成了操作日志数据库中的数据。对应在代理服务器121、122一侧，执行以下步骤：在进行访问请求的接收和转发过程中，基于转发的访问请求信息和转发到的服务节点信息，生成对应的操作日志；基于上传地址(对应于上述步骤s501中的目标数据接口)，将上述操作日志同步存储于上述上传地址所对应的存储空间中，以在服务端得到操作日志数据库。
102.为了减小操作日志数据库中的数据容量负担，保证实现较高性能的服务，本公开的实施例中还对待上传数据进行过滤，或者对已有数据进行滤除。
103.在对已有数据进行滤除或者对待上传数据进行过滤时，还发现以下技术问题：(1)在实现同一个处理任务的协同处理时，可能会存在流量在多个代理服务器之间的转发，参照图1中虚线闪电符号(闪电符号示意的为网络)所示，这种情况下，对应同一个访问请求，进行流量转发的多个代理服务器会在操作日志数据库中对应存储多个操作日志，例如，用户的访问请求req1对应的流量转发路径为：终端设备
→
代理服务器121
→
代理服务器122
→
服务节点143，那么在代理服务器121会将该访问请求req1对应的转发日志1发送给服务端150的操作日志数据库151中进行存储；同时代理服务器122也会将该访问请求req1对应的转发日志2发送给服务端150的操作日志数据库151中进行存储；实际上转发日志1和转发日志2均为同一个流量路径，这就导致在操作日志数据库151中产生了数据冗余。
104.根据本公开的实施例，同一个访问请求下，在多个代理服务器之间发生中转的访问请求所对应的操作日志中携带有冗余标识。
105.在代理服务器121、122一侧，在一种实施例中，基于转发的访问请求信息和转发到的服务节点信息，生成对应的操作日志，包括：根据上述访问请求信息，确定接收到的当前访问请求的直接来源为终端设备还是代理服务器；如果当前访问请求的直接来源为代理服务器，则在生成当前访问请求所对应的操作日志时加上冗余标识。或者，在另一种实施例中，基于转发的访问请求信息和转发到的服务节点信息，生成对应的操作日志，包括：根据上述访问请求信息，确定将当前访问请求发送到的直接后端为代理服务器还是服务节点；如果将当前访问请求发送到的直接后端为代理服务器，则在当前访问请求的地址转向(url转发，是通过服务器的特殊设置，将访问当前域名的用户引导到指定的另一个网络地址)中加入冗余标识。
106.图6示意性地示出了根据本公开实施例的对待上传数据进行滤除和对已有数据进行删除的流程图。
107.基于上述，本公开的实施例中，在服务端150一侧，上述构建操作日志数据库的步骤s401除了包括上述步骤s501和s502之外，还包括s601或s602，为了简化示意，图6中仅示意了步骤s601和s602。
108.在步骤s601，在上述目标数据接口，基于第一预设条件，对待上传数据进行滤除。
109.上述第一预设条件包括以下条件中的至少一种：在上述冗余标识相关的操作日志
中，同一个访问请求对应的冗余的操作日志不允许上传；数据时效满足预设的时效要求的操作日志的数据允许上传，否则，不允许上传；数据时效要求等级高于预设标准的服务项目对应的数据允许上传，否则，不允许上传。
110.在步骤s602，基于第二预设条件，对已存储的数据进行删除。
111.上述第二预设条件包括以下条件中的至少一种：在上述冗余标识相关的操作日志中，将同一个访问请求对应的冗余的操作日志进行删除；将数据时效超过预设周期的数据进行删除；将数据时效要求等级小于预设标准的服务项目对应的数据进行删除。
112.本实施例中，进行上传限制或已存储数据的滤除之后，存储的操作日志的数据构成了操作日志数据库。
113.以上预设条件的实施过程示例性如下。
114.在一实施例中，上述构建操作日志数据库，除了包括步骤s501和s502之外，还包括：基于上述目标数据接口，对待上传的、与上述冗余标识相关的冗余操作日志进行滤除。
115.在另一实施例中，上述构建操作日志数据库，除了包括步骤s501和s502之外，还包括：在已经存储的操作日志的数据中，根据上述冗余标识，确定与上述冗余标识相关的冗余操作日志，并删除上述冗余操作日志。
116.通过采用前面描述的两个实施例中的其中一个，来对冗余操作日志进行剔除，使得操作日志数据库中，同一个访问请求只对应一个操作日志，不存在冗余数据，节省容量的同时还避免同一个访问请求下产生多条记录，确保数据处理的可靠性。
117.在又一实施例中，上述构建操作日志数据库，除了包括步骤s501和s502之外，还包括：基于上述目标数据接口，对待上传的、数据时效不满足预设的时效要求的操作日志的数据进行滤除；和/或，基于上述目标数据接口，对待上传的、数据时效要求等级小于预设标准的服务项目所对应的数据进行滤除。
118.在再一实施例中，上述构建构建操作日志数据库，除了包括步骤s501和s502之外，还包括：在已经存储的操作日志的数据中，对数据时效不满足预设的时效要求的操作日志的数据进行滤除；和/或，在已经存储的操作日志的数据中，对数据时效要求等级小于预设标准的服务项目所对应的数据进行滤除。
119.以上描述的两个实施例中，采用其中的一个来对时效性进行筛选，对时效性要求不高的数据限制上传或进行已有数据的删除，节省操作日志数据库中的存储占用内存，以确保数据处理有足够的空间资源。
120.由于客户投诉的时效性一般较强，所以在操作日志数据库中可以仅维护特定时段的日志信息，例如，将数据时效超过一个月的操作日志进行滤除，可以有效保障操作日志数据库中数据所占用的容量不会太大。通过上传条件限制，仅上传具有较强处理时效的业务项目(例如账户项目)，可以更加缩减操作日志数据库中日志数据的容量。此外，通过设置对冗余日志的限制上传或者在常规上传的情况下，对冗余操作日志进行删除，有效保证操作日志数据库中存储的为单一请求下的操作日志，节省容量的同时还避免同一个访问请求在不同服务集群(即，流量回环)下产生的多条记录同时备份到操作日志数据库的情况，确保数据处理的可靠性。
121.图7示意性地示出了根据本公开实施例的数据处理的方法的时序图。
122.在图7中，包含操作日志数据库的服务端可以是图1中示例的服务端150，以nginx
代理服务器作为代理服务器的一个示例，以客服主机作为终端设备的一个示例。
123.参照图7所示，nginx代理服务器在进行访问请求的接收和转发过程中，基于转发的访问请求信息和转发到的服务节点信息，生成对应的操作日志；并基于服务端的上传地址(对应于服务端中用于构建操作日志数据库的目标数据接口)，将上述操作日志同步存储于该上传地址所对应的存储空间中，从而在服务端得到操作日志数据库，参照图7中的步骤s701所示。该操作日志数据库根据代理服务器nginx上传的数据来实时更新。
124.在客服主机接收到用户的投诉请求时，会根据上述投诉请求确定对应的投诉信息，并将上述投诉信息发送给服务端，对应在服务端接收到上述投诉信息。参照图7中的步骤s711所示，上述投诉信息包括：用户a(用户标识)和关于充值项目(特定服务项目)的投诉理由。
125.服务端在接收到上述投诉信息的情况下，根据上述投诉信息，在预先构建的操作日志数据库中查询：与上述用户标识和上述特定服务项目相关的候选操作日志；然后，根据上述候选操作日志确定上述投诉理由是否成立。
126.具体实施过程中，参照图7中的步骤s712所示，服务端确定操作日志数据库中是否存在目标操作日志，以确定投诉理由中的用户访问行为是否真实。
127.其中，上述投诉理由包括：名义访问对象信息、特定服务项目下的名义操作信息和名义处理结果。上述候选操作日志包括：转发的访问请求信息和访问请求分发到的服务节点信息。确定操作日志数据库中是否存在目标操作日志的方法可以是：先在操作日志数据库中查询：与上述用户标识和上述特定服务项目相关的候选操作日志；然后根据访问请求信息，确定上述候选操作日志中是否存在与上述名义访问对象和上述名义操作匹配的目标操作日志。
128.参照图7所示，在不存在目标操作日志的情况下，执行步骤s713b，确定投诉理由不成立，并将投诉理由不成立对应的投诉处理结果反馈给客服主机。投诉理由不成立对应的投诉处理结果例如为：经核查投诉理由不成立，并告知用户请勿虚假投诉。
129.参照图7所示，在存在目标操作日志的情况下，执行步骤s713a，确定访问参数是否存在埋点配置错误。上述访问参数为目标操作日志对应的目标访问请求信息中，对应于上述充值项目的埋点参数。
130.参照图7所示，在访问参数存在埋点配置错误的情况下，执行步骤s714a，确定投诉理由成立，并将投诉理由成立对应的投诉处理结果反馈给客服主机。
131.参照图7所示，在访问参数不存在埋点配置错误的情况下，执行步骤s714b，根据上述目标操作日志对应的目标服务节点信息，从对应的目标服务节点获取关于上述目标访问请求的目标服务日志。
132.接着，执行步骤s715，根据目标服务日志，来确定实际处理结果与名义处理结果是否一致，进而确定投诉理由是否成立，并根据投诉理由是否成立生成对应的投诉处理结果，投诉处理结果反馈给客服主机。
133.由此，通过基于投诉信息和操作日志数据库中的操作日志，对投诉理由进行核实，例如依次对投诉理由中的名义行为的真实性、应用软件的执行过程是否正常逐步进行核实，且在上述两个核实结果均无误的情况下，进一步基于目标操作日志能够直接定位至目标服务节点来拉取服务日志，而无需在多个服务节点之间轮询，能够显著提高分布式服务
系统架构中账户日志的查询效率，并在用户发生账户充值问题而投诉时进行快速响应。
134.图8示意性地示出了根据本公开又一实施例的数据处理的方法的流程图。
135.根据本公开的实施例，上述访问请求中携带有预设埋点参数，上述预设埋点参数包括：软件版本号和渠道号。
136.基于上述各个实施例，本公开实施例提供的数据处理的方法还可以进一步包括以下步骤：s801和s802，为了简化示意，图8中仅示意了步骤s801和s802，可以理解的是，上述步骤s801和s802可以与上述步骤s201～s204并列实施或者先后实施，步骤s801和s802的执行时机可以是：在用户对应用软件进行操作的过程中，产生访问请求所对应的流量的情况下，执行步骤s801和s802。
137.在步骤s801，从预先构建的操作日志数据库中，获取上述软件版本号和上述渠道号相关的特定操作日志数据。
138.在步骤s802，根据上述特定操作日志数据，确定上述软件版本号和上述渠道号所对应的流量信息。
139.上述步骤s801～s802的实施场景例如为：通过让前端研发人员，例如为php研发人员，在前端埋点时除了访问参数之外，还添加更多类型的参数信息，例如软件版本号和渠道号。这样，参照图1所示，终端设备110(例如客户端)在发出访问请求时，可以在url的后缀中加上相应的版本号和渠道号，并能在代理服务器121、122的操作日志中留存。通过服务端150查询上述操作日志数据库，便可以实时、直观地分析出对应软件版本号和不同渠道号下的流量情况。
140.本公开的实施例提供的上述技术方案可以全部或部分操作以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本公开的实施例实施例的电子设备中的一些或者全部部件的一些或者全部功能。本公开的实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。实现本公开的实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
141.本公开的第二个示例性实施例提供了一种电子设备。
142.图9示意性示出了本公开实施例提供的电子设备的结构框图。
143.参照图9所示，本公开实施例提供的电子设备900包括处理器901、通信接口902、存储器903和通信总线904，其中，处理器901、通信接口902和存储器903通过通信总线904完成相互间的通信；存储器903，用于存放至少一可执行指令；处理器901，用于执行存储器上所存放的可执行指令时，实现如上所述的数据处理的方法中的各个步骤。
144.具体而言，上述可执行指令使得上述处理器执行以下步骤：接收终端设备发送的投诉信息，上述投诉信息包括：用户标识和关于特定服务项目的投诉理由；根据上述投诉信息，在预先构建的操作日志数据库中查询：与上述用户标识和上述特定服务项目相关的候选操作日志；其中，上述操作日志数据库用于存储分布式的多个代理服务器在进行访问请求的接收和转发过程中的操作日志；根据上述候选操作日志，确定上述投诉理由是否成立，得到核实结果；以及根据上述核实结果，生成对应的投诉处理结果，并将上述投诉处理结果
发送给上述终端设备。上述各个步骤的详细实施过程以及可以进一步执行的各个步骤可以参照第一实施例的描述，这里不再赘述。
145.根据本公开的实施例，上述电子设备900可以是：对终端设备上安装的应用软件的投诉请求提供服务支持的服务端，参照图1示例的系统框架100中的服务端150，或者其他能够与上述终端设备110通信、且对上述操作日志数据库151具有访问和创建权限的服务器或服务集群实施。在一示例性场景中，上述应用软件例如为以下软件中的一种或多种：电子阅读类软件、短视频软件、搜索软件、外卖软件等。
146.上述存储器903可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。存储器903具有用于执行上述方法中的任何方法步骤的程序代码的存储空间。例如，用于程序代码的存储空间可以包括分别用于实现上面的方法中的各个步骤的各个程序代码。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，光盘(cd)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为便携式或者固定存储单元。该存储单元可以具有与上述电子设备中的存储器903类似布置的存储段或者存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括用于执行根据本公开的实施例的方法步骤的程序，即可以由例如诸如901之类的处理器读取的代码，这些代码当由电子设备运行时，导致该电子设备执行上面所描述的方法中的各个步骤。
147.本公开的第三个示例性实施例还提供了一种计算机可读存储介质。上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时实现如上所述的数据处理的方法。
148.该计算机可读存储介质可以是上述实施例中描述的设备/装置中所包含的；也可以是单独存在，而未装配入该设备/装置中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
149.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
150.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
151.以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开
将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。