feat: 节点任务状态优化方案

[hanshuaikang]

背景信息

现阶段下述状态都需要实时计算才能得到, 特别是PENDING_PROCESSING, PENDING_CONTINUE 或者
PENDING_CONFIRMATION 和 NODE_SUSPENDED 不仅需要进行sql的计算，还额外需要针对树的解析。

# 失败
FAILED = "FAILED"
# 执行中
RUNNING = "RUNNING"
# 节点暂停  
NODE_SUSPENDED = "NODE_SUSPENDED"  
# 等待审批  
PENDING_APPROVAL = "PENDING_APPROVAL"  
# 等待确认  
PENDING_CONFIRMATION = "PENDING_CONFIRMATION"  
# 等待处理  
PENDING_PROCESSING = "PENDING_PROCESSING"  
# 等待继续  
PENDING_CONTINUE = "PENDING_CONTINUE"

方案

能够一劳永逸解决该方案的在于:

• 尽量减少sql的查询，避免扫描State这些量级很大的表
• 尽量避免针对pipeline_tree的状态计算，将pipeline_tree的状态计算分散到执行的具体步骤中。

方案细节:

增加索引字段

为TaskFlowInstance表新增一个额外的冗余字段， status， 该字段表示以下几种状态，并且状态直接存在优先级。

参考链接: https://www.cnblogs.com/hobbybear/p/17676304.html

状态直接存在优先级:

梳理状态优先级, 如下表所示(暂定):

当存在多个节点并行执行时，此时将根据优先级的原则覆盖，例如下图的最终的状态是: 等待审批

修改状态的时机:

对于节点状态, 当进入一个高优先级状态时, 此时需要修改任务实例状态为该状态，当退出该节点时，需要重置该状态为RUNNING，交给下一个环节重新设置状态。

如下图所示:

当存在并行网关时:

注意: 这样会引入一个新的问题，那就是暂停节点和审批节点会同时对任务实例的状态发起变更，此时需要引入锁或者队列的机制 防止任务状态被覆盖。

具体实现:

1. 对于依赖于节点的状态，节点暂停/等待确认/等待审批/ 需要在对应的插件统一埋钩子，在进入节点之前发起一次状态变更，在退出节点之前发起一次状态变更。对于默认节点则无需做操作，因为状态始终都会是低优先级的RUNNING.
2. 对于流程状态的变更，FINISHED/FAILED/SUSPEND/REVOKE 等状态，监听 post_set_state 信号进行状态的变更。

[hanshuaikang]

代讨论: 当存在并行网关时，此时审批节点技术，尝试修改为RUNING，但此时暂停节点还没有结束，流程状态应该回退到NODE_PENDING

[normal-wls]

背景

目前，任务列表的过滤不支持直接过滤【执行中】和【失败】的任务状态。后续还会加入类似于【暂停中】和【等待处理】等一系列业务层状态，同样需要列表过滤。

方案

因为引擎层的流转没有记录业务层需要的状态，【执行中】和【失败】都是 RUNNING，所以没办法从引擎层的表直接支持。

实时计算的话需要多次请求 db，而且涉及多张表，计算成本高。

因此，需要有一个地方用于记录相关状态的流转。目前仅需要考虑【执行中】【暂停】【等待处理】【失败】这四种状态。因为这里只应用与列表过滤，所以可以考虑通过 Redis 来记录正在执行中的任务的状态堆栈。

数据结构：

key: sops_executing_task_{project_id}_{task_id}
value: 基于状态优先级排序的结果(list/zset)

插入：

• 在进入开始节点，新建并插入 RUNNING 状态
• 在进入暂停节点时，插入 暂停 状态
• 在进入审批节点时，插入 等待处理 状态
• 在节点失败时，插入 失败 状态

删除：

• 在任务失败或完成时，删除 key
• 在新建key 时添加过期时间，暂定（x 天）
• 调用节点跳过、重试时，去掉失败状态
• 暂停节点结束时，去掉 暂停 状态
• 审批节点结束时，去掉 等待处理 状态

列表过滤（以下状态都只支持x天内的任务）：

• Redis 中 key sops_executing_task_{project_id}_* 的任务，同时最高优先级命中过滤条件的任务列表。

待确认

• Redis 多 key 筛选性能，存储压力评估
• 生产环境执行中任务量评估，确定过期时间