tbschedule源码学习

tbschedule使用zk来解决集群间的同步问题，首先看一下zk上面的结构信息

• factory 是对应着每一个连接的机器，使用唯一的uuid做区分，后缀是zk自己维护的序列号
• strategy是任务执行策略相关的设置，在每个task-n下面记录了这个任务的策略信息包括可以执行的机器，每个机器该任务执行最多几个线程组，一个线程组里多少个线程。tbschedule在执行的时候这里作为信息的来源。tbschedule的后台也会修改这里
• tasks的是记录任务分配到那台机子的配置。tbschedule在运行的时候会读写这里的内容。任务的lead机子会定时更新这个目录，tbschedule任务片的派发直接依赖这个目录

tbschedule在启动的逻辑图

重要的类结构解析

• TBScheduleManagerFactory
  
  • 这个类必须是单例模式，否则会出现重复执行多次，如果要改配置，再次执行init方法就可以
• ManagerFactoryTimerTask
  
  • 保持心跳，定时更新配置，利用zk重新选出leader读取strategy，更新
  • 和TBScheduleManagerFactory的数量一致，也只有一个。
• TBScheduleManager 任务策略的线程组管理器
  
  • 这个类本身会创建多个，有定义了多个任务策略的就有多少个
  • 会创建很多个线程IScheduleProcessor，个数为分配到的taskItem的个数
  • 同一个组内执行线程持有相同的执行模式TBScheduleProcessorNotSleep或者TBScheduleProcessorSleep，共享同一个任务池
• HeartBeatTimerTask
  
  • 和TBScheduleManager的数量保持一致
  • 定时重新分配zk/task下目录，只有leader

zk在这里的作用

zk作为一个黑盒的资源管理中心，类似于目录和文件于一体的结构，即可以存数据也可以创建子目录。
zk被用来选举出集群中的哪个机子是leader，同时记录任务的各种信息，baseTaskType会被频繁更新。

其他

• 每一个ManagerFactory在启动以后uuid保持不变。在第一次的时候managerFactory.uuid为null，初始化一个uuid，并向zookeeper注册使用EPHEMERAL_SEQUENTIAL模式（断掉会删除，但是path后会追加一个zookeeper内部维护的递增序列号），后面这个序列号是作为集群选举的关键。 注册后得到地址，保留下来并作为这个managerFactory.uuid。 后面重连的话就会直接使用uuid创建目录，使用EPHEMERAL模式(断掉会删除)，后面不管重连多少次都会保持一致。应用重启的话 uuid会网上增加。ManagerFactory.uuid一旦设置值之后就不会再改变

• IScheduleProcessor 检查是否需要退出的机制和线程中断的机制是一样的，都是协同机制，在某个点检查标志位

• 为了避免频繁读取zk/task下的结构，使用了本地缓存，用了zk目录节点的version作为是否脏的标识。
• 任务组每执行完一遍会休眠一段时间，避免重复空执行浪费资源
• tbschedule分配给每个机子的任务片(0,n)不会相同，每个机子返回可以执行的任务组可以由n多个一般是用返回的任务片取模，这就需要在配置的时候遵守一定的约定。