关于TbSchedule任务调度管理框架的整合部署1

一、前言

任务调度管理作为基础架构通常会出现于我们的业务系统中,目的是让各种任务能够按计划有序执行。比如定时给用户发送邮件、将数据表中的数据同步到另一个数据表都是一个任务,这些相对耗时的操作通过任务调度系统来异步并行执行,既能提高任务的执行效率又能保障任务执行的可靠性。

实现的方式也是多种多样,比如使用Timer进行简单调度或者使用Quartz类似的框架,本文基于淘宝开源框架TbSchedule实现,其设计目的是让批量任务或者不断变化的任务能够被动态的分配到多个主机的JVM中,在不同的线程组中并行执行,所有的任务能够被不重复,不遗漏的快速处理,目前被应用于阿里巴巴众多业务系统。

请参照http://code.taobao.org/p/tbschedule/wiki/index/,相关内容不再重复介绍,本文记录了详细的部署整合操作步骤。

二、Zookeeper部署

1、TbSchedule依赖于Hadoop Zookeeper组件,实现任务的分布式配置及各服务间的交互通信,Zookeeper以TreeNode类型进行存储,支持Cluster形式部署且保证最终数据一致性,关于ZK的资料网上比较丰富,相关概念不再重复介绍,本文以zookeeper-3.4.6为例,请从官网下载http://zookeeper.apache.org

2、创建ZookeeperLab文件夹目录,模拟部署3台Zookeeper服务器集群,目录结构如下。

3、解压从官网下载的zookeeper-3.4.6.tar文件,并分别复制到三台ZkServer的zookeeper-3.4.6文件夹。

4、分别在三台ZkServer的data目录下创建myid文件(注意没有后缀),用于标识每台Server的ID,在Server1\data\myid文件中保存单个数字1,Server2的myid文件保存2,Server3的myid保存3。

5、创建ZkServer的配置文件,在zookeeper-3.4.6\conf文件夹目录下创建zoo.cfg,可以从示例的zoo_sample.cfg 复制重命名。因为在同一台机器模拟Cluster部署,端口号不能重复,配置文件中已经有详细的解释,修改后的配置如下,其中Server1端口号2181,Server2端口号2182,Server3端口号2183。

 

6、通过zookeeper-3.4.6\bin文件夹zkServer.bat文件启动ZKServer,由于Cluster部署需要选举Leader和Followers,所以在3个ZKServer全部启动之前会提示一个WARN,属正常现象。

7、Zookeeper启动成功后可以通过zookeeper-3.4.6\bin文件夹的 zkCli.bat验证连接是否正常,比如创建节点“create /testnode helloworld”,查看节点“get /testnode”,连接到组群中其它ZkServer,节点数据应该是一致的。更多指令请使用help命令查看。

8、对于Linux环境下部署基本一致,zoo.cfg配置文件中data和datalog文件夹路径改为linux格式路径,使用“./zkServer.sh start-foreground”命令启动ZkServer,注意start启动参数不能输出异常信息。

9、至此Zookeeper的配置完毕。

三、SVN从TaoCode获取并Import TbSchedule源码(请先配置Maven环境)

四、TbSchedule控制台的部署

1、TbSchedule Console是基于web页面对调度任务配置、部署、监控的终端。

2、将源码目录下的console\ScheduleConsole.war包及depend-lib库部署到Web应用服务器,本文以Tomcat 7.0.54为例,相关步骤不再描述。

3、首次打开页面会跳转到“基础信息配置”Config.jsp页面,其中前2项为Zookeeper服务的连接配置,请正确填写前面部署的Zookeeper服务器地址和端口号,多个ZKServer可以使用逗号分隔。后3项是用于标识ZkServer中调度任务配置的根节点和节点权限,无严格要求。

4、点击保存后,会提示 “错误信息:Zookeeper connecting ......localhost:2181”,如果ZKServer配置正确可以不用理会,直接点击“管理主页”,若不能正常跳转到Index.jsp页面请重新检查Zookeeper的配置,建议关闭防火墙。

5、TbSchedule Console Web站点对应的两个地址

[监控页面]       http://localhost:8081/ScheduleConsole/schedule/index.jsp

[管理页面]       http://localhost:8081/ScheduleConsole/schedule/index.jsp?manager=true

如果以上地址能正常访问则TbSchedule Console的部署配置完成。

五、Task场景设计

