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

技术领域

本申请涉及大数据及云技术领域，具体而言，本申请涉及一种是数据处理方法、装置、电子设备及存储介质。

背景技术

随着科学技术的飞速发展，人们的生活需求也在不断的提高，对于企业而言，利用相应的信息技术以及互联网技术为客户提供更好的服务，一直是客户关系管理服务中重要关注的问题。

目前，对于一些企业而言，尤其是一些大企业，客户人群的数量级是巨大的，有些能够达到千万级别，为了更好的服务客户，企业通常也会配置大量的客户服务人员，由不同的服务人员对相应的客户提供服务。但是随着各个企业的客户及服务人员数量的不断增加，如何为各个企业提供更加优化的服务性能，以便于企业更完善其客户管理、服务能力，仍是需要不断改进的技术问题之一。

发明内容

本申请的目的旨在提供一种能够为用户端提供更好的服务性能的数据处理方法、装置、电子设备及存储介质。为了实现上述目的，本申请实施例提供的技术方案如下：

一方面，本申请实施例提供了一种数据处理方法，该方法包括：

响应于第一用户端接收的任务创建操作，发起任务创建请求，任务创建请求包括任务指示信息，任务指示信息用于生成对应于至少一个第二用户端的待处理任务，待处理任务用于通知第二用户端对第二用户端对应的至少一个目标用户端进行业务处理；

其中，第二用户端为第一用户端所管理的用户端，且第二用户端可以管理目标用户端；

响应于针对任务创建请求的处理结果查看操作，显示任务创建请求对应的处理结果，处理结果包括各第二用户端对于其所对应的各目标用户端的业务处理状态。

另一方面，本申请实施例提供了一种数据处理装置，该装置包括：

数据收发模块，用于响应于第一用户端接收的任务创建操作，发起任务创建请求，任务创建请求包括任务指示信息，任务指示信息用于生成对应于至少一个第二用户端的待处理任务，待处理任务用于通知第二用户端对第二用户端对应的至少一个目标用户端进行业务处理；其中，第二用户端为第一用户端所管理的用户端，且第二用户端可以管理目标用户端；

显示模块，用于响应于针对任务创建请求的处理结果查看操作，显示任务创建请求对应的处理结果，处理结果包括各第二用户端对于其所对应的各目标用户端的业务处理状态。

可选的，数据收发模块可以用于：

响应于第一用户端接收到的任务创建触发操作，显示任务创建界面；

通过任务创建界面接收任务指示信息的设置操作；

响应于任务创建确认操作，发起任务创建请求；任务创建操作包括任务创建触发操作、设置操作和任务创建确认操作。

可选的，显示模块可以用于：显示每个第二用户端所对应的各个目标用户端的标识信息、以及每个第二用户端对应于该第二用户端所对应的各目标用户端的业务处理状态。

可选的，任务创建请求包括用于创建消息群发任务的请求，处理结果还包括任务创建请求对应的群发消息。

可选的，数据收发模块可以用于：将任务创建请求发送至服务器，接收服务器发送的任务创建请求的请求成功响应信息；显示模块还用于显示该请求成功响应信息。

可选的，上述服务器包括请求接收模块、过载判断模块和请求处理模块，其中：请求接收模块，用于接收第一用户端发送的任务创建请求；过载判断模块，用于确定任务创建请求对应的服务资源占用情况，服务资源占用情况表征了任务创建请求所需的处理资源；确定服务资源占用情况是否满足服务过载判断条件；请求处理模块，用于在服务资源占用情况满足服务过载判断条件时，拒绝任务创建请求；若服务资源占用情况不满足服务过载判断条件，则根据任务指示信息，生成待处理任务，将待处理任务发送至各自对应的第二用户端，以及在接收到任一第二用户端发送的针对待处理任务的任务处理请求时，对该任一第二用户端对应的待处理任务进行处理；其中，在生成得到对应于预设数量的第二用户端的待处理任务时，向第一用户端发送请求成功响应信息，并根据任务指示信息继续生成对应于剩余用户端的待处理任务，剩余用户端为至少一个第二用户端中除预设数量的第二用户端之外的用户端；。

可选的，每个待处理任务对应至少一个子任务，该至少一个子任务是指对待处理任务所对应的至少一个目标用户端进行业务处理的任务，对于每个待处理任务，请求处理模块还用于执行以下至少一项：

根据待处理任务对应的任务类型，确定待处理任务对应的目标处理节点，通过目标处理节点对待处理任务对应的子任务进行处理，其中，不同的任务类型对应有相应的处理节点；

根据待处理任务对应的任务类型，确定待处理任务对应的目标消息队列，将待处理任务对应的子任务存储到目标消息队列中，采用目标消息队列对应的任务处理逻辑对待处理任务对应的子任务进行处理，其中，不同任务类型对应有相应的消息队列，不同的消息队列对应有各自的任务处理逻辑。

可选的，一个待处理任务对应的任务类型与该任务对应的数据处理量或者任务优先级中的至少一项相关。

可选的，任务指示信息包括第一指示信息和第二指示信息，第一指示信息用于确定至少一个第二用户端，第二指示信息用于确定任务创建请求所针对的目标用户端。

可选的，任务指示信息还包括任务信息，该任务信息用于确定待处理任务的任务内容。

可选的，请求处理模块在在接收到任一第二用户端发送的针对待处理任务的任务处理请求时，对该第二用户端对应的待处理任务进行处理时，可以用于：根据第三指示信息，确定出该第二用户端对应的至少一个目标用户端，第三指示信息是基于第二指示信息确定的；根据待处理任务，对确定出的各目标用户端进行相应的业务处理。

可选的，任务创建请求包括用于创建消息群发任务的请求，请求处理模块在根据待处理任务，对确定出的各目标用户端进行相应的业务处理时，可以用于：

基于任务创建请求对应的群发消息，生成对应于确定出的每个目标用户端的第一子任务，第一子任务为群发消息的消息发送任务；

执行各第一子任务，将群发消息分别发送至各目标用户端。

可选的，任务创建请求包括用于创建关联关系变更任务的请求，请求处理模块在根据待处理任务，对确定出的各目标用户端进行相应的业务处理，包括：对于任一第二用户端，将该第二用户端对应的各目标用户端变更为由该第二用户端管理的目标用户端。

可选的，第一用户端和第二用户端为第一应用的用户端，目标用户端为第二应用的用户端，服务器为第一应用的服务器，请求处理模块还可以用于：

对于上述任一第二用户端，生成对应于该第二用户端所对应的每个目标用户端的第二子任务，第二子任务为建立目标用户端与目标用户端对应的第二用户端的关联关系的任务；

通过第二应用的服务器执行各第二子任务，以在第二应用的服务器中建立各目标用户端与对应的第二用户端的关联关系。

可选的，对于任一目标用户端，上述请求处理模块还可以用于：

接收第二应用的服务器发送的该目标用户端的第二子任务的任务处理结果；在任务处理结果为任务处理成功、且该目标用户端已被变更为由该第二用户端管理的目标用户端时，解除该目标用户端与第三用户端的管理关系，第三用户端是在将该目标用户端变更为由第二用户端管理的目标用户端之前管理该目标用户端的用户端。

可选的，对于任一待处理任务或任一子任务，请求处理模块还可以用于：生成该任务的全局唯一标识；其中，第一电子设备在对该任务进行处理的过程中，基于全局唯一标识记录或更新该任务的当前处理状态，以使第二电子设备根据全局唯一标识和当前处理状态，对该任务进行相应的处理；

其中，第一电子设备和第二电子设备为以下任一项：

第一用户端；第二用户端；目标用户端；第一应用的服务器；第二应用的服务器。

可选的，过载判断模块可以用于：根据其他用户端的业务处理请求，确定当前的服务资源使用情况，其中，其他用户端为除第一用户端之外的用户端；根据服务资源占用情况和当前的服务资源使用情况，确定任务创建请求的判断结果，该判断结果为服务资源占用情况满足服务过载判断条件或不满足服务过载判断条件。

再一方面，本申请提供了一种电子设备，该电子设备包括存储器和处理器，其中，存储器中存储有计算机程序，处理器在运行该计算机程序时用于执行本申请任一可选实施例提供的数据处理方法。

另一方面，本申请提供了计算机可读存储介质，该存储介质中存储有计算机程序，该计算机程序在处理器中运行时，处理器用于执行本申请任一可选实施例提供的数据处理方法。

另一方面，本申请提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述本申请任一可选实施例中提供的数据处理方法。

本申请还提供了一种计算机产品，该计算机产品包括计算机程序，该计算机程序被处理器执行时实现本申请任一可选实施例中提供的方法。

本申请提供的技术方案带来的有益效果如下：

基于本申请实施例提供的方案，在需要对目标用户端进行业务处理时，第一用户端的操作者可以通过第一用户端进行任务创建操作，方便、快捷的发起针对其所管理的至少一个第二用户端的任务创建请求，从而可以向其所管理的第二用户端来分配相应的待处理任务，由其所管理的第二用户端对可以由第二用户端来管理的至少一个目标用户端进行相应的业务处理。通过该方案，操作者可以方便、快捷的创建所需的任务事项，可有效改善操作者的使用感知，更好的满足了实际应用需求。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例所适用的一种数据处理系统的结构示意图；

图2为本申请的一具体场景实施例中的一种数据处理方法的流程示意图；

图3为本申请一示例中提供的一种用户端的用户界面的示意图；

图4为本申请实施例提供的一种数据访问的原理示意图；

图5为本申请实施例提供的一种判断请求是否过载的原理示意图；

图6a为本申请一示例中提供的一种用户端的用户界面的示意图；

图6b和图6c为本申请一示例中提供的用户端的用户界面的示意图；

图6d和图6e为本申请另一示例中提供的用户端的用户界面的示意图；

图7为本申请实施例提供的一种数据处理方法的流程示意图；

