随机的Docker入库服务
是否获取成功
服务器A
更新工作流状态
否
处理完毕后进入下一个轮询
更新状态表
基于文件拆分任务task表：id 主键idworkflow_id 工作流idfile_id 文件idstatus 处理完/处理中/未处理/已取消chanel_info 通道信息executor 被哪个docker容器执行
服务器B
服务器C
查询入库任务表
nacos中下线该服务
文件N
gateway路由请求，选择一个服务对任务进行拆分
更新任务状态表，抢占任务成功
去中心话实现优点：1） 只用mysql记录拆分的任务，无须额外的mq2） 通过分布式锁在任务执行完毕后抢占式获取新任务，实现任务分配最大程度的均衡(生产者/消费者模型)3） 无中心化，所有节点都能处理任务，提高可靠性4） 入库任务不限流，全部加入任务对列表，展示时可仿照类似滴滴打车，提示前面还有多少个工作流在排队，基于此可实现基于优先级的插队方案5) 基于mysql而不是mq存储任务队列的好处是可以实现实时查询任务状态，调整任务优先级，取消任务
是
任务拆分写入MySQL
通过分布式锁获取任务
入库任务按通道或文件进行拆分，存储到mysql表中
入库工作流2
网关+Nacos路由请求
获取成功
睡眠指定时间
参数校验
入库工作流3
清空不完整的数据
重置任务状态重新放入任务队列
访问宿主机对应的promethus服务
只有nacos在线的服务才能被调用
数据入库
入库工作流1
是否在处理
通过分布锁获取某个耗时任务
查询对应容器日志
睡眠特定时间
入库请求
是否全部处理完毕
Docker服务
可做成通用的starter服务，不光入库，其它服务也能使用
采用调度中心的导致的问题：1) 额外开发新模块，且需要中心化模块稳定可靠2）调度中心无法准确判断各个模块入库任务何时执行完毕，任务分配不是很均衡3）若同时有很多个入库任务，可能会造成单个docker容器任务积压，此时容器内部要额外处理
单个Docker容器的处理逻辑，通过轮询来处理，可确保宿主机资源平均利用，且尽可能的缩短处理时间
是否有任务长时间未处理完毕
CPU/内存是否超限
入库服务分3个核心功能：1） 任务拆分模块，将任务拆分并存入数据表2） 任务处理模块，通过抢占式获取任务并进行入库3） 任务校正模块，检测异常任务，确保都能执行
是否有待入库任务
