具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
本发明实施例所提供的任务分布式处理方法,可应用于如图1所示的应用环境中。参考图1,服务器110与多个终端120相连。其中,该终端可为笔记本电脑、台式电脑、平板等其中的任意一种。每个终端120均可向服务器发送任务处理请求。服务器110可根据所接收到任务处理请求,选取至少一个待分配状态的任务,将选取的任务分配给发送该任务处理请求的终端120进行处理。该终端120可对所接收到的任务进行分析处理,将任务处理结果发送给服务器110。服务器110根据接收到的任务处理结果修改对应任务的任务状态。从而实现了通过终端来对任务进行分布式处理。
在一个实施例中,如图2所示,提供了一种任务分布式处理方法,该方法可应用于如图1所示的应用环境中,具体包括如下步骤:
步骤S202,接收终端发送的任务处理请求。
本实施例中,该终端为对应需要处理该任务的公司或集团内的员工终端或其它所属终端。每个终端可为DTS***(Distributed Task Scheduler,分布式任务调度***)中的一个任务执行节点。该DTS***为一个通用的、插件式的、支持扩展的分布式调度执行框架,用于实现对任务分布式分配和解析等处理。该任务是指数量众多的、每个任务可被分布式处理的任务,包括应用程序编译任务、日志报表统计任务、Crash解析任务等。
以Crash解析任务为例来说明,该Crash可为所收集的某一app(Application,应用)上报的Crash堆栈信息,可将1条或多条适应数量的待解析的Crash堆栈信息作为一个Crash解析任务。当收集Crash堆栈信息越多,则待处理的Crash解析任务也越多。
终端可在处于空闲状态时,可向该DTS***中的服务器发送任务处理请求,该任务处理请求中携带终端标识。该服务器为DTS***中的主控节点,负责管理任务和所有执行节点。任务的管理包含了接收、存储、分发、记录、监控任务;节点的管理包含了接收执行节点的心跳包、监控执行节点的工作状态等。服务器可实时接收每个终端所发送的任务处理请求,获取其中的终端标识,使得根据该终端标识确定对应的终端。
步骤S204,选取至少一个待分配状态的任务,将选取的任务分配给终端进行处理。
本实施例中,服务器可从数据库所存储的待分配状态的任务中,选取预设数量的任务,将选取的任务的任务信息发送至终端,使得终端对该任务进行处理。其中,任务的状态包括待分配、处理中、处理成功以及处理失败的状态。预设数量可为预设的1个或几个等合适的数量,以使得终端可同时对多个任务进行处理,提高处理的效率。对待分配状态的任务的选取方式可包括随机选取方式以及按照任务生成的时间顺序来进行选取的方式。
具体地,终端可接收所分配的任务,并按照对应的任务解析方式对该任务进行解析处理,将处理结果发送给服务器。
在一个实施例中,在步骤S204之后,还包括:将选取的任务的状态修改为处理中。
步骤S206,接收终端反馈的任务处理结果;根据任务处理结果修改对应任务的任务状态。
本实施例中,服务器可接收终端对该任务进行处理后,所反馈的任务处理结果。该任务处理结果包括任务处理成功和任务处理失败。服务器可根据该任务处理结果修改对应已分配的任务的任务状态。比如,当该任务为处理成功,则将其任务状态修改为处理成功,若为处理失败,则将其任务状态修改为处理失败。
在一个实施例中,每个终端之间可为在任务处理上相互独立的终端。即在任务处理的过程中,终端之间进行互相独立的处理,并无连接关系。在DTS***中,由于每个终端仅与服务器相连,可保持对任务处理的独立性,以提高终端进行任务处理的效率。
本实施例中,通过接收终端发送的任务处理请求;选取至少一个待分配状态的任务,将选取的任务分配给终端进行处理;然后接收终端反馈的任务处理结果;根据任务处理结果修改对应任务的任务状态。从而实现了将终端作为DTS***中的任务执行节点,对任务进行处理。当终端数量越多,则服务器上可被及时分配的分布式处理的任务也越多。从而使得无需增加服务器,或者对服务器进行扩容,通过利用已有的终端,将众多的任务分配给每个已有的终端进行处理,提高了任务处理的效率。
在一个实施例中,上述的选取至少一个待分配状态的任务,包括:选取至少一个待分配状态的任务标识;从主数据库中读取每个任务标识对应的任务,当从主数据库读取失败时,从备用数据库中读取每个任务标识对应的任务。
本实施例中,任务标识用于唯一识别对应的任务,并与对应任务的任务信息相关联,可由预设位数的数字、字母等字符所构成。任务标识可为任务编号。服务器可在检测到有任务生成时,可为所生成的任务设置相应的任务编号,并将该任务信息分别写入主数据库和备用数据库中。
进一步地,还预先设置了两个数据库,分别为主数据库和备用数据库。每个未处理完成的任务的任务信息在主数据库和备用数据库中均有存储,并可根据该任务编号从主数据库或备用数据库中查询出来。主数据库为默认优先使用的数据库,备用数据库为备用的数据库。服务器可在选取了任务标识后,可根据该任务标识首先从主数据库中查询对应的任务,并读取该任务信息。当从主数据库中读取失败时,则从备用数据库中读取对应任务的任务信息,从而任可进一步提高对任务的提取的成功率。
本实施例中,通过提供主数据库和备用数据库,从而可在主数据库出现故障时,从备用数据库中读取待分配的任务。可防止数据库出现故障,导致待处理的任务积压而造成进一步的影响。
在一个实施例中,任务处理请求中携带终端的互联网协议地址;将选取的任务分配给终端进行处理,包括:根据互联网协议地址,将选取的任务分配给终端进行处理。
本实施例中,互联网协议地址(Internet Protocol Address,IP地址)为终端的本机IP地址。由于终端为员工终端,需要处理其它工作事项,可能存在随时关机、重启、断网、切换网络等操作,使得终端的IP地址或其它参数特征出现变化。相比较于传统的zookeeper需要在启动之前事先配置好所有执行节点的IP和端口。本实施例直接通过在任务处理请求中携带终端的IP地址,使得服务器可向该IP地址发送所分配的任务,实现了即时终端的IP地址出现了动态变化,也可根据变化后的IP地址,成功将任务信息发送至终端,使终端进行任务处理。
在一个实施例中,在将选取的任务分配给终端进行处理之后,包括:接收终端发送的心跳包,以根据心跳包确定终端正在处理选取的任务。
本实施例中,终端可在接收到所分配的任务后,按照预设的频率向服务器发送心跳包,该心跳包中包含终端的IP地址,使得服务器可根据所接收到的每个心跳包,识别出对应的IP地址,从而可确定对应的终端。服务器通过接收每个终端定时发送的心跳包,可获知对应终端正在处理被分配的任务,从而还实现了对每个终端进行任务处理的监控。
在一个实施例中,在将选取的任务分配给终端进行处理之后,包括:检测是否在预设时长之内接收到任务处理结果,若否,则将选取的任务重新分配给其它发送任务处理请求的终端进行处理。
本实施例中,服务器还设置了时长阈值,即上述的预设时长。该时长阈值为用于评判任务的处理是否异常的时长。时长阈值可根据历史统计出的完成任务的处理所需的平均时长,而设置的时长。可为超过该平均时长一定大小的时长。比如处理一个任务的平均时长为5分钟,则可设置该时长阈值可为8分钟或10分钟等。
服务器可在分配了任务给终端后,开始实时统计任务的处理时长,并比较该处理时长和预设时长的大小,当该处理时长达到预设时长,且还未接收到终端发送的任务处理结果时,则判定终端对该任务的处理失败。并重新将所分配任务的任务状态设置为待分配状态,并根据所接收到的其它终端的任务处理请求,重新对该任务进行分配。
本实施例中,通过设置预设时长,将超过预设时长还未收到任务处理结果的任务进行重新分配,可进一步提到对任务处理完成的成功率。
在一个实施例中,上述的任务分布式处理方法还包括:计算选取的任务的分配次数;当分配次数达到预设次数时,若在预设时长之内未接收到任务处理结果,或者接收到任务处理失败的任务处理结果,则将选取任务的任务状态修改为处理异常的状态。
本实施例中,当产生任务被重新分配时,服务器可进一步统计被重新分配的任务的分配次数,并比较该分配次数和预设次数的大小。其中,预设次数可为设置的合适的次数,比如可为3次或5次等。
当出现被分配次数达到预设次数的任务时,还未接收到任务处理成功的任务处理结果,产生的原因可能为任务本身出现问题,难以被成功处理。因此,可判定该任务被多次处理失败,则可终止对该任务的重新分配,将该任务的状态设置为处理异常的状态。
在一个实施例中,服务器可汇总每个被设置为处理异常的状态的任务信息,将该任务信息发送至对应的管理员终端,使相应的管理员对该任务进行进一步地检测。具体地,可按照预设的汇总频率进行汇总,比如按照每小时一次的频率进行汇总。
本实施例中,通过设置预设次数,可防止任务被无限地重新分配处理,以浪费终端和服务器的资源。
在一个实施例中,上述的方法还包括:统计每个终端完成的任务数量,根据完成的任务数量对终端进行排序。
服务器可统计在预设时间段内,每个终端完成的任务数量。具体地,可根据所接收到的任务处理请求中携带的终端标识,统计具有相同终端标识的终端所反馈的任务处理成功的任务处理结果的数量。其中,该终端标识可为用户名等可唯一识别终端身份的信息。
比如可按周或者天为单位,统计每天或每周之内,每个终端完成的任务数量,并根据完成的任务数量进行排序。其中,排序信息中包括终端标识、完成的任务数量以及排名等信息。
本实施例中,通过对每个终端完成的任务数量进行排序,使得每个终端之间形成一种竞赛关系,具有互动性,可提高终端用户参与任务处理的积极性呵和数量,以进一步提高了对任务处理效率。
进一步地,可将排序信息发送至对应的终端,使得终端可获知其在预设时间段内完成的任务数量以及排名。更进一步地,服务器还可从排序中选取中排序超过预设名次的、或者完成的任务数量超过预设数量的终端,并向每个终端广播对所选取的终端的奖励信息,以进一步提高每个终端用户参与任务处理的积极性。
在一个实施例中,上述的任务为Crash解析任务。如图3所示,为一个实施例中对Crash解析任务的分布式处理方法的应用环境图,包括服务器110,终端120,数据库130以及Crash解析平台。其中,服务器110中包含主服务器112以及备用服务器112,数据库同样包含主数据库132以及备用数据库134。Crash解析平台为Crash数据提供者,Crash解析任务需要获取和上传Crash文件,该Crash解析平台负责提供Crash源数据并接收解析后的结果上传。每个终端120均可向服务器110发送任务处理请求,服务器110根据所接收到的任务处理请求,从数据库130中选取至少一个待分配状态的任务,通过与该终端110所定义的接口,分配给该终端110,该接口可为http实现的接口。终端110接收服务器110发送的任务信息,并与Crash平台进行交互,以实现对Crash的解析处理。终端110将任务处理结果发送至服务器110,服务器110根据任务处理结果修改对应任务的任务状态,从而实现了对Crash解析任务的处理。
在一个实施例中,如图4所示,提供了另一种任务分布式处理方法,该任务为Crash解析任务。该方法包括:
步骤S401,终端向服务器发送任务处理请求,任务处理请求中携带终端的互联网协议地址。
本实施例中,该任务处理请求为Crash解析任务的任务处理请求。进一步地,可为IOS Crash解析任务的任务处理请求,终端为部署了Mac OSX***的终端,比如为Mac笔记本或Mac台式电脑等。
服务器可预先或实时生成了多个Crash解析任务,并将该写入主数据库以及备用数据库中。同时对所生成的Crash解析任务设置任务标识以及设置任务状态为待分配状态。其中,Crash解析任务中包含待解析的Crash文件。具体地,可提供接口和web页面创建任务,从而可接收终端通过该接口和web页面创建的Crash解析任务。
在一个实施例中,服务器可将多个Crash文件封装成一个压缩包,并将多个压缩包封装成一个Crash解析任务,从而使得分配给终端的一个Crash解析任务中包含多个待解析的Crash文件,从而可提高了Crash文件的分配处理效率。
在一个实施例中,终端可检测自身是否处于空闲状态,若是,则向服务器发送任务处理请求。其中空闲状态是指包括CPU利用率低于预设利用率、内存占用率低于预设占用率的状态。其中,预设利用率和预设占用率可设置为任意合适的数值,比如可均为50%。通过在处于空闲状态时,才发送任务处理请求,可降低处理任务对终端的正常工作造成影响。
步骤S402,服务器接收该任务处理请求,选取至少一个待分配状态的任务,根据互联网协议地址,将选取的任务分配给终端进行处理。
具体地,服务器可任务生成的时间顺序来进行选取预设数量的待分配的任务的任务标识,并优先从主数据库中查询该任务标识所对应的任务。读取所查询出的任务,并按照任务处理请求中携带的终端的IP地址,将其发送至对应的终端,使终端进行任务处理。在一个实施例中,服务器可预设用于存放待分配任务的第一任务表,该表中可按任务的生成顺序来存储待分配任务的任务信息。具体地,可存储任务的任务标识。根据终端的任务处理请求,按照生成顺序从该表中选取还未分配的任务的任务标识。根据该任务标识从主数据库中读取对应的任务信息。其中,当从主数据库中读取失败时,可从备用数据库中读取该任务。
在一个实施例中,该服务器可为一个服务器集群,包含主服务器和备用服务器。可默认调用主服务器进行任务分配和监控等处理,当检测到主服务器处理出现故障时,可调用备用服务器进行任务分配和监控等处理。
在一个实施例中,在将选取的任务分配给终端进行处理之后,还包括:将已分配的任务的状态修改为处理中。进一步地,可分配任务的数据库逻辑设置事务隔离,从而避免将同一个任务分配给了多个终端而重复执行的情况发生。
在一个实施例中,可将该任务从第一任务表中移动到用于存放处理中的第二任务表中,或者直接在第一任务表中将该任务的任务状态标记为处理中的任务状态。
步骤S403,终端接收服务器分配的任务,通过Crash解析平台对该任务进行处理,将任务处理结果发送至服务器。
本实施例中,终端在接收到服务器分配的任务后,可通过与Crash进行交互,从而实现对任务中的每个Crash文件的解析处理,生成任务处理结果并发送至服务器。其中,该任务处理结果中可包含每个Crash文件的处理结果。处理结果包括处理成功和处理失败。
在一个实施例中,终端还可按照预设的频率向服务器发送心跳包,以告知终端正在进行任务的解析处理。
步骤S404,服务器检测是否在预设时长之内接收到任务处理结果,若是,则执行步骤S405,否则,执行步骤S406。
本实施例中,服务器可在将选取的任务分配给终端进行处理之后,则开始统计任务的处理时长,若在预设时长之内接收到任务处理结果。任务处理结果中包含对应的任务标识,使得服务器可根据该任务标识任务处理结果所属的任务。
服务器可提取将所有状态为处理中,且分配时间距离当前时间已经超出预设时长的任务,然后重置该任务的状态为待分配。预设时长可根据经验值设定,假设一个任务正常执行时间为2分钟,最长执行时间为5分钟,则可设置预设时长为6分钟或者8分钟。
步骤S405,根据任务处理结果修改对应任务的任务状态。
步骤S406,将选取的任务重新分配给其它发送任务处理请求的终端进行处理。
具体地,若任务状态为处理失败,则将该任务再修改为待分配的状态,并再次存放入第一任务表中,以进行重新分配。若任务状态为处理成功,则将该任务存放入用于存储处理成功的第三任务表中。若任务状态为处理异常,则将该任务存放如用于存储处理异常的第四任务表中。其中,每个任务表中均包含对应任务的任务标识,以便于服务器可定时根据第四任务表记录的任务标识,从主数据库或备用数据库中读取对应的任务信息,发送至管理员终端,使管理员进行检测。
在一个实施例中,终端可设置多个线程来进行任务分配请求与处理。比如可设置2个线程,每个线程均在循环地“任务请求->执行->处理结果上报->休息预设时长”,从而提高终端的利用率和任务处理效率。
上述的任务分布式处理方法,通过将终端作为DTS***中的执行节点,将任务分配给多个终端进行处理,可缓解服务器对任务处理的压力,提高了对任务处理的效率。
在一个实施例中,如图5所示,提供了一种任务分布式处理装置,该装置应用于分布式任务调度***中的,包括:
请求接收模块502,用于接收终端发送的任务处理请求,所述终端为所述分布式任务调度***中的执行节点。
任务分配模块504,用于选取至少一个待分配状态的任务,将选取的任务分配给终端进行处理。
任务状态修改模块506,用于接收终端反馈的任务处理结果;根据任务处理结果修改对应任务的任务状态。
在一个实施例中,任务分配模块504还用于选取至少一个待分配状态的任务标识;从主数据库中读取每个任务标识对应的任务,当从主数据库读取失败时,从备用数据库中读取每个任务标识对应的任务。
在一个实施例中,任务处理请求中携带终端的互联网协议地址;任务分配模块504还用于根据互联网协议地址,将选取的任务分配给终端进行处理。
在一个实施例中,任务状态修改模块506还用于接收终端发送的心跳包,以根据心跳包确定终端正在处理选取的任务。
在一个实施例中,任务分配模块504还用于检测是否在预设时长之内接收到任务处理结果,若否,则将选取的任务重新分配给其它发送任务处理请求的终端进行处理。
在一个实施例中,如图6所示,该装置还包括:
排序模块508,用于统计每个终端完成的任务数量,根据完成的任务数量对终端进行排序。
上述任务分布式处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。其中,网络接口可以是以太网卡或无线网卡等。上述各模块可以硬件形式内嵌于或独立于服务器中的处理器中,也可以以软件形式存储于服务器中的存储器中,以便于处理器调用执行以上各个模块对应的操作。该处理器可以为中央处理单元(CPU)、微处理器、单片机等。
在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现一种任务分布式处理方法,所述方法应用于分布式任务调度***中,所述分布式任务调度***包括服务器和多个终端,所述服务器为所述分布式任务调度***中的主控节点,每个所述终端为所述分布式任务调度***中的执行节点,所述处理器执行所述指令时实现上述各个实施例所提供的任务分布式处理方法的步骤。
具体地,该指令被处理器执行时实现以下步骤:接收终端发送的任务处理请求;选取至少一个待分配状态的任务,将选取的任务分配给终端进行处理;接收终端反馈的任务处理结果;根据任务处理结果修改对应任务的任务状态。
在一个实施例中,所实现的选取至少一个待分配状态的任务,包括:选取至少一个待分配状态的任务标识;从主数据库中读取每个任务标识对应的任务,当从主数据库读取失败时,从备用数据库中读取每个任务标识对应的任务。
在一个实施例中,任务处理请求中携带终端的互联网协议地址;所实现的将选取的任务分配给终端进行处理,包括:根据互联网协议地址,将选取的任务分配给终端进行处理。
在一个实施例中,在将选取的任务分配给终端进行处理之后,包括实现以下步骤:接收终端发送的心跳包,以根据心跳包确定终端正在处理选取的任务。
在一个实施例中,在将选取的任务分配给终端进行处理之后,包括实现以下步骤:检测是否在预设时长之内接收到任务处理结果,若否,则将选取的任务重新分配给其它发送任务处理请求的终端进行处理。
在一个实施例中,还包括实现以下步骤:统计每个终端完成的任务数量,根据完成的任务数量对终端进行排序。
在一个实施例中,提供了一种应用于分布式任务调度***中的服务器,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述分布式任务调度***包括所述服务器和多个终端,所述服务器为所述分布式任务调度***中的主控节点,每个所述终端为所述分布式任务调度***中的执行节点,处理器执行程序时实现上述各个实施例所提供的任务分布式处理方法的步骤。
具体地,该处理器执行程序时实现以下步骤:接收终端发送的任务处理请求;选取至少一个待分配状态的任务,将选取的任务分配给终端进行处理;接收终端反馈的任务处理结果;根据任务处理结果修改对应任务的任务状态。
在一个实施例中,如图7所示,为一个实施例中服务器的内部结构示意图。该服务器包括通过***总线连接的包括通过***总线连接的处理器、存储器和网络接口。其中,该服务器的处理器用于提供计算和控制能力,支撑整个终端的运行。存储器用于存储数据、指令代码等,网络接口用于与终端进行网络通信。比如,可向终端发送所选取的任务等。存储器上存储至少一个计算机可执行指令,该计算机可执行指令可被处理器执行,以实现本申请实施例中提供的适用于服务器的任务分布式处理方法。存储器可包括磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)等非易失性存储介质,或随机存储记忆体(Random-Access-Memory,RAM)等。例如,在一个实施例中,存储器包括非易失性存储介质及内存储器。服务器的非易失性存储介质存储有操作***和计算机可执行指令。该计算机可执行指令可被处理器所执行,以用于实现以上各个实施例所提供的任务分布式处理方法。终端中的内存储器为非易失性存储介质中的操作***、数据库和计算机可执行指令提供高速缓存的运行环境。网络接口可以是以太网卡或无线网卡等,用于与外部的终端或服务器进行通信。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。本领域技术人员可以理解,图7中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的服务器的限定,具体的服务器可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
在一个实施例中,所实现的选取至少一个待分配状态的任务,包括:选取至少一个待分配状态的任务标识;从主数据库中读取每个任务标识对应的任务,当从主数据库读取失败时,从备用数据库中读取每个任务标识对应的任务。
在一个实施例中,任务处理请求中携带终端的互联网协议地址;所实现的将选取的任务分配给终端进行处理,包括:根据互联网协议地址,将选取的任务分配给终端进行处理。
在一个实施例中,在将选取的任务分配给终端进行处理之后,包括实现以下步骤:接收终端发送的心跳包,以根据心跳包确定终端正在处理选取的任务。
在一个实施例中,在将选取的任务分配给终端进行处理之后,包括实现以下步骤:检测是否在预设时长之内接收到任务处理结果,若否,则将选取的任务重新分配给其它发送任务处理请求的终端进行处理。
在一个实施例中,还包括实现以下步骤:统计每个终端完成的任务数量,根据完成的任务数量对终端进行排序。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一非易失性计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)等。
以上所述实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本发明的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。