
Flowable 异步执行器调优指南定时作业与异步执行的机制全解析【免费下载链接】flowable-userguideFlowable最新中文文档,ai自动生成BPM体验地址http://flow.je4.cn/#/login项目地址: https://gitcode.com/gh_mirrors/fl/flowable-userguideFlowable 异步执行器Async Executor是 Flowable 流程引擎在 V6 版本起唯一保留的作业执行器负责定时器触发与异步作业的后台执行其性能直接影响高并发场景下的流程吞吐量。本文从零开始带新手理解 Flowable 定时作业与异步执行的底层机制并给出可直接落地的异步执行器调优参数建议。为什么需要异步执行器⚙️Flowable 引擎默认以事务方式同步执行流程一次 API 调用如完成任务会沿流程一路执行直到所有分支都到达等待状态才提交事务。这意味着如果流程中有慢操作如调用外部 HTTP 接口、生成发票调用线程会被长时间阻塞。异步执行器正是为了解决这个问题而生的把服务任务标记为异步后引擎会先把流程实例持久化、提交事务再让后台线程池继续执行后续逻辑。用户线程立即获得响应流程吞吐量大幅提升。 在 Flowable V6 中V5 时代的旧版作业执行器Job Executor已完全移除异步执行器是唯一选择详见官方配置章节 ch03-Configuration.adoc。两类核心作业定时器作业与异步作业异步执行器管理着两种作业类型它们存储在不同的数据库表中作业类型存储表产生方式触发条件定时器作业Timer JobACT_RU_TIMER_JOB定时器边界事件、定时器启动事件、定时器中间事件到期时间到达异步作业Async JobACT_RU_JOB标记了flowable:asynctrue的服务任务等被异步执行器锁定并获取死信作业Dead Letter JobACT_RU_DEADLETTER_JOB重试超过上限的失败作业等待人工排查异步执行器中有一个专门的线程周期性扫描定时器作业到期后将其转换为异步作业并交给线程池执行另一个线程负责获取未被锁定的异步作业加锁后送入内存队列由执行线程池真正跑起来。同步与异步的直观对比先看默认的同步执行用户任务、服务任务与定时器事件全部挤在同一个事务中任何一个环节失败都会整体回滚。而把服务任务标记为异步后事务被拆分用户任务完成后立即提交并返回发票生成等重活交给后台作业执行器线程独立执行两个事务互不影响实现方式很简单只需给服务任务加上flowable:asynctrue属性完整 XML 示例见 ch07b-BPMN-Constructs.adoc。第一步开启异步执行器 异步执行器默认是关闭的定时器也因此不会触发。启用只需在流程引擎配置中设置一个开关property nameasyncExecutorActivate valuetrue /Java 配置方式configuration.setAsyncExecutorActivate(true);Spring Boot 场景下同样可以通过SpringProcessEngineConfiguration开启参考 ch05a-Spring-Boot.adoc。⚠️ 新手最容易踩的坑部署了带定时器边界事件的流程却迟迟不触发九成是因为没有打开asyncExecutorActivate核心调优参数一张表看懂异步执行器配置异步执行器高度可配置官方完整参数表在 ch17-Advanced.adoc。以下是最常用的调优项参数默认值调优建议asyncExecutorCorePoolSize2执行作业线程池的核心线程数高并发可调至 4~8asyncExecutorMaxPoolSize10最大线程数结合机器核数与作业量调整asyncExecutorThreadPoolQueueSize100内存作业队列长度队列满时作业会解锁回写数据库asyncExecutorMaxTimerJobsPerAcquisition1单次查询获取的定时器作业数调大可提升吞吐但乐观锁冲突概率上升asyncExecutorMaxAsyncJobsDuePerAcquisition1单次查询获取的异步作业数含义同上asyncExecutorDefaultTimerJobAcquireWaitTime10000定时器作业两次查询间隔毫秒空闲时生效asyncExecutorDefaultAsyncJobAcquireWaitTime10000异步作业两次查询间隔毫秒asyncExecutorTimerLockTimeInMillis300000定时器作业锁定时长5 分钟锁超时后其他执行器可重新获取asyncExecutorAsyncJobLockTimeInMillis300000异步作业锁定时长5 分钟asyncExecutorResetExpiredJobsInterval60000解锁超时作业的检查间隔秒用于恢复卡死的作业asyncExecutorNumberOfRetries3作业最大重试次数超过后进入死信表asyncExecutorSecondsToWaitOnShutdown60引擎关闭时等待线程池安全退出时间调优口诀 作业多、跑得慢优先调大MaxAsyncJobsDuePerAcquisition与线程池大小乐观锁异常频繁把单次获取数量调回 1降低多引擎竞争作业卡死无人管缩短LockTimeInMillis或ResetExpiredJobsInterval让超时作业更快被解锁复活。失败重试与死信作业机制作业执行失败时Flowable 会自动把它转成带到期日期的定时器作业等待下一次获取重试。重试次数超过asyncExecutorNumberOfRetries默认 3 次后作业会被移入ACT_RU_DEADLETTER_JOB死信表等待管理员排查异常并人工处理。这种重试 → 死信的设计与消息队列的 dead letter 概念一脉相承可以防止故障作业无限占用线程池资源。进阶方案基于消息队列的异步执行器 如果线程池模式仍无法满足吞吐要求Flowable 还提供了基于消息队列的异步执行器实现新作业产生时向 MQ 发送一条含作业 ID 的消息消费者取到 ID 后获取并执行作业彻底摆脱轮询数据库的瓶颈。官方支持通过flowable-jms-spring-executor配合 ActiveMQ 使用开启方式为asyncExecutorActivate trueasyncExecutorMessageQueueMode true注入MessageBasedJobManager作为JobManager跑分显示消息队列模式吞吐量显著优于线程池模式代价是需要引入额外的中间件与运维复杂度——对于大多数业务场景默认线程池模式已经足够。监控作业运行状态作业是否在跑、是否堆积可以通过 Flowable 自带的管理界面查看。作业管理页面会列出定时器作业、异步作业与死信作业的实时状态是排查定时器不触发和作业卡死问题的最直观入口。总结Flowable 异步执行器是流程引擎后台能力的核心理解定时器作业与异步作业的区分、掌握asyncExecutorActivate的开启方式、熟读上表中的调优参数你就能从定时器不触发的新手困境中走出来一步步把高并发流程的吞吐量调到最佳状态。更多细节可继续阅读用户手册中的 ch03-Configuration.adoc 与 ch17-Advanced.adoc。【免费下载链接】flowable-userguideFlowable最新中文文档,ai自动生成BPM体验地址http://flow.je4.cn/#/login项目地址: https://gitcode.com/gh_mirrors/fl/flowable-userguide创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考