flowable集群方式使用方案

 

摘要：本文重点说明下flowable集群方式使用方案，本方案同样适用于Activiti/camunda/盘古BPM等其他的框架。bpm工作流引擎使用Redis、分布式定时器、分布式调度作业（定时器）、发布锁。

1、集群方案中的部署

在流程引擎开始执行部署之前，它会尝试获取表中一行的排他锁ACT_GE_PROPERTY。当流程引擎能够成功获取锁定时，只要开始执行部署，它就会开始部署并持有排他锁。

如果在群集方案中的多个节点上同时执行相同资源的部署，则获得的排他锁可确保重复过滤按预期进行。否则，并行部署可能会导致同一流程定义的多个版本。

另外，排他锁确保具有相同密钥的多个定义（例如，流程定义）在同时部署时不会得到相同的版本，这可能导致失败和意外行为。注意，数据库中没有唯一约束来检查定义的唯一性。

因此，排他锁强制执行部署的顺序顺序。

默认情况下，排他锁获取已启用。如果不希望这样做，可以通过将名称deploymentLockUsed为false 的流程引擎配置标志设置为禁用。

H2数据库

请注意，在群集方案中不支持H2数据库。流程引擎不会创建任何排他锁，因为H2默认情况下使用表级锁，如果在执行部署时deploy命令需要使用DbIdGenerator获取新的ID，则可能会导致死锁。

2、缓存方案

默认缓存在bpm jvm进程中。可以使用Redis统一管理流程定义缓存。这样在部署多套的时候，不会造成资源的浪费。

3、缓存预热

因为xml解析的逻辑相对复杂，且比较耗时，如果能提前对一些常用的流程定义进行缓存预热，则模板缓存不会丢失，这样是最理想的情况。可以单独部署一套bpm进行流程定义的预热工作，盘古BPM的流程缓存监控如下所示：

4、分布式定时器

BPM中的定时器默认是单机版的，不能应对集群模式。如果进行集群方式部署，会造成如下几个问题：

1、每台服务器都需要开启定时器，可能会造成同一份数据被多次扫描和执行，单是只能有一台服务执行成功。

2、可能会造成无用资源的浪费，因为每台服务器都需要进行定时任务的轮训。

解决方案：

    1、可以引入分布式定时框架，比如XXL-JOB.（复杂）
    2、可以在每台服务上配置不同的环境变量，环境变量去决定是否可以定时作业。（简单）

其他方案可以可以邮件沟通：pangubpm@139.com

各个框架的实现总结：

 

框架	分布式缓存reids	流程预热	分布式定时器	流程发布排他锁	引擎缓存监控
Activiti	✅（参考Activiti权威指南书）	❌	❌	❌	❌
Flowable	❌	❌	✅	❌	❌
Camunda	❌	❌	❌	✅	❌
盘古BPM	✅	✅	✅	✅	✅

 技术支持：盘古BPM工作流平台