图8a、图8b、图8c和图8d为本申请一示例中提供的用户端的用户界面的示意图；

图9a、图9b、图9c、图9d、图9e、图9f及图9g为本申请另一示例中提供的用户端的用户界面的示意图；

图10为本申请实施例提供的一种数据处理方法的流程示意图；

图11a为本申请一个示例中提供的一种发送消息的原理示意图；

图11b为本申请一示例中提供的一种按照任务类型进行信息处理的原理示意图；

图12为本申请实施例提供的一种消息群发请求的处理流程示意图；

图13为本申请实施例提供的一种数据处理装置的结构示意图；

图14为本申请实施例提供的一种服务器的结构示意图；

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

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本申请实施例提供的数据处理方法，可以应用于大数据(Big data) 的处理，可选的，可以基于云技术(Cloud technology)实现。可选的，本申请实施例中所涉及的数据计算可以采用云计算(Cloud computing)的方式。比如，生成待处理任务、生成子任务、对待处理任务进行处理等步骤所涉及的计算可以采用云计算实现。本申请实施例中的数据的存储可以采用云存储的方式，比如，各用户端的相关数据(如用户端的标识信息)可以是存储在云端。

大数据是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。

其中，云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。而云存储是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

为了更好的说明和理解本申请实施例提供的数据处理方法，首先对本申请实施例中会涉及到的一些相关技术进行介绍。

应用互通：指的是两个应用的用户之间能够添加好友，发送图文、多媒体等沟通行为。即不同的应用的用户端之间可以建立关联关系，并可以进行信息交互。

服务人员：企业可以设置部分员工为服务人员，这部分人员添加的指定应用的好友会被企业所管理。比如，第一应用可以是为企业提供服务的应用，服务人员可以使用第一应用添加使用第二应用的用户，服务人员通过该应用所添加的第二应用的用户为该企业的客户。

客户：即服务人员添加的好友，可以称之为客户。

客户库：指的是一个企业的服务人员添加的好友的集合。其中，客户库中可以存储有服务人员所添加的客户的相关信息，可以包括但不限于客户的标识信息(如客户在第二应用中的用户昵称、账号、联系方式等信息中的一项或多项)、标签(如在用户授权的情况下可以获知的客户的类型标签、所在区域的标签等等)。

群发：指的是企业管理员创建任务给服务人员，服务人员确认任务并给自己添加的好友中满足条件的客户群发消息的功能。

离职继承：指的是企业服务人员离职之后，企业管理员可以将他们添加的好友即客户，转移给企业内其他企业服务人员，继续保持沟通，从而避免客户流失。

本申请是为了提升数据处理性能，以更好的满足实际应用需求，而提供的一种数据处理方法。该方法可以用于客户服务场景中，在该客户场景中，存在着一些大企业有着数十万服务人员，服务着千万级别的客户的情况，目前的相关技术中，这种级别下会存在服务响应卡顿，稳定性较弱的问题，基于本申请实施例提供的该方法可以有效提升服务的可靠性和稳定性，能够有效改善用户的使用体验，更好的满足了企业的客户服务需求。

本申请实施例提供的该方法，可以由用户终端执行，也可以有服务器执行，还可以是由用户终端和服务器交互完成。其中，用户终端包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、可穿戴电子设备、AR/VR设备等。

下面首先结合一个具体的应用场景本申请提供的数据处理方法的一种可选的实施方式进行说明。

图1示出了本申请实施例所适用的一种数据处理系统的结构示意图，如图1所示，该数据处理系统可以包括第一应用的第一服务器10、第二应用的第二服务器20、第一应用的用户端(如图1中的用户端A、用户端 B1和用户端B2)、以及第二应用的用户端(示意性的，如图1的用户端 C1、……、用户端CN)，第一服务器10和第二服务器20可以通过网络通信连接，第一服务器10与其对应的各用户端通过网络连接，第二服务器20与其对应的各用户端通信连接。

可选的，本可选实施方式中，第一应用可以是为企业提供服务的应用程序，第二应用可以是为一般用户提供服务的应用程序。企业中的服务人员可以使用第一应用添加其所管理的客户。以图1中的企业服务人员1为例，该服务人员可以通过其在第一应用的用户端B1(即第二用户端)向第一服务器10发送关联关系建立请求，该请求中可以包括想要建立关联关系的客户的标识信息(如该客户在第二应用中的用户标识，如应用账号或昵称等)，第一服务器10接收到该请求之后，可以建立两者的关联关系，并将该客户添加到服务人员1对应的客户库中(也就是该客户成为了由该服务人员管理的客户)，为了使服务人员1和该客户可以通信，第一服务器10还会向第二服务器20发送相应的关联关系建立请求，第二服务器20建立两者的关联关系并存储在第二服务器20的数据库中。可以理解的是，服务人员和客户之间关联关系的建立也可以是由客户发起的。

其中，对于每个企业而言，第一应用的客户库11中可以包括该企业的每个服务人员各自对应的客户库，其中存储有与该服务人员具有关系的各个客户的相关信息。客户库中的数据的存储方式本申请实施例不做限定，如可以采用TableStore(表格存储)的方式进行存储，比如一个客户的相关信息对应一条客户记录，第一应用的用户端(可以是管理员的客户端或服务人员的客户端)或者其他具有访问权限的用户端可以通过客户库逻辑服务对数据进行访问。

该应用场景中，第一用户端是企业管理员在第一应用中的用户端(可以称为管理员用户端或管理员客户端)，企业管理员具有企业的服务人员的管理权限，即企业服务人员是有企业管理员管理的，如图1中所示意的用户端A，第二用户端可以是企业服务人员在第一应用中的用户端(可以称为服务人员用户端或服务人员客户端)，如图1中所示的服务人员1的用户端B1和服务人员2的用户端B2，目标用户端是客户在第二应用中的用户端(客户用户端)，如图1中所示的用户端C1至CN。

可以理解的是，图1中所示的各部分都只是示意性的，并不构成对本申请方案在实施实施过程中的限定，比如，在实际实施时，一个企业的服务人员的数量、以及企业的客户的数量通常都是大量的，图1中只是示意性的示出了几个。

下面结合图1中数据处理系统，以消息群发功能为例，对本申请实施例提供的数据处理方法进行说明。图2中示出了该场景下的一种数据处理方法的流程示意图，如图2中所示，该方法可以包括以下步骤：

步骤S11：第一服务器接收管理员用户端(图中所示的企业管理员) 发送的群发人数查询请求。

可选的，在实际实施时，企业管理员在发起任务创建请求(本实施例中的用于创建消息群发任务的请求，可以简称为消息群发请求或消息群发任务创建请求)之前，可以通过管理员用户端发起群发人数查询请求，具体的，企业管理员可以在其管理员用户端设置要发送群发消息的客户的条件，即用户端筛选条件，查询请求中包括该用户端筛选条件。

步骤S12：第一服务器向管理员用户端返回满足条件的人数。

第一服务器在接收到管理员用户端发送的群发人数查询请求之后，可以根据请求中的用户端筛选条件，从该管理员用户端对应的客户库中查询满足条件的记录，即查询满足条件的客户的数量。其中，用户端筛选条件具体包括哪些条件可以根据实际需求配置，比如，可以包括客户要满足的条件，还可以将条件设置为是是某个或某些指定服务人员(或者满足一定条件的服务人员)所对应的客户。其中，上述该管理员用户端对应的客户库指的是该管理员用户端所对应的所有指定服务人员的客户库，也就是该企业的客户库。第一服务器除了会将指定服务人员的标识信息(可以是用户端标识或其他唯一标识)与其对应的客户库关联存储外，还会建立每个企业的企业标识(可以是管理员用户端的标识信息或其他唯一标识)、该企业的服务人员的标识信息、以及管理员用户端的标识信息进行关联存储，基于这些关联关系，可以查询到每个服务人员对应的客户库，还可以查询到管理员用户端对应的各个客户库。

需要说明的是，在实际应用中，企业管理员除了作为管理员之外，企业管理员还可以作为一个服务人员，企业管理员也可以有由自己管理的客户。当然，在实际应用中，也可以不执行上述步骤S11和步骤S12中。

步骤S13：创建群发，即管理员用户端向第一服务器发送消息群发请求，也就是请求创建消息群发任务。

管理员用户端在接收到第一服务器返回的人数信息之后，可以根据实际需求，确定是否需要创建群发任务，如果确定创建，则可以通过管理员用户端进行相应的操作，向第一服务器发送消息群发请求。

可选的，该请求中可以包括服务人员用户端的指示信息(第一指示信息)、客户用户端的指示信息(第二指示信息)以及要群发的群发消息。

作为一个示例，图3中示出来一种企业管理员通过管理员用户端发起消息群发请求的用户界面示意图，如图3中所示，企业管理员可以在该界面设置上述第一指示信息和第二指示信息，具体的，可以通过点击“按条件筛选客户”选项触发第二指示信息的设置，选中该选项之后，可以通过触发“标签”控件进行第二指示信息的设置，也就是要发送群发信息的目标客户需要满足的条件，即用户端筛选条件，该用户端筛选条件和群发人数查询请求中的用户端筛选条件可以相同、也可以不同，其中，用户端筛选条件为客户的标签中带有“一般”这个标签的客户。可以通过点击“添加人”标签进行第一指示信息的设置，也就是消息群发任务所要发送给的服务人员用户端的条件设置，该示例中，图3中的a和b表示两个服务人员的标识信息，可以是服务人员的名称或昵称等。通过上述设置，企业管理员可以筛选企业的指定的跟进人(即服务人员)或者客户的标签。

当然，在实际应用中，上述用户端筛选条件也可以是默认配置条件，例如，如果企业管理员没有对该条件进行设置，该条件可以是预先配置的设置，也就是默认选项，如图3中所示的“全部客户”。用户确定服务人员的第一指示信息，可以是具体的服务人员的标识信息，也可以是预设条件，这样，该消息群发请求对应的各第二用户端即为该企业的服务人员中满足预设条件的所有服务人员的用户端。

