摘要：本文重點說明下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、可以在每臺服務上配置不同的環境變量，環境變量去決定是否可以定時作業。（簡單）
其他方案可以可以郵件溝通：[email protected]
各個框架的實現總結：
| 框架 | 分佈式緩存reids | 流程預熱 | 分佈式定時器 | 流程發佈排他鎖 | 引擎緩存監控 |
| Activiti | ✅（參考Activiti權威指南書） | ❌ | ❌ | ❌ | ❌ |
| Flowable | ❌ | ❌ | ✅ | ❌ | ❌ |
| Camunda | ❌ | ❌ | ❌ | ✅ | ❌ |
| 盤古BPM | ✅ | ✅ | ✅ | ✅ | ✅ |
技術支持：盤古BPM工作流平臺