1、假设场景:任务需要将订单表tbOrder中制单日期在20141201--20141208內(共8天)的数据同步到备份tbOrder_copy 表,其中每2天分为一个任务组并行同步(每次提取500条),关于任务组的划分和TbSchedule中TaskItem的相关概念请先参考wiki,后续也会有部分解释。

2、数据环境使用MySql数据库,创建tbOrder和tbOrder_Copy数据表,结构相同,同时在tbOrder事先生成好测试数据,建议每天的数据量在1000条以上。

六、数据同步任务实现

1、创建TaskCenter Demo Project,添加对tbschedule project的依赖,并集成Spring Framework。

2、创建OrderInfo实体类,属性对应tbOrder表,用于映射从数据表取的数据。

3、创建DataSyncABean任务类,实现IScheduleTaskDealSingle<T>泛型接口的selectTasks和execute方法,其中selectTasks方法用于取数,execute方法用于执行selectTasks返回的Result,关于代码中任务片段的划分和TbSchedule中TaskItem的相关概念后续再解释,代码参考如下。

 

4、在Spring容器中注册数据同步任务Bean。

 

5、Main函数初始化Spring容器和TbSchedule 任务管理Factory,连接ZKServer,代码如下,也可以参照TbSchedule源码中通过Spring进行初始化TBScheduleManagerFactory 。

 

6、如果配置正确应该可以成功启动该TaskDeal服务。

七、在TbSchedule Console创建调度任务(请事先仔细阅读wiki中的概念解释)

1、创建调度策略,其中“最大线程组数量”设置为4,表示在机器上的通过4个线程组并行执行数据同步任务。

2、创建调度任务

任务名称:对应调度策略中的任务名称,标识任务和策略的关联关系;

 任务处理的SpringBean:对应Demo TaskDeal服务Spring容器中的任务对象ID;

 

每次获取数据量:对应于bean任务类selectTasks方法参数 eachFetchDataNum;

执行开始时间:“0 * * * * ?” 表示每分钟的0秒开始,表达式同Quartz设置的Crontab格式,有工具可以生成,详细解释参照http://dogstar.iteye.com/blog/116130

 

 任务项:前面假设的任务场景中需要把1-8号数据按2天为1个任务组并行数据同步,所以可以把任务划分为1,2,3,4,5,6,7,8一共8个任务碎片,8个任务碎片被分配到4个线程组,那么每个线程组对应2个任务碎片,运行时任务项参数又被传递到bean任务类selectTasks方法的List<TaskItemDefine> queryCondition参数,例如第1个线程组调用selectTasks方法是queryCondition参数条件为1,2 ,第2个线程组执行参数条件为3,4,bean任务类中根据参数生成对应的BuildDate条件取数,并将结果提交到execute方法执行,从而实现并行计算。

任务项的划分:可以有非常多的分配策略和技巧,例如将一个数据表中所有数据的ID按10取模,就将数据划分成了0、1、2、3、4、5、6、7、8、9供10个任务项;将一个目录下的所有文件按文件名称的首字母(不区分大小写),就划分成了A、B、C、D、E、F、G、H、I、J、K、L、M、N、O、P、Q、R、S、T、U、V、W、X、Y、Z供26个任务项 。

3、新增任务配置保存后,Task会按指定的时间段自动开始执行,可以从TbScheduleConsole监视到对应的线程组和任务项。

4、同时可以从任务TaskDeal服务控制台监视到Debug输出的取数SQL和 Insert语句,以及TbSchedule的Heartbeat、TaskItem Debug信息。

 

5、至此同步任务配置完成,并且实现了模拟场景的要求。

八、以上也只是对TbSchedule的初步认识,更多高级应用仍然在探索中,欢迎交流。

九、向开源工作者和组织致敬,@xuannan  @kongxuan,感谢对开源事业作出的任何贡献。

时间: 2024-10-12 22:05:14

关于TbSchedule任务调度管理框架的整合部署1的相关文章

关于TbSchedule任务调度管理框架的整合部署

一.前言 任务调度管理作为基础架构通常会出现于我们的业务系统中,目的是让各种任务能够按计划有序执行.比如定时给用户发送邮件.将数据表中的数据同步到另一个数据表都是一个任务,这些相对耗时的操作通过任务调度系统来异步并行执行,既能提高任务的执行效率又能保障任务执行的可靠性. 实现的方式也是多种多样,比如使用Timer进行简单调度或者使用Quartz类似的框架,本文基于淘宝开源框架TbSchedule实现,其设计目的是让批量任务或者不断变化的任务能够被动态的分配到多个主机的JVM中,在不同的线程组中并

