golang fastflow 库流程整理

组件介绍

先抄一张官网的，其实这张图里面画的不全，Leader 节点也会执行任务。

• keeper：负责上报心跳，同时负责选举 leader。
• store：存储层的抽象，负责提供存储相关的 api。
• dispatcher：监听等待执行的图，通过负载均衡算法将图分配给不同的 worker。
• parser：监听分配给自己的任务，将图解析成树，找到下一个要执行的节点，发送给 executor 执行。
• executor：负责单个节点的运行。
• commander：封装了一些常见的执行，比如停止，重试，继续等。
• watchDog：负责监听执行超时的节点将其更新为失败，同时也会重新调度那些一直得不到执行的图到其他worker。

分布式示意图

只有 leader 节点会对任务进行分配，leader 和 worker 都会负责执行任务。

系统执行流程

任务执行流程

1. 用户创建工作流任务。
2. dispatcher 监听到有待执行的任务后，分配一个 worker 给这个任务，然后将任务写回数据库。
3. parser 监听到有分配给自己的任务后，将图解析成树，寻找可以执行的节点，然后将节点发送给 executor。
4. executor 执行单个的节点，并将执行结果返回给 parser。
5. parser 收到结果后，根据树找到下一个要执行的节点，继续发送给 executor。如果整个树都执行完毕则更新任务状态。

命令执行流程

command 流程和任务执行流程相似，命令会先存储到 db 中，然后又 parser 进行命令的解析，发送给 executor 执行。

详细流程

1. 要创建一个工作流，首先要找到对应的 dag 图，然后传入必要的参数，再将这个带有参数的图存到数据库。
2. dispatcher 组件有一个协程负责监听数据库里面待执行的图，拿到图后通过负载均衡算法分配一个 worker，然后把这个图存入数据库。
3. worker 节点的 parser 组件会监听数据库，查找分配给自己的图，找到图后生成一棵树，放入内存中，然后通过树查询可以执行的节点，通过 queue 传递给 executor 组件。
4. executor 组件拿到要执行的节点后，执行顺序为 preCheck->runBefore->run->runAfter，执行完成后将节点和执行结果通过 queue 传递给 parser。
5. parser 通过 queue 拿到 executor 执行完成后的节点之后，再通过树找到下一个可以执行的节点，通过 queue 传递给 executor 执行。如果没有下一个可以执行的节点，那么就计算整个树的执行结果，存入数据库。

具体逻辑说明

选主逻辑

leader 会在二分之一超时时间的时候去更新数据库的 update_time 字段。worker 会在二分之一的超时时间查询一次 leader 是否已经超时，如果超时则将数据库中 worker_key 字段更新为自己。

优点

• 对流程支持使用编码和yaml文件的形式进行编排

• 不依赖其他的组件，只依赖 mysql

改进点

1. 如果自身负载比较低，那么生成任务后就由自身节点去立即执行，而不是走 dispatcher 分配流程。
2. 执行命令时，由接收到该命令的机器去执行该命令，同时抢占任务的执行权，省略了监听再执行的步骤，缺点是可能造成单个机器负载较高。
3. 继续，重试命令会重试节点的所有动作，可以改进为精准重试，哪里阻塞在重试的时候就重试哪里。

github 地址

原版

mysql 版