CN107423121B

CN107423121B - Gnss精密后处理任务的调度系统及方法

Info

Publication number: CN107423121B
Application number: CN201710302579.0A
Authority: CN
Inventors: 汤军; 常维; 李慧艳
Original assignee: Chihiro Location Network Co Ltd
Current assignee: Chihiro Location Network Co Ltd
Priority date: 2017-05-02
Filing date: 2017-05-02
Publication date: 2020-12-01
Anticipated expiration: 2037-05-02
Also published as: CN107423121A

Abstract

本发明提供了一种GNSS精密后处理任务的调度系统，包括任务调度模块、Zookeeper、解算服务器、监测点网关、数据中心、状态管理模块和数据库；任务调度模块接收后处理任务管理系统发送的调度请求，并存储至Zookeeper；解算服务器对Zookeeper节点进行监听；数据库存储任务调度模块的任务信息和解算服务器的解算结果；状态管理模块检查解算服务器的心跳，在某个解算服务器发生异常时，将服务器上的任务迁移到其他解算服务器；监测点网关接收监测点观测数据上报，并将观测数据存储至数据中心；星历服务模块将星历文件存储至数据中心；参考站将观测数据存储至数据中心；解算服务器根据任务配置从数据中心拉取数据。

Description

GNSS精密后处理任务的调度系统及方法

技术领域

本发明涉及全球卫星导航系统(GNSS，Global Navigation Satellite System)技术领域，特别涉及一种GNSS精密后处理任务的调度系统及方法。

背景技术

所谓GNSS精密后处理，即通过对静态监测点观测数据、参考站观测数据、星历进行后处理解算，得到监测点毫米精度的一种高精度卫星定位技术。GNSS精密后处理主要用于静态监测点毫米精度的坐标解算。行业内在房屋、桥梁、矿区的形变监测等领域得到了广泛的应用。

对于GNSS精密后处理任务，现有业界通用方案是单机解决方案：完成监测点观测数据收集、星历准备、解算任务配置、解算、解算结果存储。图1是目前业界通用方案是在单台Windows服务器上完成整个精密后处理任务从数据接入到解算的所有流程，具体如下：

1、监测点的观测数据以特定协议(如TCP+RTCM32)协议经过负载均衡转发后发送到数据流转发模块。

监测点：作为卫星接收机，连续观测卫星定位数据，用于后续进行精密后续处理，得到高精度位置。

RTCM：海运事业无线电技术委员会(Radio Technical Committee for MarineServices)制定的用于卫星导航及无线电通信的协议标准。

2、参考站的观测数据以特定协议(如TCP+RTCM32)发送至数据流转发模块。

参考站：连续接收和发送本站坐标及其变化，GNSS星历，星钟差等信息的地面固定站，用于纠正在卫星定位中产生的公共误差。

3、广播星历及精密星历以文件方式发送至数据落地模块。

星历：星历是指在GPS测量中，天体运行随时间而变的精确位置或轨迹表，它是时间的函数。

4、数据流转发模块将所有数据流进行汇总，并定时转换成文件。

5、新增单个监测点：

a)接入监测点观测数据；

b)配置监测点解算使用的参考站；

c)配置解算频率；

d)配置解算使用的数据弧段长度；

e)如果多个监测点则重复a)-d)。

6、解算服务根据配置定时对所有监测点进行解算(解算元数据包括监测点、参考站、星历)。

7、解算任务完成后，结果转储模块将解算结果转储至数据库(通常是mysql)。

现有技术存在以下问题：

1、解算任务配置过程繁琐

新增监测点通常需要手动在界面为其配置参考站、解算频率、数据弧段等。当监测点数目增加时，这样的配置操作对于运维人员来说是噩梦，同时也容易配置错误。

2、解算任务存在单点风险

Windows服务器发生宕机甚至是不可逆的机械故障时，该服务器上的所有解算任务都受到影响。只能通过将机器上的任务手动迁移到其他机器，重新配置进行解算。这个过程耗费的时间通常很久，解算的结果会出现数据丢失，这对于危房监测等业务来说是致命的。

3、无法定向扩容

现有技术通常是基于单机的解决方案，在业务扩展时通常是对整体解决方案在新的机器进行扩容。当检测点数目达到十万、百万，甚至是千万级别时，扩容所耗费的人力物力巨大。另外，不能对解算模块进行单独扩容，导致计算资源大部分被浪费了。

4、整体性能低。

发明内容

本发明提出一种GNSS精密后处理任务的调度系统及方法，解决了以下技术问题：

1、使后处理任务在机器发生机械故障时，可以进行任务迁移。对解算任务没有任何影响，不出现数据丢失，且对外部运维透明。