WebService与Spring整合部署

服务端(CXF发布webservice): 1.  http://cxf.apache.org/download.html下载 cxf文件包(3.1.18必须使用Java 7或Java 8). 2.  将下载包的lib文件夹下的jar全部拷贝到spring项目中的lib目录下,注意删除相同的jar包(版本号不同拷贝不会替换). 3.  删除以下4个jar包: cxf-services-ws-discovery-api-3.1.5.jar cxf-services-ws-discovery-ser

基于淘宝开源Tair分布式KV存储引擎的整合部署

一.前言 Tair支撑了淘宝几乎所有系统的缓存信息(Tair = Taobao Pair,Pair即Key-Value键值对),内置了三个存储引擎:mdb(默认,类似于Memcache).rdb(类似于Redis).ldb(高性能KV存储),其中前2者定位于cache缓存,ldb则定位于持久化存储.Tair属于分布式系统,由一个中心控制节点(Config Server)和一系列的服务节点(Data Server)组成,Config Server负责管理维护所有的Data Server状态信息.D

项目一:第十四天 1.在realm中动态授权 2.Shiro整合ehcache 缓存realm中授权信息 3.动态展示菜单数据 4.Quartz定时任务调度框架—Spring整合javamail发送邮件 5.基于poi实现分区导出

1 Shiro整合ehCache缓存授权信息 当需要进行权限校验时候:四种方式url拦截.注解.页面标签.代码级别,当需要验证权限会调用realm中的授权方法   Shiro框架内部整合好缓存管理器,整合ehcache环境,只需要配置即可.     <dependency> <groupId>net.sf.ehcache</groupId> <artifactId>ehcache-core</artifactId> <version>

Django框架代码和nginx的整合部署

1. nginx 安装不在此阐述,直接上关键配置 server { listen      80; server_name  _; access_log  /var/log/nginx/platform_admin.log  main; error_log /var/log/nginx/platform_admin_err.log ; location /static { root /var/www/platform_admin/resources/; } location / { uwsgi_

Slurm任务调度系统部署和测试(1)

1. 概述1.1 节点信息2. 节点准备3. 部署NTP服务器4. 部署LDAP服务器5. 部署Munge认证服务6. 部署Mysql数据库服务6. 部署slurm6.1 slurm下载6.2 解压编译安装 1. 概述 slurm任务调度系统,主要应用在HPC集群资源管理和任务调度.具体信息参见slurm官方网站:https://slurm.schedmd.com/ 部署Slurm任务调度系统,需要部署NTP内网时间同步服务器,LDAP全局认证服务器,Mysql数据库服务器 本篇博客主要记录如何

详解应对平台高并发的分布式调度框架TBSchedule

tbschedule是一款非常优秀的高性能分布式调度框架,非常高兴能分享给大家.这篇文章是我结合多年tbschedule使用经验和研读三遍源码的基础上完成的,期间和阿里空玄有过不少技术交流,非常感谢空玄给予的大力支持.我写这篇文章的目的一是出于对tbschedule的一种热爱,二是现在是一个资源共享.技术共享的时代,希望把它展现给大家(送人玫瑰,手留余香),能给大家的工作带来帮助. 一.tbschedule初识 时下互联网和电商领域,各个平台都存在大数据.高并发的特点,对数据处理的要求越来越高,

用fabric部署维护kle日志收集系统

最近搞了一个logstash kafka elasticsearch kibana 整合部署的日志收集系统.部署参考lagstash + elasticsearch + kibana 3 + kafka 日志管理系统部署 02 上线过程中有一些环节,觉得还是值的大家注意的比如: 1,应用运维和研发人员要讨论一下日志格式的定义, 2,在logstash取日志和消费端logstash消费日志麻.过滤日志的时候怎么要高效,避免服务本身告成系统压力过大,如果每天要处理过亿日志量,性能不注意,哈哈,可以使

Oracle Secure Global Desktop 部署考虑事项

你可以在这里找到原始文章. 概要 本文描述了Oracle Secure Global Desktop部署的设计和测试过程的整体过程.目的是帮助IT部门制定应用程序的部署策略,以满足IT部门和业务部门的需求. 目前IT组织的最大挑战就是为分散在各个地域的用户提供对其特定工作区(应用程序和桌面)的即时,可靠,无性能退化的访问.此外,管理者也需要对这些分散到各个地域的工作区进行集中的访问管理.这并不容易.很多客户通过使用Oracle Secure Global Desktop部署工作区来为其数以千计的