任务管理器的设计简述

  

  任务管理器的设计简述”>
  <p>讲解任务管理器之前,在这里先介绍一些任务管理器会使用到的概念术语。</p>
  <p>图数据库星云图中存在一些长期在后台运行的任务,我们称之为工作。存储层存在的DBA使用的部分指令,比如:数据完成导入后,想在全局做一次压实,都是工作范畴。</p>
  <p>作为一个分布式的系统,星云图中工作由不同的蓄能完成,而我们管一个蓄能上运行的工作子任务叫做Task.Job的控制由metad上的作业管理器负责,而任务的控制由含水层上的任务管理器负责。</p>
  <p>在本文中,我们着重讲述如何对长耗时的任务进行管理与调度进一步提升数据库性能。</p>
  <h3 id=      任务管理器要解决的问题   

上文说到含水层上的任务管理器控制的任务是元控制的工作的子任务,那任务管理器它自己具体解决什么问题呢?在星云图中任务管理器主要解决了以下2个问题:

  
      <李>将之前通过HTTP的传送方式改为RPC(节俭)   
    一般用户在搭建集群时,知道极高之间通信使用节俭协议,会为节俭所需端口开放防火墙,但是可能意识不到星云图还需要使用HTTP端口,我们遇到过多次社区用户实践忘记开放HTTP端口的事情。   <李>含水层对于任务有调度能力   
    这块内容将在本文下面章节展开讲述。
  

     任务管理器体系中的元

  

在任务管理器体系中,metad (JobManager)的任务是根据graphd中传过来的一个工作要求,选出对应的蓄能主机,并拼组出任务请求发给对应的蓄能。不难发现,体系中元接受工作要求,拼组任务请求,发送任务请求及接受任务返回结果,这些逻辑的套路是稳定的。而如何拼组TaskRequest,将任务请求发给哪些蓄能则会根据不同的工作有所变化.JobManager用   <代码>模板策略> 简单工厂>   

  任务管理器的设计简述”>
  <p>让未来的工作同样继承于MetaJobExecutor,并实现准备()和执行()方法即可。</p>
  <h3 id=      任务管理器的调度控制   

  任务管理器的设计简述”>
  <p>之前提到的,任务管理器的调度控制希望做到2点:</p>
  <ul>
  <李>系统资源足够时,尽可能的高并发执行任务</李>
  <李>系统资源吃紧时,让所有运行中占的任务用的资源不要超过某一个设定的阈值。</李> </ul>
  <h4 id=      高并发执行任务   

任务管理器将系统资源中自己持有的线程称之为Worker.Task经理有一个现实中的模拟原型——银行的营业厅。想象一下,我们去银行办业务时会有以下几步:

  
      <李>场景1:在门口的排号机拿一个号   <李>场景2:在大厅找个位置,边玩手机边等叫号   <李>场景3:等叫到号时,到指定窗口办理李
  

同时,你还会碰到这样那样的问题:

  
      <李>场景4:贵宾可以插队李   <李>场景5:你可能排着队,因为某些原因,放弃了本次业务李   <李>场景6:你可能排着排着队,银行就关门了
  

那么,整理一下,这也就是任务管理器的基本需求

  
      <李>任务按FIFO顺序执行:不同的任务有不同的优先级,高优先级的可以插队李   <李>用户可取消一个排队中任务的李   <李>蓄能随时关闭李   <李>一个任务,为了使其尽可能高的并发,会被拆分为多个子任务、子任务是每个工人真正执行的任务李   <李>任务管理器是全局唯一实例,要考虑多线程安全性李
  

于是,有了如下实现:

  
      <李>实现1:用节俭结构中的JobId和TaskId,确定一个任务,称为任务处理。   <李>实现2:TaskManager会有一个阻塞队列,负责让任务的处理排队执行(排号机),而阻塞队列本身线程安全。   <李>实现3:阻塞队列同时支持不同的优先级,高优先级先出队(VIP插队的功能)。

    任务管理器的设计简述