步骤S14：判断是否过载，如果过载则拒绝请求，向管理员用户端返回请求失败的信息，若不过载，则进入步骤S15。

该步骤中，第一服务器在接收到任务创建请求后，还可以根据任务指示信息，确定该请求对应的服务资源占用情况，该资源占用情况表征了任务创建请求所需的处理资源(将在后文中展开说明)；第一服务器可以根据该服务资源占用情况确定是否要为该管理员用户端提供服务，即是否处理该任务创建请求。

在实际实施时，可以预配置有一些服务过载判断条件，如果当前接收到的任务创建请求满足该条件，也就是说，如果处理该请求，第一服务器很可能会出现服务过载的情形，有可能会出现崩溃的情况。此时，为了避免由于处理单个企业的请求导致对其他的企业造成影响，在判断处理该请求会造成服务过载时，会拒绝掉该企业的请求，从而保证全网其他企业的正常服务。可选的，第一服务器侧可以配置有资源计算器，通过资源计算器来判断是否过载，资源计数器每隔一段时间会重置，之前被拒绝访问的企业可以重新进行访问。

作为一个示例，图4示出了一种客户关系管理服务场景中，客户关系服务系统中的服务器为企业或者其他系统(图4中所示的后台其他系统)提供服务的原理示意图，图4中所示的用户可以是企业的管理员，也可以是企业的服务人员，客户联系逻辑服务是指服务器所能够提供的各项服务对应的事务处理逻辑，即如何处理各种请求的服务逻辑，是预配置好的。用户或者其他系统可以通过客户联系逻辑服务对服务器端的数据进行访问，比如，在具有相应权限的情况下，可以对客户库中(图中所示的客户联系存储)的数据进行访问。

图5示出了第一服务器判断用户端的任务创建请求是否过载的原理示意图，如图5中所示，第一服务器可以接收多个企业(图5中所示的企业1和企业2，可以是企业管理员、也可以是企业的客服人员)发送的业务处理请求(图5中所示的企业请求数据)，对于图5中所示的企业1，该企业的企业管理员可以通过其用户端向第一服务器(图5中所示的客户服务逻辑服务) 发送任务创建请求，第一服务器的资源计数器通过确定该请求的服务资源占用情况，判断该请求过载即满足服务过载判断条件，则进行过载保护，拒绝该请求，向用户端返回请求失败的响应。对于企业2，该企业的企业管理员或服务人员发送的数据处理请求的服务资源占用情况不满足过载判断条件，第一服务器执行该请求即请求成功，通过访问数据库中该企业对应的客户库进行相应的处理。

步骤S15：第一服务器根据消息群发请求，生成待处理任务(即消息群发任务)，在生成的待处理任务达到预设数量时，向管理员用户端返回请求成功响应信息，即进入步骤S16。

可以理解的是，对于一个企业服务人员而言，如果企业管理员发起的任务创建请求所对应的客户中只有该服务人员所服务的一个客户，对于该服务人员而言，消息群发任务则是对应于该一个客户的消息发送任务，即将群发消息发送给该客户。

步骤S16：第一服务器向管理员用户端发送任务创建成功的响应，即请求成功响应消息。

管理员用户端接收到该响应消息后可以显示给管理员，以告知管理员其想要创建的任务已经创建完成。

步骤S17：第一服务器继续生成剩余的待处理任务(即写入剩余数据，异步插入剩余任务)。

其中，步骤15对应于图2中所示的写入主表和首页数据、以及插入异步任务，写入主表和首页数据可以理解为第一服务器根据任务指示信息生成的一条条的待处理任务写入到列表中，插入异步任务则是将当前生成的部分待处理任务存储到消息队列1中，等待被发送到服务人员用户端。

目前的客户服务管理系统采用的通常都是同步设置，即用户在用户端界面进行操作，服务器根据用户的操作进行相应的处理，在处理完成后，向用户端返回处理结果。但是该方案在数据规模相对较小时，比如为万级别以下还可以有不错的用户体验，但是当用户数据规模达到较大估摸时 (十万以上之后)，用户端就很可能会出现卡顿、响应超时的问题，使用体验较差。比如，一个企业的数据，其服务人员可能是千万级别的，其客户也可能是千万级别的，当按照第一指示信息或第二指示信息进行筛选的时候，可能需要20分钟才能筛选出结果，管理员用户端需要等待很长的时间才能够得到相应的请求响应，用户使用感知很差。

为了提升使用感知，第一服务器可以使用异步处理方式进行任务创建，即生成待处理任务，也就是对应于所选定的各个服务人员用户端的消息群发任务。其中，本申请实施例提供的异步处理方式可以包括：第一服务器在接收到消息群发请求之后，进行消息群发任务的创建，在创建得到预设数量的第二用户端的待处理任务时，即可以向管理员用户端返回请求成功响应信息，即告知管理员消息群发请求的处理结果为成功，即任务创建完成，第一服务器再继续创建剩余的还未创建的消息群发任务(即写入剩余数据，异步插入剩余任务)，也就是说，先告知企业管理员创建任务成功，第一服务器在后台再异步进行任务创建。

其中，上述预设数量可以根据需求配置，本申请实施例不做限定。可选的，该预设数量可以根据管理员用户端的用户界面一次性所能够显示的任务创建结果信息的条数设置，比如，管理员客户端在接收到上述请求成功响应信息之后，可以查看具体的任务创建结果，任务创建结果可以是一条条的通知消息，比如，服务人员a的消息群发任务创建成功，服务人员b的消息群发任务。可以根据用于显示该任务创建结果的界面中所能够显示的通知消息的数量，确定上述预设数量，该预设数量可以不小于上述界面中所能够显示的通知消息的数量，由于第一服务器在发送请求成功响应信息时，仍在异步创建剩余的消息群发任务，管理员在查看结果时，可以在界面上看到界面所能够显示的最大数量的任务处理结果，由于第一服务器在异步不停的创建剩余的任务，管理员在其用户端还可以通过下拉或者滑动等方式不断从第一服务器拉取新的任务创建结果，对管理员而言，体验与同步创建无异，但是在数据规模较大时，可以大大提升使用感知。

作为一个示例，企业管理员选定的消息群发服务人员(即消息群发请求对应的服务人员)为千万级别的服务人员，第一服务器生成对应于这些服务人员的消息群发任务可能需要20分钟，如果采用同步处理方式，管理员用户端要在大约20分钟之后才能收到任务创建成功的响应。而基于本申请实施例的方案，假设上述预设数量为100条，则在生成对应于100 个服务人员的消息群发任务之后，管理员用户端即可以接收到任务创建成功的响应。

对于管理员而言，管理员可以通过管理员用户端查看其所发起的任务创建请求的处理结果，即可以在管理员用户端发起任务创建请求的处理结果查看操作，以查看该请求对应的处理结果。对于不同类型的任务创建请求，对应的处理结果可以不同，可以根据实际需求配置。

继续以消息群发请求为例，该请求对应的处理结果可以包括该请求对应的群发消息、每个服务人员用户端所对应的各个目标用户端(也就是客户用户端)的标识信息、以及每个服务人员用户端对应的每个目标用户端的业务处理结果中的一项或多项，也就是说，管理员用户端可以显示上述一项或多项信息，对于该一项或多项信息的具体显示形式本申请实施例不做限定。

作为一个示例，图6a中示出了管理员用户端的一个用户界面的示意图，如图6a中所示，该用户界面中显示有“全部群发记录”，其中，该“全部群发记录”可以是指该企业的所有创建过消息群发请求的服务人员(包括管理员和服务人员)所创建的群发请求的记录列表，也可以是管理员创建的所有消息群发请求的记录列表，该示例中的列表中包含两条记录，也就是共发起过两次消息群发请求，即群发消息为“消息1”的请求，和群发消息为“消息2”的请求，该界面中还可以显示每次请求所对应的服务人员的数量以及客户的数量，如“消息1”的请求所对应的服务人员(图中所示的成员)为2 名，对应的客户是这2个服务员所服务的30位客户。图6a中的“我”用于标识管理员，也就是标识当前的操作者，管理员可以在该用户界面触发针对任一消息群发请求的处理结果查看操作，如点击用户界面每条记录对应的区域，响应于该操作，则会在用户界面中显示该操作所针对的消息群发请求对应的处理结果。

作为一个示例，图6b和图6c中示出了消息群发请求对应的处理结果的用户界面的示意图。如图6b和图6c中所示，该示例中的群发请求对应的群发消息是“1122dev”，请求的创建时间为8月5日22点04分。该请求对应的服务人员的数量为18名，对应的客户为18名服务人员所服务的160名客户。图6b和图6c中所示的用户界面的左侧一列的标识信息，如标识b1@C1是客户的标识信息，也就是目标用户端的标识信息，其中， b1部分可以是客户的名称和客户在第二应用中的头像，C1部分可以是客户的标签信息，如客户所属的企业的标识信息或者其他标签。图6b和图 6c中所示的用户界面的右侧一列中的“a”和数字的组合表示服务人员的标识信息，也就是第二用户端的标识信息，如a1是标识信息为a1的服务人员，图中的“我”代表当前操作者，如管理员。两幅图中的每一行对应于一个子任务(也就是对应一个目标用户端)，一行表示一个服务人员和其所服务的一个客户、以及该客户对应的业务处理结果(即子任务的处理结果)，例如“b1@C1待a1发送”这一行，表示了a1是b1的服务人员，“待a1发送”表示a1还没有向b1发送群发消息，再例如，“b41 @C40通过我发送”这一行，表示了管理员是客户b41的服务人员，“通过我发送”表示管理员已经将群发消息发送给了客户b41且发送成功了。再例如，“b6@C1客户接收已达上限”这一行，表示了客户b6能够接收群发消息的数量已经达到上限，无法向该客户发送群发消息，也可以理解成发送失败。如图6b中所示，客户b6的服务人员是管理员，由于客户b6能够接收群发消息的数量已经达到上限，对应于客户b6的消息发送任务未执行成功，仍是“待我发送”状态。