2、支持定向扩容，单独对解算服务进行扩容。

本发明采用的技术方案是：

一种GNSS精密后处理任务的调度系统，其特征在于，包括任务调度模块、Zookeeper、至少一个解算服务器、状态管理模块和数据库；任务调度模块接收后处理任务管理系统发送的调度请求，并存储至Zookeeper；解算服务器对Zookeeper节点进行监听；数据库存储任务调度模块的任务信息和解算服务器的解算结果；状态管理模块检查解算服务器的心跳，并将任务迁移到任务调度模块。

进一步地，所述调度系统还包括监测点网关、数据中心；监测点网关接收监测点观测数据上报，并将监测点观测数据存储至数据中心；星历服务模块将星历文件存储至数据中心；参考站将参考站观测数据存储至数据中心；解算服务器从数据中心拉取监测点观测数据、星历文件和参考站观测数据。

一种GNSS精密后处理任务的调度方法，包括任务调度流程，步骤如下：

步骤S11，后处理任务管理系统接收用户解算任务的调度请求，然后将调度请求发送给任务调度模块；

步骤S12，任务调度模块查询数据库，获取当前解算服务器的状态以及负载的任务个数；

步骤S13，判断是否有空闲的解算服务器，如否，执行步骤S13a；如是，执行步骤S13b；

步骤S13a，终止调度请求，对解算服务器进行扩容；

步骤S13b，将解算任务分配至解算服务器，执行步骤S14；

步骤S14，任务调度模块为解算任务配置解算参数，将解算任务的解算元数据存储至Zookeeper节点，并对解算任务在Zookeeper节点进行管理；

步骤S15，解算服务器对Zookeeper节点进行监听，当Zookeeper节点下新增任务节点或者Zookeeper节点发生更新时，获取任务元数据；

步骤S16，判断是新建还是更新任务，如是新建任务，执行步骤步骤S16a；如是更新任务，执行步骤S16b；

步骤S16a，根据任务元数据，启动后处理解算任务；

步骤S16b，根据任务元数据，更新解算任务。

进一步地，通过将解算服务器的IP加入任务调度模块的服务器列表完成对步骤S13a中解算服务器的扩容。

进一步地，所述步骤S13b中，通过以下任一一种调度策略将解算任务分配至解算服务器：

调度策略1，选择当前解算任务数量最少的解算服务器；

调度策略2，将解算任务复制到所有解算服务器，所有解算服务器获得相同的解算任务；

调度策略3，选择CPU或者内存使用最少的解算服务器。

进一步地，步骤S14中解算任务在Zookeeper节点的管理按照解算服务器的IP进行组织。

进一步地，所述步骤S14中解算元数据包括参考站观测数据、监测点观测数据和星历文件。

进一步地，所述调度方法还包括任务迁移流程，步骤如下：

步骤S21，解算服务器定时发送心跳信息；

步骤S22，状态管理模块接收心跳信息，更新解算服务器的心跳时间；

步骤S23，状态管理模块定时检查所有解算服务器的心跳时间，判断是否需要进行任务迁移，如果收到解算服务器的心跳，则不需要进行任务迁移，执行步骤S23b；如果没有收到解算服务器的心跳，则需要进行任务迁移，执行步骤S23a；

步骤S23b，返回，不做处理；

步骤S23a，任务调度模块查询解算服务器的所有解算任务，执行步骤S24；

步骤S24，任务调度模块取消所有查询到的解算服务；

步骤S25，使用任务调度模块将取消的解算任务重新分配到其余解算服务器。

本发明的有益效果在于，使后处理解算任务配置过程简单、易操作，提高了数据的安全性，减少计算资源浪费。

附图说明

图1是现有技术流程图。

图2是本发明系统架构图。

图3是本发明任务调度流程图。

图4是本发明任务迁移流程图。

具体实施方式

下文中，结合附图和实施例对本发明作进一步阐述。

图2为本发明系统架构图，具体如下：

监测点网关1：通常是以特定协议(如TCP或者NTRIP(通过互联网进行RTCM网络传输的协议，Networked Transport of RTCM via Intemet Protocol))接受监测点8观测数据上报，以一定频率(通常15分钟)落地为Rinex(Receiver Independent ExchangeFormat，与接收机无关的交换格式)文件，并存储至数据中心2。

可选地，监测点网关1替换为任何可以接收监测点8观测数据并落地文件的服务。

数据中心2：通常为分布式文件存储(如NFS-Network File System，网络文件系统)，主要存储三部分解算元数据文件：a)监测点8观测数据；b)参考站10观测数据；c)星历服务模块9的星历文件。解算服务器5拉取数据中心2的解算元数据。

