一种任务处理方法、装置和用于任务处理的装置
文献发布时间：2023-06-19 09:26:02
技术领域
本发明涉及计算机技术领域，尤其涉及一种任务处理方法、装置和用于任务处理的装置。
背景技术
多方安全计算，是使多个非互信数据库之间可以在数据相互保密的前提下进行数据计算或融合，在多方安全计算系统中，由于各数据服务端(Date Server，DS，又称为数据拥有方或数据提供方)没有公网IP地址，因此，在有任务时服务器无法主动连接到DS，目前的实现方案为：通过不断对多方安全计算系统中的数据服务控制端进行询问，以确保在有任务需要执行时，数据服务控制端可以将任务配置信息发送给DS端。
上述方式至少存在如下缺点：
DS获取到任务存在较长的时间延迟，这个延迟的时间取决于DS询问的时间间隔，若间隔过长则导致延迟时间过长，若间隔时间过短，则耗费的处理资源较多，且可能会给被询问的数据服务控制端带来较大的负担，进而降低系统整体的稳定性。
发明内容
本发明实施例提供一种任务处理方法、装置和用于任务处理的装置，使得执行任务时，可以节省处理资源，提高系统整体的稳定性。
为了解决上述问题，本发明实施例公开了一种任务处理方法，应用于任务执行系统，所述系统包括消息服务端、任务管理TM端、任务执行ES端以及数据服务DS端，所述方法包括：
所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
所述TM端保存所述任务配置信息；
所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
另一方面，本发明实施例公开了一种任务处理装置，应用于任务执行系统，所述系统包括消息服务端、TM端、ES端以及DS端，所述装置包括：
第一获取模块，用于通过所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
保存模块，用于通过所述TM端保存所述任务配置信息；
第一发送模块，用于通过所述TM端基于所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
第二获取模块，用于通过所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
再一方面，本发明实施例公开了一种用于任务处理的装置，应用于任务执行系统，所述系统包括消息服务端、TM端、ES端以及DS端，所述装置包括有存储器，以及一个或者一个以上程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行以下操作的指令：
所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
所述TM端保存所述任务配置信息；
所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
又一方面，本发明实施例公开了一种机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如前述一个或多个所述的任务处理方法。
本发明实施例包括以下优点：
本发明实施例的任务处理方法中，TM端通过在获取到待执行任务的情况下，即，有任务要执行的情况下，通过系统中的消息服务端发送任务通知消息给DS端。相应地，DS端在接收到消息服务端发送的任务通知消息的情况下，去获取任务配置信息。这样，由于DS端无需不断进行询问，仅需在接收到通知消息之后，再去获取任务配置信息，因此可以避免进行不必要的询问，进而可以节省处理资源，降低被询问的数据服务控制端的负担，提高系统整体的稳定性。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明提供的一种应用架构的示意图；
图2是本发明提供的一种任务处理方法实施例的步骤流程图；
图3是本发明提供的一种TM端的启动逻辑图；
图4是本发明提供的一种任务配置信息获取示意图；
图5是本发明提供的一种任务执行系统的架构图；
图6是本发明提供的一种任务处理装置实施例的结构框图；
图7是本发明的一种用于任务处理的装置800的框图；及
图8是本发明的一些实施例中服务器的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
首先，参考图1描述本发明实施例的一种应用架构。该应用架构可以用于实现任务执行系统，该架构可以包括消息服务端、任务管理(Task Management，TM)端、任务执行(Executor Server，ES)端以及DS端。其中，任务执行系统可以是一个调度及管理系统，它又可以称为调度者(coordinator，CO)平台，消息服务端可以用于为系统中的各个端之间传递消息，ES端可以用于执行具体任务，ES端可以开启任务控制(Task Control，TC)线程/进程，TM端可以用于管理TC线程/进程，DS端可以提供数据存储、数据提供、计算结果存储等服务。该任务执行系统可以用于实现本发明实施例提供的任务处理方法。
参照图2，示出了本发明的一种任务处理方法实施例的步骤流程图，所述方法应用于任务执行系统，所述方法包括如下步骤：
步骤101、所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
步骤102、所述TM端保存所述任务配置信息；
步骤103、所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
步骤104、所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
本发明实施例的任务处理方法中，TM端通过在获取到待执行任务的情况下，即，有任务要执行的情况下，通过系统中的消息服务端发送任务通知消息给DS端。相应地，DS端在接收到消息服务端发送的任务通知消息的情况下，去获取任务配置信息。这样，由于DS端无需不断进行询问，仅需在接收到通知消息之后，再去获取任务配置信息，因此可以避免进行不必要的询问，进而可以节省处理资源，降低被询问的数据服务控制端的负担，提高系统整体的稳定性。
其中，待执行任务可以是用户通过客户端发起的，待执行任务中可以包含任务配置信息，也可以进一步包含其他信息。相应地，在保存任务配置信息的情况下，还可以进一步保存待执行任务中包含的其他信息，本发明实施例对此不做限定。
进一步地，任务配置信息可以包括待执行任务的任务标识(Identity，ID)，不同待执行任务可以对应不同的任务ID。进一步地，任务配置信息还可以包括其他信息，例如，用于执行该待执行任务的任务参与节点的节点ID，包括：执行任务的ES端ID和、数据提供方DS的ID等。任务配置信息中包括的节点ID表示的任务参与节点，即为待执行任务对应的任务参与节点。
在本发明实施例的一种可选实现方式中，可以预先在TM端中设定接到新任务请求后的通知推送策略，具体的，TM端在收到新任务请求之后，可以获取并保存待执行任务的任务配置信息。之后TM端通过消息服务端向待执行任务对应的任务参与节点发送任务通知消息时，可以先根据任务配置信息确定待执行任务对应的任务参与节点的节点ID，然后向消息服务端发送包括节点ID的通知发送消息，该通知发送消息可以用于指示消息服务端向节点ID指示的任务参与节点发送任务通知消息。相应地，消息服务端在收到该通知发送消息之后，可以向各个节点ID指示的任务参与节点发送任务通知消息。
在本发明实施例的技术方案应用于多方安全计算系统中时，由于完成一个密文计算任务至少需要两个ES，对于ES端，步骤104所述的获取所保存的任务配置信息的步骤可以包括：
步骤S11、所述ES端开启所述待执行任务对应的任务控制TC进程/线程；
步骤S12、所述TC进程/线程根据所述任务ID，向所述TM端发送拉取请求；
步骤S13、所述TC进程/线程接收所述TM端基于所述拉取请求返回的所述任务配置信息。
其中，进程是设备中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位。线程是操作系统能够进行运算调度的最小单位。它可以被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的操作。具体实施时，ES端可以是开启TC进程来执行待执行任务，也可以是开启TC线程来执行待执行任务，本发明实施例对此不作限定。
具体实施时，TM端可以提供grpc接口，以供获取任务配置信息，TC进程/线程可以支持grpc协议，相应地，TC进程/线程基于该grpc接口向TM端发送携带任务ID的拉取请求，该拉取请求可以用于请求TM端保存的待执行任务的任务配置信息。需要说明的是，TC进程/线程发送拉取请求时可以是通过消息服务端发送，也可以是ES端基于自身的节点ID与TM端保持心跳连接，ES端上的TC进程/线程通过该心跳连接向TM端发送，本发明实施例对此不做限定。进一步地，任务执行系统可能会存在多个待执行任务，TM端收到该拉取请求之后，可以根据拉取请求中携带的任务ID，查找该任务ID对应的待执行任务的任务配置信息，并返回给TC进程/线程。需要说明的是，TC进程/线程可以通过ES端上的下述命令实现接收返回的任务配置信息：rpc ExecTcTask(TaskConfig)returns(TaskResponse){}；其中，“TaskConfig”及“TaskResponse”可以延用现有“ExecTask”配置中的信息，本发明实施例对此不作限定。进一步地，如果发送拉取请求的预设时长之后，还未收到TM端返回的任务配置信息，则可以确定TM端出现故障，相应地，可以输出故障提示信息，以提醒工作人员及时进行故障处理。需要说明的是，本发明实施例中，还可以收集TC进程/线程在运行过程中产生的日志，然后通过预设的管理设备进行显示，进而方便获知TC进程/线程的运行情况。其中，日志可以任务ID来命名，通过日志收集系统，例如，“elasticsearch”系统，按照标准(std)格式进行收集，预设的管理设备可以通过读取elasticsearch系统中收集的内容进行显示。
在一种现有实现方式中，TM端通过本身的docker虚拟服务技术，开启TC进程/线程，并主动向TC进程/线程发送任务配置信息。示例的，TM端启动TC进程/线程的过程可以参照图3所示的启动逻辑示意图。这种实现方式中，有时会出现TM端出现问题，导致TC进程/线程受到牵连，无法正常启动的情况。本发明实施例中，由各个ES端开启各自的TC进程/线程，在开启之后主动从TM端获取任务配置信息。这样，可以避免由于TM端出现问题，导致TC进程/线程无法正常启动的问题，确保可以正常开启TC进程/线程。同时，通过在开启之后主动从TM端获取任务配置信息，可以及时发现TM端是否出现问题，进而方便掌握TM端的运行情况。
进一步地，步骤S11中的ES端可以包括第一ES端及第二ES端，其中，第二ES端可以为一个或多个，第一ES端及第二ES端组成一套ES端。具体实施时，所述ES端开启所述待执行任务对应的任务控制TC进程/线程的步骤，可以包括：所述第一ES端开启所述待执行任务对应的任务控制TC进程/线程。所述TC进程/线程接收所述TM端基于所述拉取请求返回的所述任务配置信息之后，所述方法还包括：所述TC进程/线程将所述任务配置信息同步给各个所述第二ES端。例如，在多方安全计算系统中，用于完成一个密文计算任务的一套ES中的一个ES接收到任务通知消息后，启动TC进程/线程，TC进程/线程获取到配置信息后，同步给该一套ES中的其他ES。
其中，第一ES端可以是一套ES端中的任一ES端，第二ES端可以是该套ES端中除第一ES端外的ES端。第一ES端在通过开启的TC进程/线程将任务配置信息同步给第二ES端之后，第一ES端可以参与待执行任务的具体执行过程。本发明实施例中，由第一ES端先开启TC进程/线程，向TM端发送拉取请求以获取任务配置信息，将获取到的任务配置信息同步给其他的第二ES端，这样，可以减小TM端接收的拉取请求的请求量以及需要执行的返回任务配置信息的操作次数，进而可以减轻TM端的负担，同时，也可以省略第二ES端发送拉取请求的操作，节省处理资源。
本发明实施例的任务执行系统中还可以包括数据服务控制(Data ServerControl，DSC)端。任务通知消息中还包括所述DSC端的地址。步骤102中TM端保存所述任务配置信息的操作可以包括：所述TM端本地保存所述任务配置信息，以及根据所述DSC端的地址，将所述任务配置信息发送给所述DSC端保存。其中，DSC端的地址可以是DSC端的网络通信地址或统一资源定位符(Uniform Resource Locator，URL)，TM端可以通过访问该DSC端的地址，向DSC端发送任务配置信息，DSC端收到任务配置信息之后，可以将任务配置信息保存在本地。或者，TM端可以通过ES端将任务配置信息发送给DSC端保存。
示例的，图4是本发明实施例提供的一种任务配置信息获取示意图，如图4所示，第一ES端可以启动TC进程/线程，并从TM端获取任务配置信息。接着该第一ES端可以将任务配置信息发送给ES集群中其他的第二ES端以及DSC端。
需要说明的是，受到发送延迟等因素的影响，可能会出现DS端向DSC端请求任务配置信息时，DSC端可能还未收到ES端发送的任务配置信息。这种情况下DSC端可以主动从TM端获取任务配置信息，并将获取到的任务配置信息返回至DS端，以确保DS端能够及时获取到任务配置信息。
相应地，对于DS端，步骤104中所述获取所保存的待执行任务的任务配置信息的操作，可以包括：
步骤S21、所述DS端根据所述任务ID，向所述DSC端发送拉取请求，以从所述DSC端中获取所述任务配置信息；
步骤S22、若所述DS端在第一预设时长内未接收到所述DSC端返回的所述任务配置信息，则向所述TM端发送所述拉取请求；
步骤S23、所述DS端接收所述TM端基于所述拉取请求返回的所述任务配置信息。
其中，第一预设时长可以根据实际需求设置，本发明实施例对此不做限定。示例的，可以将DSC端返回任务配置信息所需的最长时长作为第一预设时长。具体实施时，可以预先为DSC端以及TM端设置相同的任务获取接口，该任务获取接口可以用于获取任务，DS端可以先基于DSC端的任务获取接口获取任务配置信息，DSC端在有该任务配置信息且正常的情况下，可以向DS端返回任务配置信息。相应地，如果DS端在第一预设时长内未接收到DSC端返回的任务配置信息，则可以认为DSC端可能出现了故障导致无法返回任务配置信息，DS端可以向TM端重新发送拉取请求，基于TM端的任务获取接口获取任务配置信息。需要说明的是，DS端从DSC端中获取任务配置信息之后，还可以在后续过程中向DSC端返回任务状态信息，以便于DSC端获知任务当前的状态。其中，任务状态可以包括：执行中、已完成、未完成，等等。进一步地，DSC端对于未存储的任务配置信息对应的任务状态信息，可以进行抛弃，以避免浪费存储资源。
本发明实施例中，TM端本地保存任务配置信息，以及将任务配置信息发送给DSC端保存，DS端从DSC端中拉取任务配置信息的失败的情况下，从TM端拉取任务配置信息。具体的，TM端可以提供一个返回任务配置信息的grpc接口，任务参与节点可以通过该接口获取config任务配置信息。相应地，DS端可以通过该接口获取任务配置信息。本发明实施例中，通过控制TM端和DSC端保存任务配置信息，两者均能为DS端提供任务配置信息，进而实现为DS端提供双重保障，确保DS端能够顺利获取到任务配置信息。
进一步地，在一种现有实现方式中，DS端是以一个时间周期不断的向DSC端发送心跳消息，通过心跳消息获取任务配置信息，这个时间周期决定了DS端可以在什么时候拿到任务。在时间周期较长的情况下，可能会导致DS端在TM端保存任务配置信息较长时间之后，才获取到任务配置信息，获取任务配置信息的延迟较大。本发明实施例中，DS端在接收到消息服务端发送的任务通知消息的情况下，就去获取任务配置信息，一定程度上可以确保能够及时的获取到任务配置信息，降低获取任务配置信息的延迟。
同时，相较于DS端通过和DSC端一直保持心跳连接，不断询问DSC端，以获取任务配置信息，进而给DSC端造成较重的网络流量和CPU负担的方式。本发明实施例中，DS端和DSC端无需一直保持心跳连接，仅需和消息服务端进行偶尔通讯，即，接收消息服务端发送的任务通知消息，在接收到任务通知消息之后，才从DSC端中获取任务配置信息，可以避免为DSC端造成不必要的的网络流量和CPU负担，提高DSC端的稳定性。
进一步地，本发明实施例中由于TM端需要通过消息服务端向DS端发送任务通知消息，因此，DS端可以先向TM端注册，以确保TM端能够感知到DS端的存在，进而方便TM端向DS端发送任务通知消息。可选的，DS端进行注册的过程可以为：所述DS端在初始化阶段，向所述TM端发送携带所述DS端的节点ID的注册信息，以向所述TM端表征所述DS端当前处于可使用状态；若所述DS端在第三预设时长内未接收到所述TM端返回的注册成功响应，则重新向所述TM端发送所述注册请求，直至接收到所述注册成功响应为止。
其中，初始化阶段可以为DS端初次接入任务执行系统时，第三预设时长可以是根据实际需求设置的，本发明实施例对此不做限定。需要说明的是，TM端向DS端发送任务通知消息时，可以先确定该DS端是否处于可使用状态，如果处于，再执行发送操作，以避免向不可使用的DS端执行不必要的发送操作，进而节省处理资源。
具体的，可以预先设定TM端提供支持重复注册的注册接口，以供DS注册。TM端收到DS端发送的注册信息之后，可以记录DS端的节点ID，以实现注册。并在注册之后返回注册成功响应。相应地，如果DS端在第三预设时长内未接收到TM端返回的注册成功响应，则可以认为没有注册成功，此时，可以重新向TM端发送注册请求，直至接收到注册成功响应为止。本发明实施例中，DS端通过向TM端进行注册，并在未注册成功的情况下，重复注册，这样可以确保TM端能够感知到DS端当前处于可使用状态，进而方便TM端向DS端发送任务通知消息。同时，通过支持重复注册，保持接口的幂等性，可以确保DS端能够顺利注册。例如，在出现网络延迟，或者DS端重启的特殊情况下，DS端可以通过重复注册，完成注册。
可选的，实际应用场景中，任务参与节点可能会接收到多种多样的通知消息。例如，当TM端需要探活DS端时，可能会发送用于指示DS端向TM端发送ping指令的探活通知消息，或者，当TM端地址有变化时，TM端可能会发送地址变更通知消息。对于接收到的通知消息，所述任务参与节点可以判断所述通知消息的通知类型是否为任务类型；若所述通知的通知类型为任务类型，则确认接收到所述任务通知消息。
具体实施时，通知消息的通知格式可以为一个元组
在本发明的另一可选实施例中，也可以不在任务执行系统中设置DSC端，相应地，对于任务参与节点中的DS端，DS端可以根据任务ID，向所述TM端发送拉取请求；所述DS端接收所述TM端基于所述拉取请求返回的所述任务配置信息。具体的，DS端根据任务ID发送拉取请求，以获取任务配置信息的实现方式可以参照前述相关描述，此处不再赘述。本发明实施例中，无需在任务执行系统设置DSC端，DS端直接从TM端中拉取任务配置信息的方式，可以降低任务执行系统的硬件成本，进而降低任务处理方法的实现成本。
在本发明的另一可选实施例中，步骤103之后，还可以包括：
步骤A、若在第二预设时长内未接收到所述拉取请求，则所述TM端重复执行所述发送任务通知消息的操作，直至重复执行的次数达到预设次数阈值或接收到所述拉取请求为止。其中，第二预设时长以及预设次数阈值可以根据实际需求设置，本发明实施例对此不做限定。正常情况下，任务参与节点收到任务通知消息，会通过向TM端发送拉取请求来响应该任务通知消息。如果在第二预设时长内未接收到拉取请求。则可以认为任务参与节点未正常收到任务通知消息。这种情况下TM端可以重复通过消息服务端发送任务通知消息，进一步地，如果重复执行的次数达到预设次数阈值或接收到拉取请求，则可以停止执行，以避免浪费处理资源。当然，也可以在执行重复发送操作的时长达到预设时长时，停止重复发送，本发明实施例对此不作限定。
相应地，任务参与节点根据所述任务ID，向所述TM端发送拉取请求时，可以先判断是否首次接收到所述任务ID；若是首次接收到所述任务ID，则向所述TM端发送所述拉取请求。具体实施例时，任务参与节点可以每次对接收到任务通知消息中携带的任务ID进行记录，在根据任务ID发送拉取请求时，可以检测记录的任务ID中是否存在该任务ID，如果不存在，则可以认为是首次接收到该任务ID，并根据该任务ID向TM端发送拉取请求。
本发明实施例中，TM端在第二预设时长内未接收到拉取请求的情况下，重复发送任务通知消息，这样，一定程度上可以确保任务通知消息能够正常发送给任务参与节点。进一步地，可能会出现任务参与节点收到任务通知消息，但由于网络延迟等因素，导致拉取请求未及时发送给TM端，进而导致TM端重复发送任务通知消息的情况。本发明实施例中任务参与节点根据任务通知消息中的任务ID发送拉取请求时，在首次接收到任务ID的情况下，才发送拉取请求，进而可以避免由于TM端重复发送任务通知消息，导致重复发送拉取请求的问题，节省处理资源。
进一步地，在本发明的另一可选实施例中，可以在步骤103之前执行下述操作：所述任务参与节点向所述消息服务端发送通道分配请求；所述消息服务端在接收到所述通道分配请求之后，向所述任务参与节点分配对应的消息发送通道。其中，通道分配请求可以用于向消息服务端订阅属于任务参与节点的通道。通道分配请求中可以携带任务参与节点的节点ID，消息服务端可以建立节点ID与通道(channel)的对应关系，不同节点ID对应的通道可以不同，该任务参与节点的节点ID对应的通道即为分配给该任务参与节点的通道。需要说明的是，任务参与节点对应的通道的通道信息可以表示该任务参与节点的节点ID，这样，可以方便消息服务端根据任务参与节点的节点ID确定其对应的通道。示例的，DS端对应的通道的通道信息可以为url：privpy/aaa/dsid。其中“dsid”表示DS端的节点ID。
相应地，所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息，可以包括：
步骤S31、所述TM端将所述待执行任务中包括的任务参与节点的节点ID发送给所述消息服务端；
步骤S32、所述消息服务端根据接收到的各个所述节点ID对应的消息发送通道，向所述任务参与节点发送所述任务通知消息。
具体实施时，TM端和消息服务端可以为部署在同一服务器上的虚拟服务，相应地，TM端可以通过服务器内部的通信机制与消息服务端进行通信。或者，TM端和消息服务端部署在不同服务器上，相应地，TM端可以通过服务器之间的网络连接与消息服务端进行通信。
进一步地，消息服务端可以根据建立的对应关系确定各个节点ID对应的消息发送通道，并通过对应的消息发送通道发送任务通知消息。本发明实施例中，各个任务参与节点先向消息服务端注册属于自己的消息发送通道，消息服务端通过各个任务参与节点各自对应的消息发送通道发送任务通知消息，可以避免发送给多个任务参与节点的多个任务通知消息之间互相干扰，进而提高消息发送效率。
在本发明的一种可选实施例中，获取所保存的任务配置信息之后，所述方法还包括：
步骤B、所述任务参与节点根据所述任务配置信息，进行多方安全计算，以完成所述待执行任务；具体的，执行待执行任务可以包括：所述DS端根据所述任务配置信息将数据密文发送给所述任务配置信息中指定的ES端；所述ES端针对接收的数据密文，按照多方安全计算协议执行多方安全计算。这样，通过指定的ES端对数据密文按照多方安全计算协议执行多方安全计算，可以在数据相互保密的前提下实现计算，进而提高参与计算的数据的安全性。需要说明的是，DS端可以与ES端共享相应的证书，以使计算过程支持安全层传输(Transport Layer Security，TLS)及数据授权(auth)。
进一步地，所述ES端针对接收的数据密文，按照多方安全计算协议执行多方安全计算之后，所述方法还包括：
步骤C、所述ES端通过所述消息服务端向结果需求端发送结果获取通知消息；
步骤D、所述结果需求端在接收到所述结果获取通知消息之后，向所述ES端发送结果拉取请求；
步骤E、所述结果需求端接收所述ES端返回的所述多方安全计算的计算结果。
其中，结果获取通知消息可以表示多方安全计算已完成，结果拉取请求可以用于向ES端获取多方安全计算的计算结果。ES端收到结果拉取请求之后，可以相应将多方安全计算的计算结果返回给结果需求端。结果需求端可以是根据实际需求指定的。示例的，结果需求端可以为DS端，也可以为发起待执行任务的客户端，等等。进一步地，在一种现有实现方式中，结果需求端是以一个时间周期不断的向DSC端发送心跳消息，通过心跳消息获取计算结果，这个时间周期决定了结果需求端可以在什么时候拿到计算结果。在时间周期较长的情况下，可能会导致结果需求端获取计算结果的延迟较大。本发明实施例中，ES端在完成多方安全计算之后，通过消息服务端向结果需求端发送结果获取通知消息，结果需求端收到结果获取通知消息之后，才向ES端发送结果拉取请求，可以省略结果需求端不断发送心跳消息的操作，进而降低对结果需求端的资源耗费量，提高结果需求端的获取效率。同时，收到结果获取通知消息之后，就向ES端发送结果拉取请求的方式，可以及时的获取到计算结果，降低延迟。
需要说明的是，TC进程/线程在执行待执行任务的过程中，可以周期性向TM端返回任务状态信息。具体的，在开始执行任务时，TM端可以调用预设的“ExecTcTask”接口，发送“startTcRequest”协议信息至ES端的控制端口，该控制端口可以为7001端口。基于该“ExecTcTask”接口可以返回任务状态信息。具体的，TM端可以每秒向该接口发送基于protobuf协议的信息，以获取任务状态信息，直到任务结束位置。相应地，ES端可以在收到基于protobuf协议的信息之后，转发给TC进程/线程，待TC进程/线程返回任务状态信息之后，将任务状态信息发送给TM端。进一步地，TM端调用“ExecTcTask”接口，基于“ExecTcTask”接口获取返回的任务状态信息以及每秒向该接口发送基于protobuf协议的信息的操作，可以是在执行排除故障(debug)任务的具体代码时调用的。
可选的，本发明实施例中的消息服务端可以为基于发布PUB/订阅SUB协议的通知notification服务。由于notification服务可以支持多种操作系统和编程语言，因此，采用notification服务可以多样化的实现消息服务端，例如，将消息服务端的处理逻辑和实际的任务处理过程分离。同时，由于notification服务可以以较小的网络开销实现通信，支持各种不同的client网络环境，因此，可以确保DS端/ES端处于各种各样的网络环境时，都可以通过消息服务端实现向DS端/ES端发送消息。例如，在DS端没有公网IP地址的情况下，由于notification服务可以支持有公网IP地址和没有公网IP地址情况下的通信，因此，可以确保能够向DS端发送消息。同时，由于notification服务本身较为成熟可靠，因此采用notification服务实现消息服务端，可以确保消息服务端的可靠性以及稳定性。其中，消息服务端中选定的通知系统可以为一个微消息队列，进一步地，还可以设置一个接口与微消息队列一致的模拟消息队列。这样，通过双消息队列一定程度上可以提高消息服务端的消息发送效率。
进一步地，在本发明的一种可选实施例中，对于任务参与节点中的DS端，所述消息服务端可以为所述DS端分配至少两个消息发送通道，一个消息发送通道可以对应一个多方安全计算系统。需要说明的是，消息服务端为DS端分配的至少两个消息发送通道可以理解为DS端向消息服务端订阅的多个服务。进一步地，步骤S32中所述的消息服务端根据接收到的各个节点ID对应的消息发送通道，向任务参与节点发送所述任务通知消息的操作，可以包括：
步骤S32a、所述消息服务端通过为所述DS端分配的至少两个消息发送通道中，与目标多方安全计算系统对应的消息发送通道，向所述DS端发送所述任务通知消息；所述目标多方安全计算系统为所述任务执行系统。
具体实施时，消息服务端可以先查找与目标多方安全计算系统对应的消息发送通道，然后通过该消息发送通道发送任务通知消息。本发明实施例中，通过为DS端分配多个对应不同多方安全计算系统的消息发送通道，使得DS端可以为多个多方安全计算系统提供服务。这样，多个多方安全计算系统共用DS端，一定程度上可以提高DS端的利用率。示例的，可以为DS端分配两个消息发送通道，其中一个消息发送通道可以对应多方安全计算系统A，另一个消息发送通道可以对应多方安全计算系统B，进而实现DS端同时对接多方安全计算系统A及多方安全计算系统B，同时为两个或多个多方安全计算系统提供服务。
进一步地，图5是本发明实施例提供的一种任务执行系统的架构图，如图5所示，TM端可以通过消息服务端向其中一个ES端及DS端发送任务通知消息，相应地，该ES端可以通过内部开启的TC进程/线程从TM端拉取任务配置信息，之后将拉取到的任务配置信息同步至各个ES端，以及发送给DSC端保存，以便于DS端从DSC端获取任务配置信息。进一步地，DS端以及ES端还可以向向TM端返回状态信息。相较于现有架构，本发明实施例中仅需在现有架构基础上添加消息服务端，即可实现本发明实施例提供的任务处理方法，对架构的改动较小，实现成本较低。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
装置实施例
参照图6，示出了本发明的一种任务处理装置实施例的结构框图，所述装置应用于任务执行系统，所述系统包括消息服务端、TM端、ES端以及DS端，所述装置具体可以包括：
第一获取模块601，用于通过所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
保存模块602，用于通过所述TM端保存所述任务配置信息；
第一发送模块603，用于通过所述TM端基于所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
第二获取模块604，用于通过所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
可选的，所述任务配置信息中包括所述待执行任务的任务标识ID；
对于所述任务参与节点中的所述ES端，所述第二获取模块604，具体用于：
通过所述ES端开启所述待执行任务对应的任务控制TC进程/线程；
通过所述TC进程/线程根据所述任务ID，向所述TM端发送拉取请求；
通过所述TC进程/线程接收所述TM端基于所述拉取请求返回的所述任务配置信息。
可选的，所述ES端包括第一ES端及第二ES端；
所述第二获取模块604，还用于：
通过所述第一ES端开启所述待执行任务对应的任务控制TC进程/线程；
通过所述TC进程/线程接收所述TM端基于所述拉取请求返回的所述任务配置信息之后，所述第二获取模块604，还具体用于：
通过所述TC进程/线程将所述任务配置信息同步给各个所述第二ES端。
可选的，所述系统还包括：数据服务控制DSC端，所述任务通知消息中还包括所述DSC端的地址；
所述保存模块602，具体用于：
所述TM端本地保存所述任务配置信息，以及
根据所述DSC端的地址，将所述任务配置信息发送给所述DSC端保存；
相应地，对于所述任务参与节点中的所述DS端，所述第二获取模块604，还具体用于：
通过所述DS端根据所述任务ID，向所述DSC端发送拉取请求，以从所述DSC端中获取所述任务配置信息；
若所述DS端在第一预设时长内未接收到所述DSC端返回的所述任务配置信息，则通过所述DS端向所述TM端发送所述拉取请求；
通过所述DS端接收所述TM端基于所述拉取请求返回的所述任务配置信息。
可选的，所述任务配置信息中包括所述待执行任务的任务标识ID；对于所述任务参与节点中的所述DS端，所述第二获取模块604，还具体用于：
通过所述DS端根据所述任务ID，向所述TM端发送拉取请求；
通过所述DS端接收所述TM端基于所述拉取请求返回的所述任务配置信息。
可选的，通过所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息之后，所述第一获取模块601，具体用于：
若在第二预设时长内未接收到所述拉取请求，则通过所述TM端重复执行所述发送任务通知消息的操作，直至重复执行的次数达到预设次数阈值或接收到所述拉取请求为止；
相应地，所述第二获取模块604，还具体用于：
判断是否首次接收到所述任务ID；
若是首次接收到所述任务ID，则向所述TM端发送所述拉取请求。
可选的，所述装置还包括：
第二发送模块，用于通过所述任务参与节点向所述消息服务端发送通道分配请求；
分配模块，用于通过所述消息服务端在接收到所述通道分配请求之后，向所述任务参与节点分配对应的消息发送通道；
相应地，所述第一获取模块601，具体用于：
通过所述TM端将所述待执行任务中包括的任务参与节点的节点ID发送给所述消息服务端；
通过所述消息服务端根据接收到的各个所述节点ID对应的消息发送通道，向所述任务参与节点发送所述任务通知消息。
可选的，所述装置还包括：
执行模块，用于所述任务参与节点根据所述任务配置信息，进行多方安全计算，以完成所述待执行任务；
相应地，对于所述任务参与节点中的DS端，所述消息服务端为所述DS端分配至少两个消息发送通道，一个消息发送通道对应一个多方安全计算系统；所述所述第一获取模块601，还具体用于：
通过所述消息服务端通过为所述DS端分配的至少两个消息发送通道中，与目标多方安全计算系统对应的消息发送通道，向所述DS端发送所述任务通知消息；所述目标多方安全计算系统为所述任务执行系统。
可选的，所述消息服务端为基于发布PUB/订阅SUB协议的通知notification服务。
可选的，所述装置还包括：
注册模块，用于所述DS端在初始化阶段，向所述TM端发送携带所述DS端的节点ID的注册信息，以向所述TM端表征所述DS端当前处于可使用状态；
第三发送模块，用于若所述DS端在第三预设时长内未接收到所述TM端返回的注册成功响应，则重新向所述TM端发送所述注册请求，直至接收到所述注册成功响应为止。
可选的，所述装置还包括：
判断模块，用于对于接收到的通知消息，所述任务参与节点判断所述通知消息的通知类型是否为任务类型；
确认模块，用于若所述通知的通知类型为任务类型，则确认接收到所述任务通知消息。
可选的，所述执行模块，具体用于：
通过所述DS端根据所述任务配置信息将数据密文发送给所述任务配置信息中指定的ES端；
通过所述ES端针对接收的数据密文，按照多方安全计算协议执行多方安全计算。
可选的，所述装置还包括：
第四发送模块，用于所述ES端通过所述消息服务端向结果需求端发送结果获取通知消息；
第五发送模块，用于所述结果需求端在接收到所述结果获取通知消息之后，向所述ES端发送结果拉取请求；
接收模块，用于所述结果需求端接收所述ES端返回的所述多方安全计算的计算结果。
本发明实施例的任务处理装置，通过TM端在获取到待执行任务的情况下，即，有任务要执行的情况下，通过系统中的消息服务端发送任务通知消息给DS端。相应地，通过DS端在接收到消息服务端发送的任务通知消息的情况下，去获取任务配置信息。这样，由于DS端无需不断进行询问，仅需在接收到通知消息之后，再去获取任务配置信息，因此可以避免进行不必要的询问，进而可以节省处理资源，降低被询问的数据服务控制端的负担，提高系统整体的稳定性。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
本发明实施例提供了一种用于任务处理的装置，包括有存储器，以及一个或者一个以上程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行以下操作的指令：获取待处理字符串；根据所述待处理字符串中各字符在内存中的字符编码，将所述待处理字符串转换为整数类型的目标数据；对所述目标数据进行加密，得到密文数据；将所述密文数据输入多方安全计算系统，通过所述多方安全计算系统对所述密文数据执行预设的操作，得到所述待处理字符串对应的操作结果的密文。
图7是根据一示例性实施例示出的一种用于任务处理的装置800的框图。例如，装置800可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。
参照图7，装置800可以包括以下一个或多个组件：处理组件802，存储器804，电源组件806，多媒体组件808，音频组件810，输入/输出(I/O)的接口812，传感器组件814，以及通信组件816。
处理组件802通常控制装置800的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件802可以包括一个或多个处理器820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件802可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。
存储器804被配置为存储各种类型的数据以支持在设备800的操作。这些数据的示例包括用于在装置800上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
电源组件806为装置800的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为装置800生成、管理和分配电力相关联的组件。
多媒体组件808包括在所述装置800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当设备800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。
音频组件810被配置为输出和/或输入音频信号。例如，音频组件810包括一个麦克风(MIC)，当装置800处于操作模式，如呼叫模式、记录模式和语音信息处理模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中，音频组件810还包括一个扬声器，用于输出音频信号。
I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。
传感器组件814包括一个或多个传感器，用于为装置800提供各个方面的状态评估。例如，传感器组件814可以检测到设备800的打开/关闭状态，组件的相对定位，例如所述组件为装置800的显示器和小键盘，传感器组件814还可以检测装置800或装置800一个组件的位置改变，用户与装置800接触的存在或不存在，装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。
通信组件816被配置为便于装置800和其他设备之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件816还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频信息处理(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。
在示例性实施例中，装置800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。
在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由装置800的处理器820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
图8是本发明的一些实施例中服务器的结构示意图。该服务器1900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processingunits，CPU)1922(例如，一个或一个以上处理器)和存储器1932，一个或一个以上存储应用程序1942或数据1944的存储介质1930(例如一个或一个以上海量存储设备)。其中，存储器1932和存储介质1930可以是短暂存储或持久存储。存储在存储介质1930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1922可以设置为与存储介质1930通信，在服务器1900上执行存储介质1930中的一系列指令操作。
服务器1900还可以包括一个或一个以上电源1926，一个或一个以上有线或无线网络接口1950，一个或一个以上输入输出接口1958，一个或一个以上键盘1956，和/或，一个或一个以上操作系统1941，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。
一种非临时性计算机可读存储介质，当所述存储介质中的指令由装置(服务器或者终端)的处理器执行时，使得装置能够执行图2所示的任务处理方法。
一种非临时性计算机可读存储介质，当所述存储介质中的指令由装置(服务器或者终端)的处理器执行时，使得装置能够执行一种任务处理方法，所述方法应用于任务执行系统，所述系统包括消息服务端、TM端、ES端以及DS端，所述方法包括：所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；所述TM端保存所述任务配置信息；所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
本发明实施例公开了A1、一种任务处理方法，应用于任务执行系统，所述系统包括消息服务端、任务管理TM端、任务执行ES端以及数据服务DS端，所述方法包括：
所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
所述TM端保存所述任务配置信息；
所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
A2、根据A1所述的方法，所述任务配置信息中包括所述待执行任务的任务标识ID；
对于所述任务参与节点中的所述ES端，所述获取所保存的任务配置信息，包括：
所述ES端开启所述待执行任务对应的任务控制TC进程/线程；
所述TC进程/线程根据所述任务ID，向所述TM端发送拉取请求；
所述TC进程/线程接收所述TM端基于所述拉取请求返回的所述任务配置信息。
A3、根据A2所述的方法，所述ES端包括第一ES端及第二ES端；
所述ES端开启所述待执行任务对应的任务控制TC进程/线程，包括：
所述第一ES端开启所述待执行任务对应的任务控制TC进程/线程；
所述TC进程/线程接收所述TM端基于所述拉取请求返回的所述任务配置信息之后，所述方法还包括：
所述TC进程/线程将所述任务配置信息同步给各个所述第二ES端。
A4、根据A1所述的方法，所述系统还包括：数据服务控制DSC端，所述任务通知消息中还包括所述DSC端的地址；
所述TM端保存所述任务配置信息，包括：
所述TM端本地保存所述任务配置信息，以及
根据所述DSC端的地址，将所述任务配置信息发送给所述DSC端保存；
相应地，对于所述任务参与节点中的所述DS端，所述获取所保存的待执行任务的任务配置信息，包括：
所述DS端根据所述任务ID，向所述DSC端发送拉取请求，以从所述DSC端中获取所述任务配置信息；
若所述DS端在第一预设时长内未接收到所述DSC端返回的所述任务配置信息，则向所述TM端发送所述拉取请求；
所述DS端接收所述TM端基于所述拉取请求返回的所述任务配置信息。
A5、根据A1所述的方法，所述任务配置信息中包括所述待执行任务的任务标识ID；对于所述任务参与节点中的所述DS端，所述获取所保存的任务配置信息，包括：
所述DS端根据所述任务ID，向所述TM端发送拉取请求；
所述DS端接收所述TM端基于所述拉取请求返回的所述任务配置信息。
A6、根据A2至A5任一所述的方法，所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息之后，所述方法还包括：
若在第二预设时长内未接收到所述拉取请求，则所述TM端重复执行所述发送任务通知消息的操作，直至重复执行的次数达到预设次数阈值或接收到所述拉取请求为止；
相应地，所述根据所述任务ID，向所述TM端发送拉取请求，包括:
判断是否首次接收到所述任务ID；
若是首次接收到所述任务ID，则向所述TM端发送所述拉取请求。
A7、根据A1所述的方法，所述方法还包括：
所述任务参与节点向所述消息服务端发送通道分配请求；
所述消息服务端在接收到所述通道分配请求之后，向所述任务参与节点分配对应的消息发送通道；
相应地，所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息，包括：
所述TM端将所述待执行任务中包括的任务参与节点的节点ID发送给所述消息服务端；
所述消息服务端根据接收到的各个所述节点ID对应的消息发送通道，向所述任务参与节点发送所述任务通知消息。
A8、根据A6所述的方法，所述获取所保存的任务配置信息之后，所述方法还包括：
所述任务参与节点根据所述任务配置信息，进行多方安全计算，以完成所述待执行任务；
相应地，对于所述任务参与节点中的DS端，所述消息服务端为所述DS端分配至少两个消息发送通道，一个消息发送通道对应一个多方安全计算系统；所述消息服务端根据接收到的各个所述节点ID对应的消息发送通道，向所述任务参与节点发送所述任务通知消息，包括：
所述消息服务端通过为所述DS端分配的至少两个消息发送通道中，与目标多方安全计算系统对应的消息发送通道，向所述DS端发送所述任务通知消息；所述目标多方安全计算系统为所述任务执行系统。
A9、根据A1所述的方法，其特征在于，所述消息服务端为基于发布PUB/订阅SUB协议的通知notification服务。
A10、根据A1所述的方法，其特征在于，所述方法还包括：
所述DS端在初始化阶段，向所述TM端发送携带所述DS端的节点ID的注册信息，以向所述TM端表征所述DS端当前处于可使用状态；
若所述DS端在第三预设时长内未接收到所述TM端返回的注册成功响应，则重新向所述TM端发送所述注册请求，直至接收到所述注册成功响应为止。
A11、根据A1所述的方法，所述方法还包括：
对于接收到的通知消息，所述任务参与节点判断所述通知消息的通知类型是否为任务类型；
若所述通知的通知类型为任务类型，则确认接收到所述任务通知消息。
A12、根据A1所述的方法，所述执行所述待执行任务包括：
所述DS端根据所述任务配置信息将数据密文发送给所述任务配置信息中指定的ES端；
所述ES端针对接收的数据密文，按照多方安全计算协议执行多方安全计算。
A13、根据A12所述的方法，所述ES端针对接收的数据密文，按照多方安全计算协议执行多方安全计算之后，所述方法还包括：
所述ES端通过所述消息服务端向结果需求端发送结果获取通知消息；
所述结果需求端在接收到所述结果获取通知消息之后，向所述ES端发送结果拉取请求；
所述结果需求端接收所述ES端返回的所述多方安全计算的计算结果。
本发明实施例公开了B14、一种任务处理装置，应用于任务执行系统，所述系统包括消息服务端、TM端、ES端以及DS端，所述装置包括：
第一获取模块，用于通过所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
保存模块，用于通过所述TM端保存所述任务配置信息；
第一发送模块，用于通过所述TM端基于所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
第二获取模块，用于通过所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
本发明实施例公开了C15、一种用于任务处理的装置，应用于任务执行系统，所述系统包括消息服务端、TM端、ES端以及DS端，所述装置包括有存储器，以及一个或者一个以上程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行以下操作的指令：
所述TM端获取待执行任务，所述待执行任务中包含任务配置信息；
所述TM端保存所述任务配置信息；
所述TM端通过所述消息服务端向所述待执行任务对应的任务参与节点发送任务通知消息；所述任务参与节点包括所述待执行任务对应的ES端以及DS端；
所述任务参与节点接收到所述任务通知消息之后，获取所保存的任务配置信息，以执行所述待执行任务。
本发明实施例公开了D16、一种机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如A1至A13中一个或多个所述的任务处理方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。
应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
以上对本发明所提供的一种任务处理方法、一种任务处理装置和一种用于任务处理的装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
- 一种任务处理方法、装置和用于任务处理的装置
- 一种任务处理方法、装置和用于任务处理的装置