可选的，在接收到管理员针对“1122dev”这一群发消息对应的消息群发请求的处理结果查看操作时，如在图6a中所示记录列表中点击了该群发消息(图6a中未示出该“1122dev”群发消息)对应的区域，响应于该操作，可以显示如图6b所示的用户界面，该用户界面显示有各个服务人员的标识信息、各个服务人员所服务的各个客户的标识信息、各服务人员对应于其所服务的每个客户的业务处理结果等信息。管理员可以通过滑动用户界面，如上滑或者下滑，来查看对应于不同客户的各项信息(即一行信息)，比如，可以对图6b的用户界面进行上滑动作，此时用户界面上显示的信息会发生变化，通过不断滑动操作，可以看到如图6c所示的用户界面的信息。

该示例中，图6c中所示的“分别发送给12位客户”表示已经向12 位客户发送了群发消息，“分别发送给12位客户”的下方区域显示的是已经发送了群发消息的各个客户对应的信息，如果在图6c的用户界面继续下滑，还可以看到12位客户中其他几位客户对应的信息。“分别发送给12位客户”的上方区域显示的是还没有发送群发消息的各个客户对应的消息。可以看出，该示例中，用户界面中先显示了未处理的待处理任务 (也就是还没有将群发消息向对应的客户端发送的任务)对应的处理结果，后显示了已经处理的待处理任务对应的处理结果。

图6b和图6c中该业务处理结果是群发消息的发送结果，即是否已经将群发消息发送给了客户、是否发送成功的提示信息、或者其他结果提示信息，如上述“b41@C40通过我发送”中的“通过我发送”表示对应于b41的业务处理结果为处理成功，“b6@C1客户接收已达上限”中的“客户接收已达上限”表示对应于b41的业务处理结果为未处理成功(未发送成功或还没发送)，“b1@C1待a1发送”中的“待a1发送”表示b1的业务处理结果为还没有发送。

在实际应用中，随着各客户对应的业务处理结果的变化，管理员用户端的上述显示请求处理结果的用户界面中所显示的客户端对应的业务处理结果的状态也会发生变化，比如，服务人员a5将群发消息发送给了其所服务的各个客户，上述用户界面中该服务人员所服务的各客户对应的业务处理结果也会发送变化，如由“待a5发送”更新为了“通过a5发送”。

步骤S18：发送待处理任务，即第一服务器将消息队列1中的待处理任务发送到对应的服务人员用户端。

可选的，第一服务器可以向满足条件的服务人员发送任务提醒信息，服务人员可以在其用户端进行任务查看操作，第一服务器响应于该操作可以将待处理任务发送到该用户端进行显示。

作为一个示例，图6d中示出了一种服务人员用户端的用户界面的示意图，第一服务器可以向各个满足条件的服务人员用户端发送任务提醒消息并显示在该界面，如图6d中所示的“管理员A分配给发送的企业消息”的提醒消息，对于消息群发任务而言，提醒消息中还可以包括群发消息，如图6d中所示的“今晚大促，8点直播间见[呲牙]”。通过该界面，服务人员可以知晓当前自己有哪些待处理任务需要进行处理。可选的，如图 6c中所示，服务人员可以在图6d中所示的界面中特定的操作区域(如图所示的区域61)进行点击操作(即任务查看操作)，之后，则可以显示待处理任务的详情，如图6e所示的任务详情界面，其中，该界面中可以显示有群发消息，还可以显示有该服务人员管理的客户中满足客户筛选条件的客户的提示信息，如可以包括但不限于客户的标识信息、满足条件的客户的数量等，如图中所示的“c1、c2等9人”是该示例中当前的服务人员的客户库中满足条件的各个客户的名称和满足条件的客户的数量。可选的，待处理任务或者待处理任务提醒信息可以采用卡片的形式显示给服务人员，服务人员确认群发任务卡片后，对应的客户就能够收到群发的消息。

步骤S19：服务人员用户端向第一服务器发送任务处理请求。

可选的，对于每个服务人员，其在接收到待处理任务时，可以在服务人员用户端的界面进行相应的操作，以触发对待处理任务进行处理。如图 6e中的示例，如果服务人员想要处理其接收到的消息群发任务(也就是待处理任务)，则可以通过触发“发送”控件，向第一服务器发送该任务的任务处理请求，该请求中可以包括群发消息和用户端筛选条件即客户筛选条件(可以是客户的标识信息，如名称、昵称)等信息。

步骤S20：第一服务器对任务处理请求进行处理，即生成待处理任务对应的子任务。

步骤S21：执行子任务，将群发消息发送到对应的客户即客户用户端。

具体的，第一服务器在接收到一个服务人员发送的任务处理请求时，会生成对应于该服务人员的满足条件的各个客户分别生成对应的子任务，也就是消息发送任务，第一服务器可以将生成的各个子任务存储到消息队列2中，第二应用的服务器即图2中所示的第二服务器可以从该队列中读取各个子任务并进行处理，也就是执行步骤S21，将群发消息发送至该服务人员的客户中满足客户筛选条件的各个客户，如图6d和图6e所示的示例中，第一服务器将上述“今晚大促，8点直播间见[呲牙]”的消息分别发送至c1.c2等9人的用户端。

将本申请实施例提供的方案应用到客户服务场景中，可以有效提高服务系统的可用性、稳定性、可靠性，改善用户体验。尤其是在大企业的服务人员、客户的规模较大时，比如服务的大企业有着数十万服务人员，服务着千万级别的客户时，采用该方案，可以有效避免出现卡顿、响应等待时间过长等问题。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图7中示出了本申请实施例提供的一种数据处理方法的流程示意图，该方法可以应用于客户管理服务类的应用程序中，可以由应用程序(第一应用)的第一用户端执行，如图7中所示，该方法可以包括以下步骤：

步骤S100：响应于第一用户端接收的任务创建操作，发起任务创建请求，该任务创建请求包括任务指示信息；

步骤S200：响应于针对任务创建请求的处理结果查看操作，显示任务创建请求对应的处理结果。

其中，任务指示信息用于生成对应于至少一个第二用户端的待处理任务，待处理任务用于通知第二用户端对第二用户端对应的至少一个目标用户端进行业务处理。

本申请实施例中，第二用户端为第一用户端所管理的用户端，且第二用户端可以管理目标用户端。例如，在客户关系管理的应用场景中，第一用户端可以是企业管理员的用户端，第二用户端可以是企业服务人员的用户端，目标用户端可以是该企业所服务的客户的用户端。上述第二用户端对应的至少一个目标用户端中，该至少一个目标用户端可以是指当前由该第二用户端所管理的用户端，也可以是指通过对至少一个目标用户端进行业务处理后，将该目标用户端变更为由该第二用户端管理的用户端。

可选的第一用户端和第二用户端为第一应用的用户端，目标用户端为第二应用的用户端。当然，第一用户端、第二用户端和目标用户端也可以是同一应用的用户端。

根据实际应用需求，第一用户端可以通过向第一应用的服务器发送任务创建请求，来请求服务器为至少一个第二用户端创建对应的待处理任务，服务器接收任务创建请求之后，则可以基于请求中所携带的任务指示信息为每个第二用户端生成对应的待处理任务，并将待处理任务发送给第二用户端，即将任务分配给第二用户端。

上述任务指示信息具体包含哪些内容，可以由第一用户端的使用者根据实际需求设定，任务创建请求的数据格式本申请实施例也不做限定，可以根据实际需求配置。可选的，任务指示信息可以包括第一指示信息和第二指示信息，其中，第一指示信息用于确定上述至少一个第二用户端，也就是第二用户端的确定条件，用于确定是为哪些用户端生成待处理任务。第二指示信息用于确定上述目标用户端，即要对哪些目标用户端进行业务处理。任务指示信息中还可以包括任务信息，任务信息用于确定待处理任务的具体内容，对于不同的应用需求，任务信息一般是不同的，比如，对于消息群发请求，任务信息至少要包含待群发的群发信息，服务器根据该群发消息为每个第二用户端生成包含该群发消息的待处理任务，也就是将消息群发任务。再比如，对于用于创建关联关系变更任务的请求，任务信息可以是变更任务的任务标识，根据该标识服务器可以知晓要生成的待处理任务是关联关系变更任务，也就是将至少一个目标用户端的管理者由一个用户端(后文中的第三用户端)变更为另一个用户端(即对应的第二用户端)。

本申请的可选实施例中，第一用户端发起任务创建请求之后，还可以包括：

显示任务创建请求的请求成功响应信息。

其中，该请求成功响应信息用于通知第一用户端上述任务创建请求所请求的事项已经处理成功，也就是待处理任务已创建，比如，对于消息群发任务，该响应消息用于通知第一用户端已经将消息群发任务通知/分配给第二用户端，即已经通知第二用户端有消息需要发送给其所服务的目标用户端。对于求成功响应信息的具体内容形式本申请实施例不做限定，如可以是“通知已发送”的信息。

其中，请求成功响应信息是第一用户端的服务器(如第一应用的服务器) 发送给第一用户端的，第一用户端在将该任务创建请求发送给服务器之后，服务器根据任务指示信息对该请求进行处理，并将对应的响应信息发送给第一用户端。当然，如果是处理失败，响应信息则会是请求失败的响应消息。