可选地，数据中心2替换为任何存储文件的分布式存储模块。

任务调度模块3：当新增解算任务时，任务调度模块3负责以一定的策略(通常是任务均分)将该解算任务分配至合适的解算服务器5；同时在解算服务器5发生机械故障时，负责支持任务迁移。

Zookeeper4：一个分布式的，开放源码的分布式应用程序协调服务。在本发明中，Zookeeper4用以存储调度至各解算服务器5的解算任务。

可选地，Zookeeper4替换为任何存储任务元数据，同时具有通知功能的任务模块。

解算服务器5：监听自己所关心的Zookeeper4节点，并对解算任务的新建及更新做出响应。启动定时解算任务，拉取解算所需要的元数据，在完成解算后将解算结果落地到数据库7(通常是Mysql，一个关系型数据库管理系统)。

状态管理模块6：在本发明中，状态管理模块6用以辅助实现任务迁移。定时检查所有解算服务器5的心跳，并一定策略将宕机的解算服务器5上的解算任务迁移到其他解算服务器5，保证解算任务的正常。

数据库7：通常为Mysql，用于存储任务调度模块3的任务信息，以及所有解算任务的解算结果。

可选地，数据库7替换为任何关系数据库或者非关系数据库。

图3是本发明任务调度流程图，通常在新增后处理任务时，通过任务调度模块3以一定策略分配至合适的解算服务器5；同时在配置发生更新时，通过任务调度模块3更新至对应的解算服务器5，具体步骤如下：

步骤S11，后处理任务管理系统11接收用户新增或者更新解算任务的调度请求(通常为WEB UI(Website User Interfac，网络产品界面设计)或者API(ApplicationProgramming Interface，应用程序编程接口))，然后将调度请求发送给任务调度模块3。

步骤S12，任务调度模块3查询数据库，获取当前解算服务器5的状态以及每个解算服务器5已负载的任务个数。

步骤S13，判断是否有足够的解算服务器，如否(所有解算服务器5资源的任务个数都已到达上限(如500，由压力测试评估))，执行步骤S13a；如是(有空闲服务器可以供调度)，执行步骤S13b。

步骤S13a，终止调度请求，考虑对解算服务器5进行扩容。解算服务器5扩容仅需要将该解算服务器5的IP加入任务调度模块3的服务器列表即可。

步骤S13b，通过任务调度策略将解算任务分配至合适的解算服务器5，执行步骤S14。

步骤S14，Zookeeper4任务节点管理；任务调度模块3为解算任务配置合适的解算参数，并将解算任务的调度和解算参数等解算元数据存储至Zookeeper4合适的节点，对解算任务在Zookeeper4的节点进行管理。解算元数据如下：

a)以一定策略(如监测点就近原则)选取参考站10；

b)配置合适的解算频率(根据业务需求，一般为1小时、3小时、6小时、一天一次等)；

c)配置合适的数据弧段(根据业务需求，一般为6小时、12小时)。

步骤S15，解算服务器5监听其所关心的Zookeeper4节点，当Zookeeper4节点下新增任务节点或者Zookeeper4节点发生更新时，获取任务元数据。

步骤S16，判断是新建还是更新任务，如是新建任务，执行步骤步骤S16a；如是更新任务，执行步骤S16b。

步骤S16a，根据任务元数据，启动后处理解算任务。

步骤S16b，根据任务元数据，更新解算任务。

较佳地，所述步骤S13b中任务调度策略如下：

1、最少任务原则：选择当前任务数目最少的解算服务器5，将当前任务分配至该解算服务器5。

2、任务拷贝：将解算任务复制到所有的解算服务器5，所有解算服务器5获得相同的任务。(主要用于在测试阶段对不同版本解算服务进行对比测试)。

3、最少压力原则：选择当前压力最小(如CPU、内存使用最少)的解算服务器5。

较佳地，步骤S14中Zookeeper4任务节点管理如下：

1、解算任务在Zookeeper4的管理按照解算服务器5的IP进行组织，即任务在Zookeeper5的存储节点为：

/tasks/${server_ip}/${task_id}

其中，tasks为任务节点；${server_ip}为解算服务器5的IP；${task_id}为解算任务ID。该节点下存储了该解算任务的解算元数据(参考站观测数据、监测点观测数据和星历文件)。

2、如IP为127.0.0.1的解算服务器5监听节点：

/tasks/127.0.0.1

如当该节点下新增ID为1的task，或者更新了ID为2的task，该解算服务器5都能获取对应的解算元数据。

