集群式的任务调派系统的制作方法
【技术领域】
[0001]本申请涉及一种网络服务的任务调派系统，具体涉及一种集群式的任务调派系统。
【背景技术】
[0002]随著网络速度高速的提升，也带动网路服务的多样性。而网路服务的背后是由硬件与软件的搭配所实现的。硬件方面则是服务器的架构、资源或运算能力等。软件方面则是任务分配和资源调度等演算机制所实现。
[0003]目前，比较流行的任务调度平台包括基于Quartz、基于Redis存储任务队列数据、使用crontab命令、基于Mapduce计算框架、IBM MQ消息队列等。这些调度平台均存在一些缺陷:Quartz的单机版单进程应用，一旦发生宕机的情况，无法确保任务正确被触发，在任务数量过高时会产生内存溢出的风险，执行效率低，容错性差，不存在故障切换的机制。从Redis中读取任务队列数据时，由于各任务处理程序间争夺数据可能导致死锁。crontab配置都是单独的写在对应的服务器上，随着服务的细化及任务数量的增加，对计划任务的管理越来越复杂。且crontab对正在运行的计划任务并没有合理的监控机制。当服务器宕机或者停电无法将原有任务转移到其他服务器完成。Mapduce计算框架是属于离线批处理系统，Mapduce计算框架的数据必须先存储，才能运算，存储和运算不能并行运行，不支持实时处理。
【发明内容】
[0004]本申请所要解决的技术问题在于提供集群式的任务调派系统，其特征在于包括指令调派平台、多个JVM容器与至少一JVM容器。指令调派平台是由多台任务服务器透过网络相互连接，于这些任务服务器中部署zookeeper服务，zookeeper服务根据任务要求返回运行指令;每一 JVM容器用于运行一业务服务，不同的运行指令对应存在JVM容器与所属的业务服务;至少一节点服务器，节点服务器用于接收任务要求，节点服务器接收来自于指令调派平台的运行指令或传送发送指令至指令调派平台，每一节点服务器设置节点编号、集群编码与位址资讯，节点服务器根据任务搜寻相应业务的这些JVM容器，由所搜寻的这些JVM容器向指令调派平台取得运行指令;节点服务器判断取得运行指令的JVM容器的负载状态是否为空闲或忙碌，若负载状态为空闲，则JVM容器根据运行指令对任务要求进行处理，若负载状态为忙碌，则节点服务器把运行指令暂存于等待队列中。
[0005]与现有技术相比，本申请基于Zookeeper分布式应用程序协调服务，可针对不断增加的任务数量，越来越细化的任务内容，越来越复杂的任务管理的情况下获得包括以下技术效果:
[0006]I)多服务器任务调度，不同业务分布在不同服务器上执行，当任务数量过高时，可以并发地执行，提高执行效率。集群方式存储指令，如果其中的一台服务器坏掉，能保证其他服务器提供不间断的服务，不会因为一台坏掉的服务器，而导致整个系统崩溃，确保在执行过程中可靠、稳定。
[0007]2)当有新的任务需要执行时，可以手动增加配置节点容器的相关属性，扩展平台的操作指令，进一步细化服务内容。同时调度程序可以通过容器名称，到Zookeeper指令存储库中取指令，然后根据指令内容选择相应容器进行操作，不会因为争夺资源而造成系统的不可用。
[0008]3)可以实时地对正在运行的任务、异常任务进行监控，随时启停、忽略或者重新运行任务。
[0009]4)任务运行之前，可以对不同来源、格式和特点的数据进行抽取、转换、加载，放到等待队列中，减少错误数据的存储空间。
[0010]当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有技术效果。
【附图说明】
[0011]此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。
[0012]图1为本申请的集群式的任务调派系统的架构示意图。
[0013]图2为本申请的指令调派平台的各模块的业务示意图。
[0014]图3为本申请的FastLeaderElect1n的运作流程图。
[0015]图4为本申请的zookeeper服务配置的运作流程图。
[0016]图5为本申请的指令调派平台的各模块的业务示意图。
【具体实施方式】
[0017]以下请配合附图及实施例来详细说明本申请的实施方式，藉此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。
[0018]请参考图1A与图1B所示，其系为本申请的集群式的任务调派系统的架构示意图与主从任务服务器示意图。本申请的集群式的任务调派系统包括指令调派平台110、至少一节点服务器120与JVM容器130。指令调派平台110是由多台任务服务器111透过网络相互连接，于这些任务服务器111中部署zookeeper服务112，zookeeper服务112根据任务要求返回运行指令。节点服务器120可配置多个JVM容器130。每一 JVM容器130用于运行一业务服务，不同的运行指令对应存在JVM容器130与所属的业务服务。节点服务器120用于接收任务要求，节点服务器120接收来自于指令调派平台110的运行指令或返回发送指令至指令调派平台110。每一节点服务器120设置节点编号、集群编码与位址资讯。节点服务器120根据任务搜寻相应业务的JVM容器130，由所搜寻的JVM容器130向指令调派平台110取得运行指令。后台操作者可以根据新的任务，手动增加节点服务器120的数量与相关属性。
[0019]指令调派平台110提供zookeeper服务112、消息队列的存储或消息处理服务等。指令调派平台110可以透过分布式ETL(Extract, transform and load，简称ETL)系统所实现。为能区别实体机器与服务的差异，在图中实线直角方块代表所提供的服务，而实线钝角方块代表实体机器。
[0020]这些任务服务器111更依照功能被区分为监控模块1111、核心模块1112、插件模块1113与元数据管理模块1114。请配合图2所示，其系为本申请的指令调派平台的各模块的业务示意图。监控模块1111用于监控该指令调派平台110的运行程序是否异常，特别是服务器运行间异常监控与运行时的历史查询。
[0021]核心模块1112用于调度控制指令与该些任务服务器111间的消息传递与异常管理与日志管理。核心模块1112用於查詢节服務器相匹配的JVM容器130，並於zookeeper服务112中獲取指令，再把指令放入等待等待队列中。核心模块1112也可以判断当前任务是否完成。如果任务完成，核心模块1112结束本次调度。否则，核心模块1112打包指令，核心模块1112把指令存入zookeeper服务112中，等待获取下一步操作。元数据管理模块1114用于节点配置、运行容器的配置、外部资源的配置、业务场景的配置、ETL步骤配置、JAR包版本管理。
[0022]插件模块1113用于服务器之间的文件传输、文件到库，库到库，库到文件、文件发现、文件传输、数据处理、Kettle处理、流式计算(Stream Computing)与文件入库。插件模块1113用于实时监控远程FTP服务器，通过文件的路径，定时扫描。插件模块1113根据文件的修改时间是否发生变化来判断远程FTP服务器上的文件是否有变动。如果有变动则取出放入数据库，由插件模块1113调度指令确定下一步操作。如果没有变动，则插件模块1113继续监控。插件模块1113用于本地服务器之间、本地服务器和远程服务器之间的数据传递(上传、下载等)。
[0023]其中，传输协议包含文件传输协议(File Transfer Protocol，FTP)、安全文件传输协议(Secure File Transfer Protocol，SFTP)和流控制传输协议(Stream ControlTransmiss1n Protocol, SCTP)。插件模块1113也用于处理文件，对数据进行筛选、合并、统计等业务逻辑处理。Kettle处理，调用第三方开源的ETL工具(Kettle)进行数据处理。KettIe分为4大块:Chef、Kitchen、Spoon与Span。Chef—工作(job)设计工具(GUI方式)、Kitchen一工作(job)执行器(命令行方式)；Spoon—转换(transform)设计工具(GUI方式)；Span—转换(trasf orm)执行器(命令行方式)。在官网下载Ket11e压缩包，解压，执行以下脚本:cd Kettle ； chmod+x*.sh;启动图形用户界面Spoon，创建资源库，设计、运行转换和作业。
[0024]指令调派平台110除了提供前述的服务外，另部署zookeeper服务112C3Zookeeper服务112用于从多台任务服务器111中选出一台作为主任务服务器211，其馀未选上则为从任务服务器212。若要部署zookeeper服务112且对外网提供服务，则需要过半数的任务服务中是可正常运行并且能相互通信。换言之，于存在X台任务服务器111的情况下，必须部署大于(1+X/2)台的任务服务器