第一用户端在发起任务创建请求之后，还可以在第一用户端的用户界面查看该请求对应的处理结果，即发起针对该任务创建请求的处理结果查看操作，在接收到该操作后，可以在用户界面中显示该请求对应的处理结果。可选的，该处理结果可以包括该请求对应的待处理任务的处理状态(第二用户端对于其待处理任务的任务处理情况)，即各第二用户端对于其所对应的各目标用户端的业务处理状态，也就是第二用户端对其所对应的目标用户端的业务处理情况。

对于不同的任务创建请求，所显示的请求对应的处理结果的具体信息可以不同，具体如何显示、以及显示哪些内容可以根据实际需求配置，本申请实施例不做限定。可选的，任务创建请求可以包括但不限于上述用于创建消息群发任务的请求(消息群发请求)、用于创建关联关系变更任务的请求(可以称为用户端关联关系变更请求)等。

可选的，上述显示任务创建请求对应的处理结果，包括：

显示每个第二用户端所对应的各个目标用户端的标识信息、以及每个第二用户端对应于其所管理的各目标用户端的业务处理状态。

可选的，任务创建请求可以是用于创建消息群发任务的请求，上述任务创建请求度一应的处理结果还包括任务创建请求对应的群发消息。

对于消息群发请求和用户端关联关系变更请求的相关内容，将在后文中结合可选实施例再展开说明。

本申请的可选实施例中，上述响应于第一用户端接收的任务创建操作，发起任务创建请求，可以包括：

响应于第一用户端接收的任务创建触发操作，显示任务创建界面；

通过任务创建界面接收任务指示信息的设置操作；

响应于任务创建确认操作，发起任务创建请求，任务创建操作包括任务创建触发操作、所述设置操作和任务创建确认操作。

需要说明的是，通过任务创建界面获取任务指示信息的步骤可以是在一个用户界面中完成，也可以是在多个用户界面中完成，对于具体实现方式本申请实施例不做限定。

作为一个示例，图8a至图8d中示出了一种任务创建请求的生成过程示意图，该示例中，任务创建请求为消息群发请求，如图8a所示，第一用户端的操作者可以在该用户界面中触发任务创建操作，也就是触发生成任务创建请求的操作，比如，操作者可以点击上述“向企业的客户发送消息”所对应的区域，该点击操作则为任务创建触发操作，触发消息群发请求创建，当然也可以点击“向我的客户发消息”来触发向操作者所服务的客户发送消息的操作。如果操作者点击了上述“向企业的客户发送消息”所对应的区域，则是第一用户端可以响应于该操作，显示对应的任务创建界面，如图8b所示，操作者可以通过该界面来设置任务指示信息，如可以在区域81输入要群发消息，其中，群发消息可以多媒体信息，可以包括文本、图片、音频、视频等信息中的一项或多项，该示例中的群发消息的内容为“群发消息”。操作者可以通过点击区域82来进行筛选条件的设置，该筛选条件可以包括客户筛选条件和服务人员筛选条件中的至少一个。比如，点击区域82可以显示图8c所示的用户界面或者如图3所示的用户界面，操作者可以进行筛选条件的具体设置，在设置好之后可以点击图中所示的“确定”控件，返回上一用户界面。操作者在完成任务指示信息的设置，在确认需要进行任务创建之后，则可以基于任务指示信息生成对应的消息群发请求。在该示例中，操作者可以点击图8b中所示的“通知成员发送”的按钮来进行该确认操作，当然，也可以在点击该按钮后，先显示提示信息，提示该请求对应的待处理任务的相关信息(具体形式不做限定)，操作者对该提示信息进行的确认作为上述确认需要进行任务创建的操作。

之后，第一用户端可以将消息群发请求发送给第一应用的服务器，服务器对该请求进行处理，即生成对应于各个服务人员的消息群发任务，在满足一定条件时服务器会向第一用户端发送请求成功响应信息，第一用户端的用户界面中可以显示该响应信息，如图8d所示的“通知已发送”。需要说明的是，对于响应信息所在的用户界面是哪个界面本申请实施例不做限定。第一应用的服务器还会将生成的待处理任务进一步处理，即将群发消息发送给服务人员对应的客户即目标用户端。

作为另一个示例，图9a至图9g示出了用户端关联关系变更请求对应的管理员用户端的几个用户界面的示意图，下面结合这几个示意图对本申请实施例提供的数据处理方法再次进行说明。第一用户端的操作者可以通过图9a 所示的用户界面发起任务创建触发操作，该示例中，企业的服务人员中有6 名发生了离职，该6名服务人员服务了20位客户和105个客户群，可以理解的是，客户群是由一位或多位客户组成的群组，也就是说，本申请中的客户可以是一个个独立的客户，可以是一个群组中的各个客户。操作者可以点击图9a中所示的“去分配”控件发起任务创建触发操作，响应于该操作，用户界面中可以显示如图9b所示的信息。图9b的用户界面中现有各个离职人员的标识信息(即第三用户端的标识信息)以及离职服务人员所服务的客户的相关信息，如图中显示的标识信息为“霸霸”的离职服务人员所服务的客户包括2个独立的客户和3个客户群中的客户。操作者可以通过图9b选择一个或多个第三用户端，也就是选择想要重新分配的客户是哪些离职服务人员所服务的客户。该示例中，选择的至少一个目标用户端为标识信息为“霸霸”的离职服务人员所服务的客户，在用户界面的下方还显示了被选中的离职服务人员的标识信息(头像)。

操作者在完成选择之后并确认该选择(如点击图9b中所示的“确定(1)”按钮)后，可以显示如9c所示的用户界面。通过该界面操作者可以设置第一指示信息，将待目标用户端(即客户)重新配给至哪些新的服务人员。如操作者可以通过该界面发起新的服务人员(即第二用户端)的设置操作，如可以点击图9c中所示的“分配给…”的控件，响应于该点击操作，可以显示服务人员列表，该列表中包括在职的多个服务人员，操作者可以在该列表中选择新的服务人员，并在确认选择之后，显示用户端关联关系变更请求的请求成功响应信息，如图9d所示的用户界面，操作者在选择了新的服务人员之后，可以显示提示是否确定将要重新分配的客户分配给该服务人员提示信息(该示例中，M则是新的服务人员)，接收到确认操作(如点击了图9d中的“确认”控件)后，用户界面中可以显示图9e所示的“分配完成”的信息，该信息为该示例中的请求成功响应信息，操作者可以点击其中的“我知道了”的控件，关闭该用户界面。

在获取到请求成功响应信息，操作者还可以查看该变更请求对应的处理结果，可选的，操作者可以通过点击图9a中所示的“分配记录”控件，触发显示所有历史分配记录，也就是所有已发起的变更请求对应的处理结果，图 9f中示出了一种历史分配记录的用户界面的示意图，图中显示了每次变更请求的发起时间、每个变更请求对应的第三用户端的标识信息(如“霸霸”、“成员D”、“成员A”及各自对应的头像)、以及第三用户端对应的客户的相关信息，也就是被重新分配的第三用户端的相关信息。操作者还可以选择该列表中的任一历史分配记录，查看该分配记录对应的处理结果，即关联关系并更请求对应的处理结果，比如，点击图9f中“霸霸”对应的分配记录，可以显示图9g所示的用户界面，由图中可以看出，该界面中显示此次分配记录对应的各个目标用户端的标识信息，即此次分配的2个客户和3个客户群的标识信息，还包括第二用户端的标识信息即新的服务人员M，“待M接收”表示新的服务人员还没有对关联关系变更任务进行处理，也就是还没有接受成为上述2个客户和3个客户群的新的服务人员。如果服务人员M在其用户端进行了任务的处理，比如确认了接受成为这些客户新的服务人员，图9g中的业务处理状态会相应更新，如有“待M接受”变更为“已由M接收”。

本申请的可选实施例中，上述发起任务创建请求，包括：

将任务创建请求发送至服务器；

接收服务器发送的所述任务创建请求的请求成功响应信息并显示；其中，服务器可以执行如图10中所示的以下各个步骤：

步骤S110：接收第一用户端发送的任务创建请求，任务创建请求包括任务指示信息。

步骤S120：确定任务创建请求对应的服务资源占用情况，服务资源占用情况表征了任务创建请求所需的处理资源。

步骤S131：若服务资源占用情况满足服务过载判断条件，则拒绝任务创建请求。

步骤S132：若服务资源占用情况不满足服务过载判断条件，则根据任务指示信息，生成待处理任务。

其中，在生成得到对应于预设数量的第二用户端的待处理任务时，向第一用户端发送请求成功响应信息，并根据任务指示信息继续生成对应于剩余用户端的待处理任务，剩余用户端为至少一个第二用户端中除预设数量的第二用户端之外的用户端；

步骤S140：将待处理任务发送至各自对应的第二用户端。

可选的，在将待处理任务发送至对应的第二用户端之后，服务器还可以执行以下操作：

在接收到任一第二用户端发送的针对待处理任务的任务处理请求时，对该第二用户端对应的待处理任务进行处理。

其中，上述服务资源占用情况的具体表征形式可以根据实际需求配置，本申请实施例不做限定。可选的，服务资源占用情况可以通过以下一项或多项来表征：

上述至少一个第二用户端的数量；

请求生成的待处理任务所对应的目标用户端的数量；其中，目标用户端指的是待处理任务所针对的用户端，也就是在对待处理任务进行处理时，待处理任务会关联到的用户端。比如，对于消息群发任务，目标用户端指的是群发消息最终会被发送至的用户端；

处理该任务创建请求所需的第一应用的服务器的资源量、单位时间对应的网络流量或者单位时间内对服务器的数据库(如客户端)的读写频率中的至少一项。

也就是说，服务资源占用情况代表了第一应用的服务器处理该任务创建请求会消耗的服务器的性能，通过该服务资源占用情况可以判断处理该请求会不会造成服务器过载，影响到对其他用户端的服务。为了避免由于服务器消耗大量的资源服务器与一个用户端的请求而引发服务器崩溃，影响到其他用户端(如其他企业)的情况，本申请实施例的该方法中，采用了熔断保护机制，在对一个用户端的请求进行处理前，先判断该请求是否造成服务过载，即满足服务过载判断条件，则拒绝该用户端的请求，从而保证对其他用户端能够提供正常服务。