为了保证在解算服务器5发生宕机时对危房监测业务无影响，在需要时(如解算服务器5宕机)进行任务迁移，图4是本发明任务迁移流程图，具体步骤如下：

步骤S21，解算服务器5定时发送包含本服务器IP的心跳信息。

步骤S22，状态管理模块6接收心跳信息，更新解算服务器5的心跳时间。

步骤S23，状态管理模块6判断是否需要进行任务迁移，如否，执行步骤S23b；如是，执行步骤S23a；

状态管理模块6判断的策略如下：

状态管理模块6定时(如6小时)检查所有解算服务器5的心跳时间。如果在一段时间内(如6小时)收到解算服务器5的心跳，则不需要进行任务迁移；如果在一段时间内(如6小时)没有收到解算服务器5的心跳，则认为该解算服务器5已经出现无法恢复的故障，需要进行任务迁移。

步骤S23b，返回，不做处理。

步骤S23a，任务调度模块3查询该解算服务器5的所有解算任务，执行步骤S24。

步骤S24，任务调度模块3取消所有查询到的解算服务。

步骤S25，使用任务调度模块3将取消的这些解算任务重新分配到其他解算服务器5。

本发明对于计算机编程语言没有特别要求，优选采用JAVA语言。

本发明虽然已以较佳实施例公开如上，但其并不是用来限定本发明，任何本领域技术人员在不脱离本发明的精神和范围内，都可以利用上述揭示的方法和技术内容对本发明技术方案做出可能的变动和修改，因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化及修饰，均属于本发明技术方案的保护范围。

Claims

1.一种GNSS精密后处理任务的调度方法，其特征在于，包括任务调度流程，步骤如下：

步骤S11，后处理任务管理系统(11)接收用户解算任务的调度请求，然后将调度请求发送给任务调度模块(3)；

步骤S12，任务调度模块(3)查询数据库，获取当前解算服务器(5)的状态以及负载的任务个数；

步骤S13a，终止调度请求，对解算服务器(5)进行扩容；

步骤S13b，将解算任务分配至解算服务器(5)，执行步骤S14；

步骤S14，任务调度模块(3)为解算任务配置解算参数，将解算任务的解算元数据存储至Zookeeper(4)节点，并对解算任务在Zookeeper(4)节点进行管理；

步骤S15，解算服务器(5)对Zookeeper(4)节点进行监听，当Zookeeper(4)节点下新增任务节点或者Zookeeper(4)节点发生更新时，获取任务元数据；

步骤S16a，根据任务元数据，启动后处理解算任务；

步骤S16b，根据任务元数据，更新解算任务。

2.如权利要求1所述的一种GNSS精密后处理任务的调度方法，其特征在于，通过将解算服务器(5)的IP加入任务调度模块(3)的服务器列表完成对步骤S13a中解算服务器(5)的扩容。

3.如权利要求1所述的一种GNSS精密后处理任务的调度方法，其特征在于，所述步骤S13b中，通过以下任一一种调度策略将解算任务分配至解算服务器(5)：

调度策略1，选择当前解算任务数量最少的解算服务器(5)；

调度策略2，将解算任务复制到所有解算服务器(5)，所有解算服务器(5)获得相同的解算任务；

调度策略3，选择CPU或者内存使用最少的解算服务器(5)。

4.如权利要求1所述的一种GNSS精密后处理任务的调度方法，其特征在于，步骤S14中解算任务在Zookeeper(4)节点的管理按照解算服务器(5)的IP进行组织。

5.如权利要求1所述的一种GNSS精密后处理任务的调度方法，其特征在于，所述步骤S14中解算元数据包括参考站观测数据、监测点观测数据和星历文件。

6.如权利要求1所述的一种GNSS精密后处理任务的调度方法，其特征在于，还包括任务迁移流程，步骤如下：

步骤S21，解算服务器(5)定时发送心跳信息；

步骤S22，状态管理模块(6)接收心跳信息，更新解算服务器(5)的心跳时间；

步骤S23，状态管理模块(6)定时检查所有解算服务器(5)的心跳时间，判断是否需要进行任务迁移，如果收到解算服务器(5)的心跳，则不需要进行任务迁移，执行步骤S23b；如果没有收到解算服务器(5)的心跳，则需要进行任务迁移，执行步骤S23a；

步骤S23b，返回，不做处理；

步骤S23a，任务调度模块(3)查询解算服务器(5)的所有解算任务，执行步骤S24；

步骤S24，任务调度模块(3)取消所有查询到的解算服务；

步骤S25，使用任务调度模块将取消的解算任务重新分配到其余解算服务器(5)。