-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: 节点任务状态优化方案 #7337
Comments
代讨论: 当存在并行网关时,此时审批节点技术,尝试修改为RUNING,但此时暂停节点还没有结束,流程状态应该回退到NODE_PENDING |
背景目前,任务列表的过滤不支持直接过滤【执行中】和【失败】的任务状态。后续还会加入类似于【暂停中】和【等待处理】等一系列业务层状态,同样需要列表过滤。 方案因为引擎层的流转没有记录业务层需要的状态,【执行中】和【失败】都是 RUNNING,所以没办法从引擎层的表直接支持。 实时计算的话需要多次请求 db,而且涉及多张表,计算成本高。 因此,需要有一个地方用于记录相关状态的流转。目前仅需要考虑【执行中】【暂停】【等待处理】【失败】这四种状态。因为这里只应用与列表过滤,所以可以考虑通过 Redis 来记录正在执行中的任务的状态堆栈。 数据结构:
插入:
删除:
列表过滤(以下状态都只支持x天内的任务):
待确认
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
背景信息
现阶段下述状态都需要实时计算才能得到, 特别是
PENDING_PROCESSING
,PENDING_CONTINUE
或者PENDING_CONFIRMATION
和NODE_SUSPENDED
不仅需要进行sql的计算,还额外需要针对树的解析。方案
能够一劳永逸解决该方案的在于:
方案细节:
增加索引字段
为TaskFlowInstance表新增一个额外的冗余字段,
status
, 该字段表示以下几种状态,并且状态直接存在优先级。参考链接: https://www.cnblogs.com/hobbybear/p/17676304.html
状态直接存在优先级:
梳理状态优先级, 如下表所示(暂定):
当存在多个节点并行执行时,此时将根据优先级的原则覆盖,例如下图的最终的状态是: 等待审批
修改状态的时机:
对于节点状态, 当进入一个高优先级状态时, 此时需要修改任务实例状态为该状态,当退出该节点时,需要重置该状态为RUNNING,交给下一个环节重新设置状态。
如下图所示:
当存在并行网关时:
注意: 这样会引入一个新的问题,那就是暂停节点和审批节点会同时对任务实例的状态发起变更,此时需要引入锁或者队列的机制 防止任务状态被覆盖。
具体实现:
The text was updated successfully, but these errors were encountered: