TBSchedule调度平台疑难解答

TBSchedule调度平台疑难解答

前言：TBSchedule调度平台的环境搭建以及使用本文不再过多的介绍，如果不了解可自行移步百度。本文主要介绍TBSchecduler集群、容灾、负载均衡的实现。本文仅供个人学习参考，未经作者允许请勿传递。

TBSchedule调度管理控制台

下图是TBSchedule调度管理控制台，该页面是作者稍微修改UI后的结果；原生的页面确实太简陋了，看着不舒服。后文主要对调度策略、任务管理、机器管理进行深入介绍，建议各位朋友先下载源码把环境先搭建起来，能够调起任务。

机器管理

学过微服务的同学都知道，一个服务可以发布到多台服务器上搭建机器黄金，消费者调用的时候就可以根据负载均衡策略调用到某一个服务。这里的机器就相当于服务器，如果只有一台机器那么就无法做负载，会存在单点故障。我们学习的时候可以使用单台主机启动多个服务（机器），TBSchedule会自动给机器生成一个唯一的id，无需开发者指定（类似于单主机启动多个Tomcat修改端口号，此处连端口号都不用修改）。个人学习时可以先试着把机器数量控制到两台，然后再依次增加。关于机器管理先介绍到这来，后续还会穿插一些机器相关的信息。

任务管理

任务管理可以是一个调度的入口，后台开发好程序后，首先需要在任务管理配置相关的参数。创建任务时关注红色框框中的参数即可。

参数名称释义参数值任务处理的SpringBean配置文件中调度实现类型类对应的id名称例如，singleTask0任务名称该调度类的名称，建议命名时能做到见名思意例如，singleTaskTest心跳频率服务与zookeeper通信时间间隔,单位为秒，告诉zookeeper自己还活着。（但时TBSchedule底层默认2秒内会执行一次刷新 *** 作）例如，5假定服务死亡间隔该参数为集群时使用，如果正在执行的服务异常死亡，那么间隔该时间后，其他可以用的服务会将运行在该服务上的任务“接走”。例如，25秒，必需>=5倍心跳时间线程数处理模式每次获取数据量每次执行数量没有数据时休眠时长每次处理完数据后休眠时间执行开始时间执行结束时间单线程组最大任务项单次调度执行次数自定义参数任务项 单JVM最大线程组数量

概念：这里的单JVM不太好理解，如果是一路看着作者前几篇教程过来的朋友，把这里理解成单个调度器实例可以启动的最大线程组数量（一个线程组中默认5个子线程）。一个线程组负责执行对应任务中的一个任务项。
那么不难理解，如果不限制该值，当所有实例加起来的线程组总数大于任务项时，任务项被均匀分配到线程组中，多出来的线程组作为灾备处于“待命”状态，过多的“待命”必然会有线程资源的浪费。而当其小于任务项时，多余的任务项会被分配到某一线程组下并行，一个线程组处理太多的任务项也会造成该实例占用资源升高，效率降低，极端情况下可能会压死实例。
如何限制该值，这里官方控制台有一个误导。假设单JVM最大线程组数量为1，最大线程组数量为3，启动一个调度器你会发现该调度器仍会启动3个线程组。此时所谓的“单JVM最大线程组数量”是没有效果的，如果有单线程运行的需求，请配置单JVM最大线程组数量为1，最大线程组数量为1，并将任务配置中的“线程数”设为1。此时该任务处于真正的单线程运行，避免业务处理中的线程安全问题。
作用1：灾备（重要）。当执行任务的调度器为集群时，某一调度器宕机达到60s，tbs会将任务转移到另一个调度器中的线程组运行。
作用2：多重并发执行。知道了线程组的概念，那么我们可以利用任务项同时激活多个线程组，再加上任务执行本身也可以配置线程数。所以此时我们可以做到单个调度器上：（线程组数*子线程数）个线程同时处理任务，作者将此场景称之为多重并发执行，其执行效率相当恐怖，但需要自己处理好任务处理幂等性的问题。（此处转载：https://my.oschina.net/wednesday/blog/1591716）

最大线程组数量

解释：所有调度器总计可以运行的线程组数量
注意：结合上述分配图看，理论上，也是大多数情况下，tbs都会启动最大线程组数量的线程组以保证可容灾性。但在实际应用中偶尔也会发生线程组启动不全的情况，这种情况仅限于某任务所配置的任务项刚好整倍数于线程组数的时候。（此处转载：https://my.oschina.net/wednesday/blog/1591716）