工作流持续排队
工作流事件触发后会以消息的形式先进入 Kafka 消息队列,再由工作流消费服务进行读取消息进行处理流程。
遇到工作流持续排队时,首先需要先区分平台内工作流虽然排队量大但也在陆续消费,还是一直排队并无消费。
以如下两种常见情况为例:
- 工作流排队量大但也在陆续消费
- 工作流一直排队并无消费


工作流排队量大但也在陆续消费
在工作流监控页面看下是否有个别流程排队数字非常高,如有数十万、百万等这种排队量较大的流程,可能是因为业务人员没能配置好触发逻辑或者死循环等原因造成工作流触发量大。
消费能力可能受多种影响有处理上限,比如每分钟正常可以处理一万条流程,但实际可能触发了数十万条流程,此时触发流程较多,流程不能快速消费完,就呈现了排队的现象。
例如有个别工作流在排队数十万条甚至更高时,造成了所有工作流排队严重,如确认到这种排队量大的流程不需要其再消费,应在非暂停状态下直接关闭对应工作流。
-
工作流直接关闭后,排队中的消息会快速消费(不走工作流中的节点逻辑),这样可以让排队中的工作流尽快得到处理。
-
如果这种排队量大的工作流需要消费,可以先暂停,等待业务空闲期间再开启。
如果没有误触发排队较多的工作流,请登陆服务器检查资源的占用情况。可以使用 top 命令查看当前服务器与各进程 CPU、内存的资源实时占用。
-
占用 CPU 较大的进程是
mongod进程,通常是因为有慢查询导致,处理方式参见慢查询优化帮助文档。 -
占用 CPU 较大的进程是
dotnet或java进程,通常是工作流节点中的逻辑较为复杂,会连带关联服务资源占用上升。- 如果当前服务器资源满载可以选择扩容或暂停逻辑复杂的工作流等业务低峰期再运行。
- 如是基于 Kubernetes 部署的集群模式,可以在资源还有一定冗余的情况动态扩容资源占用高的服务实例。
工作流一直排队并无消费
在所有工作流一直排队并无消费时,通常为服务器磁盘满,或者队列组件 Kafka 服务异常导致。
-
在服务器上通过
df -Th命令查看当前系统盘与数据盘的使用率。 -
检查 Kafka 服务是否正常:
- 单机模式
- 集群模式
查看存储组件容器健康检查日志
docker logs $(docker ps | grep sc | awk '{print $1}')