可选的，服务器即第一用户端对应的服务器还可以执行以下操作：

根据其他用户端的业务处理请求，确定当前的服务资源使用情况，其中，其他用户端为除第一用户端之外的用户端；

根据服务资源占用情况和当前的服务资源使用情况，确定任务创建请求的判断结果，该判断结果为服务资源占用情况满足服务过载判断条件或不满足服务过载判断条件。

其中，上述业务处理请求可以是第一用户端的服务器所能够提供的服务中任一服务对应的请求，包括但不限于任务创建请求，比如，还可以包括用于请求对用户端的相关信息(比如标签、联系方式等)进行修改的请求。在该方案中，服务器可以根据当前的实际服务情况即负载情况，来判断任务处理请求的服务资源占用情况是否满足过载判断条件，以更好的评估系统的当前服务情况，保证服务的可用性和稳定性。

其中，服务过载判断条件可以根据实际需求配置，服务过载判断条件和服务资源占用情况的内容可以是相互对应的，比如，该判断条件可以包括单位时间内网络流量超过预配置的最大限值，服务资源占用情况则可以该任务创建请求对应的单位时间内的网络流量，如果该请求对应的单位时间内的网络流量和服务器在服务的其他用户端的请求所对应的单位时间的网络流量之和超过上述最大限值，则该请求的服务资源占用情况满足服务过载判断条件。

在服务资源占用情况不满足服务过载判断条件时，第一用户端的服务器则可以根据任务指示信息，生成对应于各个第二客户端的待处理任务。其中，为了提升第一用户端的使用感知，本申请提供的该方法，在生成待处理任务时，采用了异步设计，即生成了部分第二用户端的待处理任务时，就可以向第一用户端返回任务创建成功的响应信息，第一服务器会根据任务信息，继续不断的创建剩余的待处理任务。

对于第一用户端的服务器将待处理任务发送至各自对应的第二用户端的方式，本申请实施例不做限定，可选的，可以是在至少一个待处理任务生成之后，就可以把已经生成的任务发送至对应的第二客户端，即任务的生成和发送可以同步进行，也可以是在所有的待处理任务生成之后再完成。在实际实施时，服务器在生成待处理任务之后，可以将生成的各个待处理任务存储到对应的消息队列中，根据预配的任务发送逻辑，将消息队列中的各个待处理任务分别发送至对应的第二用户端。

本申请实施例提供的数据处理方法，在接收到任务创建请求时，会通过确认该请求的服务资源占用情况来判断该请求是否会造成服务器过载，并根据判断结果确定是否处理该请求，避免了由于为一个用户端提供服务而对其他用户端的服务造成影响的问题，提升了服务的稳定性和可靠性。在对任务创建请求的处理过程中，通过采用异步处理的方式，避免了第一用户端的多长等待，有效改善了用户的使用感知。

本申请的可选实施例中，第一用户端对应的服务器接收第一用户端发送的任务创建请求可以包括：

接收第一用户端发送的用户端数量查询请求，该查询请求中可以包括第一指示信息或第二指示信息中的至少一项；

根据查询请求中携带的指示信息，确定各指示信息所对应的用户端数量，将该用户端数量发送至第一用户端；

接收第一用户端发送的任务创建请求，其中，该创建请求是响应于第一用户端接收到上述用户端数量之后所触发的任务创建确认操作生成的。

该可选方案中，第一用户端在向服务器发送任务处理请求之前，可以根据需求，查询其想要创建的待处理任务所对应的第二用户端的数量或者目标用户端的数量中的至少一项，基于该方案，用户可以提前知晓其想要创建的待处理任务所对应的用户规模，并可以进一步确定是否要请求创建待处理任务，或者是根据服务器端返回的用户端数量，确定是否要调整任务指示信息，如调整第一指示信息或第二指示信息中的至少一项，以实现对用户规模的控制。

本申请的可选实施例中，每个待处理任务对应至少一个子任务；对于每个待处理任务，第一应用的服务器还执行以下至少一项

根据待处理任务对应的任务类型，确定待处理任务对应的目标处理节点，通过目标处理节点对待处理任务对应的子任务进行处理，其中，不同的任务类型对应有相应的处理节点；

根据待处理任务对应的任务类型标识，确定待处理任务对应的目标消息队列，将待处理任务的子任务存储到目标消息队列中，采用目标消息队列对应的任务处理逻辑对待处理任务对应的子任务进行处理，其中，不同任务类型对应有相应的消息队列，不同的消息队列对应有各自的任务处理逻辑。

其中，至少一个子任务是指对待处理任务所对应的至少一个目标用户端进行业务处理的任务，比如，一个第二用户端的消息群发任务对应的目标用户端是50个客户(可以是独立的客户个人，也可以是客户群)，那么该群发任务对应的子任务则为50个，也就是需要向50个客户发送群发消息。

对于任务类型的具体划分方式本申请实施例不做限定，可选的，一个待处理任务对应的任务类型与该任务对应的数据处理量相关，也可以与任务的优先级有关。其中，数据处理量的具体表征方式本申请实施例不做限定，一个任务对应的数据处理量可以是该任务所对应的目标用户端的数量，也可以是处理该任务所需的服务器的资源。

由于不同类型的待处理任务的数据处理量(可以理解为待处理任务对应的子任务的数据量)或优先级不同，如果所有类型的任务都采用同样的处理节点或采用同一消息队列，那么就很可能会造成不同类型的任务之间的相互影响。比如，一个任务可能对应于千万级别的目标用户端(在客户关系管理应用场景中，可能是批量处理千万级别的客户，也可以是给千万级别的客户发送消息)，需要消耗大量的服务器资源，甚至可能会影响用户端的其他类型的操作。为了避免该情况，本申请的该可选方案中，在对待处理任务对应的子任务进行处理时，该待处理任务对应的任务类型，采用该任务类型对应的处理节点(即服务节点)进行处理，或者是将该待处理任务的各个子任务存储到该类型对应的目标消息队列中，以通过该类型对应的任务处理逻辑对各个子任务进行处理。

可选的，不同的任务类型可以采用不同的任务类型标识表示。比如，对于消息群发任务，如果第二用户端确认对该任务进行处理时，第二用户端会向服务器发送该任务对应的任务处理请求，该任务的任务处理请求中可以包括该任务对应的任务类型标识，比如，群发标识。再比如，对于用户关联关系变更请求，该变更请求中可以包括对应的任务类型标识，该标识可以作为该变更请求对应的每个待处理任务对应的任务类型标识。当然，待处理任务对应的任务类型也可以由第一应用的服务器基于预配置的判断策略来判断，比如，根据待处理任务对应的子任务的数量判断。

本申请提供的该可选方案，采用隔离设计，将不同类型的任务采用不同的处理方式，避免了不同类型的任务之间的相互影响。其中，隔离设计可以采用上述单独部署机器(即处理节点)或者单独部署消息队列的方式。

下面以客户服务场景中的消息群发任务为例，对该可选方案中提供的隔离设计方案进行说明，该例子中第一用户端和第二用户端为第一应用的用户端，目标用户端为第二应用的用户端，第一应用和第二应用可以互通，即可以相互发送消息。图11a示出了一种未采用隔离涉及的任务处理方式的原理示意图，图11a示出了一种采用隔离设计的任务处理方式的原理示意图。

如图11a中所示，图中的消息服务逻辑指的是第一应用或第二应用的服务器进行消息发送的处理逻辑。第一应用的用户端和第二应用的用户端之间的消息存储到图中所示的消息发送队列中，第一应用的用户端发送给第一应用的用户端的消息存储到第一应用的消息存储中，第二应用的用户端发送给第二应用的用户端的消息存储到第二应用的消息存储中。第一应用/第二应用的服务器从消息发送队列中读取发送给第一应用/第二应用的用户端的消息，并按照各自的消息服务逻辑将消息发送至对应的接收用户端。如果不按照任务的类型进行隔离设计，那么不论是消息群发任务，还是要发送给单个用户端的消息，都会被存储在消息发送队列中，并按照同样的消息服务逻辑进行处理。在客户联系服务中，一个任务可能是批量处理千万级别的客户，也有可能是给千万级别的客户发送消息，需要消耗大量的系统资源，如果不按照任务类型隔离处理，有大批量数据要处理的任务则很可能影响到其他用户。比如，第一应用的一个用户端需要向第二应用的千万级别的用户端发送群发消息，这些消息的发送会对单个用户端对单个用户端发送的消息产生很大影响，甚至可能会导致后者的消息很长时间才会被接收端接收到。

对于图11b中所示的示例，可以按照任务类型的不同，配置多个消息发送队列，如图中所示的队列1至队列4，每个队列对应一种任务类型，比如，队列1是用于存储用户正常的聊天消息的队列，队列4是用于存储群发消息的队列，比如，用户端a向用户端b发送一条信息，将该消息发送至用户端 b的任务则会存储到队列1中，如果用户端c需要向10万个用户端发送群发消息，则对应于这10万个用户端的消息发送任务则会存储到队列4中，通过隔离存储方式，减少了不同类型的任务处理时的相互影响。

可选的，在实施应用中，除了可以对待处理任务的具体子任务采用上述隔离处理方式之外，服务器在接收到任务创建请求时，也可以根据该请求的类型，确定该请求对应的目标服务节点或目标消息队列中的至少一项，以将后续生成的待处理任务通过该请求对应的目标服务器节点发送至对应的第二用户端，或者是将生成的待处理任务按照请求的类型存储到相应的消息队列中，以采用该对象对应的任务处理逻辑对该任务进行处理。

