Power-job 调研

Power-job 调研

1. cron表达式只能支持15s以上的定时任务, 任务调度在server端
2. 15秒以下的定时任务可以配置走jvm定时任务, 任务调度在client端
3. server端每15s查询一次数据库, 查询30s内即将执行的任务, 记录发送日志, 添加到时间轮等待执行.
4. Client端通过akka实现了一个http server, job-server端反向调用http接口下发任务, 新版本通过vertx实现的httpserver, 默认没有开启.
5. client端job日志存在内存队列中，可能丢失日志，由client通过akka上报到server端；job-server端通过h2数据库存储(Demo级别,不适合生产)，可扩展到MongoDB
6. appId和server节点绑定, 同一个app的client对应到同一个server端, 以此来实现分片
   client端获取server列表: 第一次通过http访问客户端配置的server地址, 获取映射的server地址, 后续定时任务访问
   更新客户端server list, 这里要求必须通过域名访问server, 否则永远连接到的是第一个server地址, 无法做分片.
   server端逻辑: 第一次获取当前server地址做为app地址, 在数据库记录appId和server ip的映射关系, 后续从数据库
   查询, 查询到server地址后先ping验证server连通性, ping不通则重新分配当前server机器地址, 更新到Db
7. 客户端默认10秒通过akka上报一次心跳, 记录一些运行时信息, 例如client address, cup数量, 负载, 内存, 供server端在选择任务节点时做负载计算.
8. 由于appId和server之间一对一绑定了, 所以心跳信息记录在了server内存中. 下发任务时通过client端上报的指标数据计算分数, 选择最优的执行任务.
9. client 分为耗时任务和非耗时任务线程池

是否存在callback, 是否执行成功, 业务结果

存在callback, 逻辑同下；记录执行状态, 不记录业务结果

页面展示的触发时间是server端时间还是真实执行时间

1. 实际上是server发送任务后记录的时间, 并不是client端真实触发的时间
2. client端默认每隔15s主动上报一次任务运行状态, client端会上报触发时间, 但是server端并没有更新该时间.
3. 任务执行完成后立刻上报执行状态.

超时重试怎么实现

1. 客户端做超时校验, 但是存在bug, 服务端下发了超时时间,但是客户端端并没有使用, 默认使用了Integer.MAX_VALUE
2. 定时扫任务实例库, 每10s检测一次,60s外还没有任务状态上报的, 认为超时, 修改任务状态,改成待分配, 等待下次分配.

告警怎么实现

客户端记录失败信息, 通过心跳上报是否需要告警, 以及告警内容, 由服务端告警.