为什么会需要分布式任务集统一调度中心？
传统的方式:混合式，高耦合，不能分布式部署，存在重复调度，重复消费现象等问题，在J2E项目中如果需要满足分布式任务调度，通常需要引入Zookeeper等节点管理中间件来满足CAP设计理念原则。
设计理念:以CAP原则为设计导向，可以云化，组件化原则，支持分片，支持负载均衡策略，产品设计上尽量轻量级，必须支持可拓展属性并建议提供SDK或者支持插件化操作。
细粒化组件图如下↓
大致流程如下
001-1
@日志收集:入数据库，同时连带产生日常化日志文件，LogBack方式纳入ELK日志平台。(日常化日志文件进行历史文件清除，比如只保留最近的7天日志文件)
@负载均衡选举策略:大致满足如下选举策略，LRU(选举最近最少使用优先原则策略)，LFU(选举最近最少频率优先原则策略)，Random(随机选举原则)，Random+Weight(随机+权重原则)，FIFO(先进先出选举原则)，FILO(先进后出选举原则),一致性Hash选举策略等，心跳检测坏节点自动下线原则。(控台WEB管理页面给出不同场景下推荐合适的选举策略，也可以通过监控数据自动切换成不同的选举策略)
建议:如果是最近一段时间，同一调度JOB上的作业集群都是以健康状态平稳运行，使用LRU策略，否则使用LFU策略。如果作业节点比较多的话，通常是具有中心化的Master-Slave集群特性，这时候采用一致性Hash选举策略算法较妥。
@重试机制: 可对每个JOB单独设置负载策略和重试策略。
1.支持失败后自动重试功能
2.支持阶梯式重试功能(例如默认重试次数2次，隔三分钟后增加重试次数五次，五分钟后增加重试次数十次)
3.支持重试无意义自动关闭重试功能，简单做可以通过异常行为来操作，比如因代码造成的不可逆行为触发一次重试后，识别到关键字就不需要再次触发重试了，并发出警告，警告以邮件形式通知运营。
@防止重复调度任务消费:较高成本可采用Redis实现分布式锁机制，较低成本采用数据库悲观锁机制，采用FileLock机制(文件读写锁机制)，采用乐观锁机制(调度ID+版本号机制实现)。
@CICD,采用Docker部署
@邮件警告功能，采用JAVAMail基于邮件协议的组件造成此功能
@支持脚本化调度，通过操作系统或者其他任务调度平台返回的ACK编码，当出现ErrCode时自动触发重试机制
@前置+后置作业:采用业务上的触发器，并用分布式数据库实现数据库层面的回滚功能，其他层面上的回滚功能，采用回滚资源或者事件回滚等形式来实现该回滚达到最终一致性效果。
最终的原则是:使用方便，维护成本低，可拓展，面向二次开发友好，面向用户傻瓜式操作，前端控台部分可采用VUE/React等实现管理功能。
前端管理开放出来的模块如下
004
网友评论