本申请的可选实施例中，上述任务指示信息包括第一指示信息和第二指示信息，第一指示信息用于确定至少一个第二用户端，第二指示信息用于确定各待处理任务的任务处理请求所针对的目标用户端。

任务指示信息还可以包括任务信息，该信息用于确定待处理任务的具体任务内容。

其中，第一指示信息是用于指示任务创建请求所针对的至少一个第二用户端，也就是待处理任务所要发送至的用户端，该指示信息的具体包含什么内容本申请实施例不做限定，如可以是各个第二用户端的标识信息，如第二用户端的用户名称或其他唯一标识，如图3所示的示例中的用户a和用户b 即为第一指示信息。

第二指示信息则是用于确定任务创建请求所针对的所有目标用户端的信息，该指示信息可以是用户端筛选条件，满足该条件的第二应用的用户端即为目标用户端，如图2所示的示例中的群发信息最终所发送至的客户的用户端，如图3中所示的服务人员a和服务人员b的客户库中带有“一般”标签的客户的用户端。对于消息群发请求，待处理任务为消息群发任务，该任务用于通知第二用户端进行消息群发；对于用户端关联关系变更请求，待处理任务为关联关系变更任务，用于通知第二用户端将至少一个目标用户端分配给了该第二用户端，即让至少一个目标用户端对应的客户成为该第二用户端管理的客户。

可选的，第一用户端的服务器在接收到任一第二用户端发送的针对待处理任务的任务处理请求时，对该第二用户端对应的待处理任务进行处理，可以包括：

根据第三指示信息，确定出该第二用户端对应的至少一个目标用户端，所述第三指示信息是基于所述第二指示信息确定的；

根据待处理任务，对确定出的各目标用户端进行相应的业务处理。

本申请的可选实施例中，对于消息群发请求，该请求中还包括待发送的群发消息，第一用户端的服务器在接收到任一第二用户端的任务处理请求之后，具体可以执行以下操作：

根据上述群发消息，生成对应于确定出的每个目标用户端的第一子任务，第一子任务为群发消息的消息发送任务；

执行各第一子任务，将群发消息分别发送至该确定出的各目标用户端。

可选的，在目标用户端为第二应用的用户端时，上述执行各第一子任务，将群发消息分别发送至该确定出的各目标用户端，包括：

通过第二应用的服务器执行各第一子任务，将群发消息分别发送至各目标用户端。

对于一个待处理任务而言，上述任务处理请求中包含的第三指示信息是用于确定该任务所对应的目标用户端的信息，可以是用户端筛选条件，也可以是目标用户端的标识信息(该标识信息可以是第一应用的服务器根据第二指示信息确定出的该任务对应的目标客户端)。如图3中对于服务人员a，其所对应的待处理任务对应的第三指示信息可以是带有“一般”标签的客户，该待处理任务对应的目标用户端则是服务人员a的客户库中带有“一般”标签的客户的用户端，第三指示信息也可以是各目标用户端的标识信息，第一应用的服务器根据第二指示信息可以确定出各个第二用户端所对应的目标用户端的标识信息，并可以将该标识信息携带在待处理任务中发送给各个第二用户端。

该可选方案中，待处理任务对应的目标用户端与第一用户端和第二用户端可以是不同应用的用户端。第一应用的服务器和第二服务器可以通信，第一应用的用户端和第二应用的用户端可以通过互相通信的两个应用的服务器进行信息交互。比如，在客户关系管理应用场景中，第一应用可以是服务于企业的应用，第二应用可以是服务于普通用户的应用(当然该应用也可以提供其他服务)，第一用户端和第二用户端可以是该企业的管理员的用户端和服务人员的用户端，目标用户端可以是该企业的客户在第二应用中的用户端。企业的管理员可以通过其用户端请求第一应用的服务器为各个服务人员创建待处理任务，而服务器人员在收到待处理任务之后，可以请求该服务器对该任务进行处理，如果该待处理任务是针对第二应用中的目标用户端的任务，第一服务器则可以与第二应用的服务器通信，以完成该任务的处理。基于该方案，实现了应用互通，使用不同应用的用户端之间可以实现沟通，更好的满足了实际应用需求。

在任务创建请求为消息群发请求时，第一应用的服务器可以根据群发消息以及待处理任务所对应的各个目标用户端，分别生成对应于每个目标用户端的消息发送任务，以通过第二应用的服务器将群发消息发送至各个目标用户端。可选的，第一应用的服务器可以将生成的每个消息发送任务存储到指定的消息队列中，如前文中的目标消息队列中，第二应用的服务器(或者是第二服务器的目标处理节点)可以从该目标消息队列中读取各个消息发送任务，将群发消息发送给目标用户端。

本申请的可选实施例中，任务创建请求包括用于创建关联关系变更任务的请求；第一用户端对应的服务器根据待处理任务，对确定出的各目标用户端进行相应的业务处理，具体可以包括：

对于上述任一第二用户端，将该第二用户端对应的各目标用户端变更为由该第二用户端管理的目标用户端，也就是建立该第二用户端与该第二用户端对应的各目标用户端的第一关联关系。

其中，在目标用户端为第二应用的用户端时，第一用户端对应的服务器还可以执行以下操作：

对于上述任一第二用户端，生成对应于每个目标用户端的第二子任务，第二子任务为建立目标用户端与目标用户端对应的第二用户端的关联关系的任务；

通过第二应用的服务器执行各第二子任务，建立各目标用户端与对应的第二用户端的第二关联关系。

其中，在该可选方案中，对于一个第二用户端，关联关系变更任务的任务处理请求也就是将至少一个目标用户端与第三用户端之间的关联关系变更为该至少一个目标用户端与该第二用户端的关联关系的请求，第一用户端的服务器在接收到第二用户端的该请求之后，则执行相应的操作，已将至少一个目标用户端的管理者进行变更。具体的，服务器可以根据用户端关联关系变更请求中的第三指示信息，确定出该任务处理请求对应的各个目标用户端，并建立任务处理请求对应的第二用户端与确定出的该第二用户端对应的各个目标用户端(也就是分配给该第二用户端的各个目标用户端)的关联关系。

在客户关系管理应用场景中，基于该方案，可以实现离职继承功能，具体的，在企业中有服务人员离职时，企业管理员可以在其管理员用户端选定该离职的服务人员所对应的各个客户(即该客户的用户端的标识信息)以及想要将这些客户转移给一个或多个其他服务人员(可以称为新的服务人员)，并向服务器发送用户端关联关系变更请求，服务器接收到该请求之后，则可以生成对应于上述新的服务人员的关联关系变更事项(即上述任务处理请求)，还会向新的服务人员和/或重新分配的客户发送相应的通知信息，如将关联关系变更任务分配给新的服务人员，向被分配的客户通知其服务人员发生了变更，从而可以让新的服务人员可以继续与客户保持沟通，避免客户流失。

另外，在目标用户端是第二应用的用户端时，为了保证建立关联关系的第二用户端和目标用户端之间能够交互，需要在第二应用的服务器端也建立两者之间的关联关系，这样，第二用户端就可以通过该第一应用的服务器和第二应用的服务器与目标客户端进行通信。

本申请的可选实施例中，对于任一目标用户端，对于任一目标用户端，第一应用的服务器还执行以下操作：

接收到第二应用的服务器发送的该目标用户端的第二子任务的任务处理结果；

在任务处理结果为任务处理成功、且该目标用户端已被变更为由该第二用户端管理的目标用户端时，解除该目标用户端与第三用户端的管理关系，第三用户端是在将该目标用户端变更为由第二用户端管理的目标用户端之前管理该目标用户端的用户端。

可以理解的是，第三用户端也是由第一用户端管理的用户端，是被重新分配的至少一个目标用户端之前的管理用户端。

由于关联关系变更任务是将与目标用户端有关联关系的管理用户端进行变更，为了保证关联关系变更完后，目标用户端对应的关联用户端是变更后的第二用户端，需要解除之前基于该目标用户端与第三用户端之间的关联关系，也就是将与目标用户端具有关联关系的第一应用的用户端由第三用户端变更为第二用户端，如将服务人员1的客户变更为服务人员2的客户，并接触服务人员1和该客户之间的关联关系。

本申请的可选实施例中，对于任一待处理任务或任一子任务，该方法还可以包括：

生成该任务的全局唯一标识；

第一电子设备在对该任务进行处理的过程中，基于全局唯一标识记录或更新该任务的当前处理状态，以使第二电子设备根据全局唯一标识和当前处理状态，对该任务进行相应的处理；

其中，第一电子设备和第二电子设备为以下任一项：

第一用户端；第二用户端；目标用户端；第一应用的服务器；第二应用的服务器。

在实际应用中，一项任务的创建及处理过程通常会涉及到很多个不同的处理环节(如待处理任务的异步创建、任务所涉及的内容的审核(比如审群发消息是否合规等)、将待处理任务发送给对应的第二用户端、将子任务发送给目标客户端、更新统计子任务的相关数据(如哪些子任务已经处理完成、已经处理成功的任务的数量等)，不同的环节通常会有不同的计算机设备执行，许多的操作流程有时也会非常地冗长，而在分布式系统中，失败是非常常见的。失败可能带来数据的不一致，丢失消息。所以，为了保证数据处理的可靠性，需要有相应的处理方式。本申请的该可选实施例中，对于每个待处理任务或者子任务(第一子任务或第二子任务)，通过为任务生成全局唯一标识，并在处理过程中记录以及更新任务的当前处理状态的方式，来保证任务执行的可靠性。

具体的，在每一个环节，对于每个任务，可以进行任务重试，比如，可以设置一个任务可以重试的最大次数，在该最大次数之内，如果一个任务处理失败，可以重试。但是任务重试就可能冬导致把一个任务重复做多次，而为了保证任务的幂等性，本申请的该方案中，引入了幂等性设计，其中，每个待处理任务或子任务(第一子任务或第二子任务)可以使用全局的ID(即全局唯一ID)进行排重，处理任务的电子设备可以通过记录任务的当前处理状态来是的该设备或会对该任务进行后续处理的其他电子设备能够根据全局唯一ID和当前处理状态来保证任务的幂等性，其中，任务的当前处理状态的具体记录形式本申请实施例不做限定，可选的，可以使用状态机与版本号进行更新等多种手段来实现。

作为一个示例，以第一应用的服务器将待处理任务发送至第二用户端为例，一个待处理任务具有全局唯一ID，服务器将该待处理任务向第二用户端发送之后，可以记录待处理任务的当前处理状态为已发送，记录重发次数为0，如果接收到了第二用户端返回的任务接收成功的响应，则可以将当前处理状态更新为已发送成功，如果设定时长内为接收到接收成功的响应，则可以重新发送，当前处理状态可以更新为重发，记录重复次数为1。这样，服务器可以根据每个待处理任务的全局唯一ID和当前处理状态确定任务的实时处理状态。此外，第二用户端可以同样执行上述操作，根据一个任务的全局唯一ID和当前处理状态保证任务的幂等性。

作为一个示例，图12中示出了一个消息群发任务的处理过程，需要经历异步创建任务、内容审核任务(图中所示的自动审核队列，审核群发消息是否合规等)、发送任务卡片任务(将消息群发任务发送给对应的服务人员的用户端)、发送消息给客户任务(即将群发消息发给目标用户端)，更新群发数据等多个异步任务。在每一个任务失败的时候，都可以进行任务重试，在每个任务的处理过程中，当前处理该任务的电子设备都会记录其所处理的每个待处理任务或子任务的当前处理状态，并将该状态与待处理任务或子任务的全局唯一标识建立关联，从而任何一个电子设备都可以根据全局唯一标识和该标识对应的处理状态，知晓该标识对应的任务的处理状态，保证了任务的幂等性。其中，一个全局唯一标识对应的处理状态可以有多个。

在实际应用中，为了进一步提升数据处理的可用性，还可以根据实际需求，在任务的处理过程中配置其他一些处理策略，比如还可以增加补偿事务和降级设计等多种柔性措施，以更好的为用户提供服务。基于本申请实施例提供的方案，可以很好的满足用户需求，尤其是在客户服务场景中，能够为具有百万员工，超过千万的客户的企业提供稳定的服务。

基于与本申请实施例提供的方法相同的原理，本申请实施例还提供了一种数据处理装置，如图13中所示，该数据处理装置100可以包括数据收发模块110和显示模块120，其中：

数据收发模块110，用于响应于第一用户端接收的任务创建操作，发起任务创建请求，任务创建请求包括任务指示信息，任务指示信息用于生成对应于至少一个第二用户端的待处理任务，待处理任务用于通知第二用户端对第二用户端对应的至少一个目标用户端进行业务处理；其中，第二用户端为第一用户端所管理的用户端，且第二用户端可以管理目标用户端；

显示模块120，用于响应于针对任务创建请求的处理结果查看操作，显示任务创建请求对应的处理结果，处理结果包括各第二用户端对于其所对应的各目标用户端的业务处理状态。

可选的，数据收发模块可以用于：

响应于第一用户端接收到的任务创建触发操作，显示任务创建界面；

通过任务创建界面接收任务指示信息的设置操作；

响应于任务创建确认操作，发起任务创建请求；任务创建操作包括任务创建触发操作、设置操作和任务创建确认操作。

可选的，显示模块可以用于：显示每个第二用户端所对应的各个目标用户端的标识信息、以及每个第二用户端对应于该第二用户端所对应的各目标用户端的业务处理状态。

可选的，任务创建请求包括用于创建消息群发任务的请求，处理结果还包括任务创建请求对应的群发消息。

可选的，数据收发模块可以用于：将任务创建请求发送至服务器，接收服务器发送的任务创建请求的请求成功响应信息；显示模块还用于显示该请求成功响应信息。

可选的，如图14中所示，上述服务器包括请求接收模块210、过载判断模块220和请求处理模块230，其中：请求接收模块，用于接收第一用户端发送的任务创建请求；过载判断模块，用于确定任务创建请求对应的服务资源占用情况，服务资源占用情况表征了任务创建请求所需的处理资源；确定服务资源占用情况是否满足服务过载判断条件；请求处理模块，用于在服务资源占用情况满足服务过载判断条件时，拒绝任务创建请求；若服务资源占用情况不满足服务过载判断条件，则根据任务指示信息，生成待处理任务，将待处理任务发送至各自对应的第二用户端，以及在接收到任一第二用户端发送的针对待处理任务的任务处理请求时，对该任一第二用户端对应的待处理任务进行处理；其中，在生成得到对应于预设数量的第二用户端的待处理任务时，向第一用户端发送请求成功响应信息，并根据任务指示信息继续生成对应于剩余用户端的待处理任务，剩余用户端为至少一个第二用户端中除预设数量的第二用户端之外的用户端；。

可选的，每个待处理任务对应至少一个子任务，该至少一个子任务是指对待处理任务所对应的至少一个目标用户端进行业务处理的任务，对于每个待处理任务，请求处理模块还用于执行以下至少一项：

根据待处理任务对应的任务类型，确定待处理任务对应的目标处理节点，通过目标处理节点对待处理任务对应的子任务进行处理，其中，不同的任务类型对应有相应的处理节点；

根据待处理任务对应的任务类型，确定待处理任务对应的目标消息队列，将待处理任务对应的子任务存储到目标消息队列中，采用目标消息队列对应的任务处理逻辑对待处理任务对应的子任务进行处理，其中，不同任务类型对应有相应的消息队列，不同的消息队列对应有各自的任务处理逻辑。

可选的，一个待处理任务对应的任务类型与该任务对应的数据处理量或者任务优先级中的至少一项相关。

可选的，任务指示信息包括第一指示信息和第二指示信息，第一指示信息用于确定至少一个第二用户端，第二指示信息用于确定任务创建请求所针对的目标用户端。

可选的，任务指示信息还包括任务信息，该任务信息用于确定待处理任务的任务内容。

可选的，请求处理模块在在接收到任一第二用户端发送的针对待处理任务的任务处理请求时，对该第二用户端对应的待处理任务进行处理时，可以用于：根据第三指示信息，确定出该第二用户端对应的至少一个目标用户端，第三指示信息是基于第二指示信息确定的；根据待处理任务，对确定出的各目标用户端进行相应的业务处理。

可选的，任务创建请求包括用于创建消息群发任务的请求，请求处理模块在根据待处理任务，对确定出的各目标用户端进行相应的业务处理时，可以用于：

基于任务创建请求对应的群发消息，生成对应于确定出的每个目标用户端的第一子任务，第一子任务为群发消息的消息发送任务；

执行各第一子任务，将群发消息分别发送至各目标用户端。

可选的，任务创建请求包括用于创建关联关系变更任务的请求，请求处理模块在根据待处理任务，对确定出的各目标用户端进行相应的业务处理，包括：对于任一第二用户端，将该第二用户端对应的各目标用户端变更为由该第二用户端管理的目标用户端。

可选的，第一用户端和第二用户端为第一应用的用户端，目标用户端为第二应用的用户端，服务器为第一应用的服务器，请求处理模块还可以用于：

对于上述任一第二用户端，生成对应于该第二用户端所对应的每个目标用户端的第二子任务，第二子任务为建立目标用户端与目标用户端对应的第二用户端的关联关系的任务；

通过第二应用的服务器执行各第二子任务，以在第二应用的服务器中建立各目标用户端与对应的第二用户端的关联关系。

可选的，对于任一目标用户端，上述请求处理模块还可以用于：

接收第二应用的服务器发送的该目标用户端的第二子任务的任务处理结果；在任务处理结果为任务处理成功、且该目标用户端已被变更为由该第二用户端管理的目标用户端时，解除该目标用户端与第三用户端的管理关系，第三用户端是在将该目标用户端变更为由第二用户端管理的目标用户端之前管理该目标用户端的用户端。

可选的，对于任一待处理任务或任一子任务，请求处理模块还可以用于：生成该任务的全局唯一标识；其中，第一电子设备在对该任务进行处理的过程中，基于全局唯一标识记录或更新该任务的当前处理状态，以使第二电子设备根据全局唯一标识和当前处理状态，对该任务进行相应的处理；

其中，第一电子设备和第二电子设备为以下任一项：

第一用户端；第二用户端；目标用户端；第一应用的服务器；第二应用的服务器。

可选的，过载判断模块可以用于：根据其他用户端的业务处理请求，确定当前的服务资源使用情况，其中，其他用户端为除第一用户端之外的用户端；根据服务资源占用情况和当前的服务资源使用情况，确定任务创建请求的判断结果，该判断结果为服务资源占用情况满足服务过载判断条件或不满足服务过载判断条件。

本申请实施例的装置可执行本申请实施例所提供的方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

基于与本申请实施例提供的数据处理方法、数据处理装置相同的原理，本申请实施例还提供了一种电子设备，该电子设备可以包括存储器和处理器，其中，存储器中存储有计算机程序，处理器在运行该计算机程序时用于执行本申请任一可选实施例提供的数据处理方法，或者用于执行本申请任一可选实施例提供的装置所执行的动作。

作为一个可选实施例，图15中示出了本申请实施例的一种电子设备的结构示意图，该电子设备可以执行本申请任一可选实施例中提供的数据查询方法。如图15所示，该电子设备4000可以包括处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC (Application SpecificIntegrated Circuit，专用集成电路)，FPGA (FieldProgrammable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或 EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscReadOnly Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器4003用于存储执行本申请方案的应用程序代码(计算机程序)，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的应用程序代码，以实现前述方法实施例所示的内容。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。

基于与本申请实施例提供的方法相同的原理，本申请实施例还提供了一种本计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述本申请任一可选实施例中提供的方法。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。