並行多實例循環如何在 Camunda 7.16.6 中工作

Question

我正在使用 camunda-enginge 7.16.6。 我有一個像這樣的多實例循環的進程，它並行重復 1000 次。

這個循環是並行執行的。 我的假設是，n camunda 執行者現在開始他們的工作，所以執行者 #1 執行任務 2，然后是任務 3，然后是任務 4，執行者 #2 和所有其他執行者都這樣做。 因此，不久之后，至少 1000 次中的一些完成了循環中的所有三個任務

但是到目前為止我觀察到的是，任務 2 執行 1000 次，只有在完成后，任務 3 才會執行 1000 次，依此類推。 我還注意到，除了任務之外，camunda 本身需要很多時間。

我的觀察是否正確，這種行為是否記錄在某處？ 你能改變這種行為嗎？

Answer 1

我已經運行了一些測試並可以解釋這種行為：任務順序和完成的總時間受事務邊界的影響（異步之后，屏幕截圖中的紅條）。 它有點描述here 。

通過設置 asyncBefore='true' 屬性，我們引入了一個額外的保存點，在該點處進程 state 將被持久化並提交到數據庫。 一個單獨的作業執行線程將通過使用一個單獨的數據庫事務來異步地繼續該過程。 如果此事務失敗，服務任務將被重試並最終標記為失敗 - 以便由人工操作員處理。

重復 1000 次，並行，無事務 一個 Job Executor 沖過這個過程，順序是 1，[2,3,4|2,3,4|...]，5。不是真正的並行。 但這是記錄在這里：

Job Executor 確保來自單個流程實例的作業永遠不會同時執行。

如果您是專家並且知道自己在做什么（並且已經理解本節），則可以將其關閉。

總的來說，這大約需要 5 秒。

重復 1000 次，並行，有事務 這里，由於事務的原因，會有 1000 個等待 Task 7 的 Job，每完成 Task 7 就會創建 Task 8 的另一個 Job。由於 Jobs 的執行是按照數據庫中的順序（ 見這里），所以 order 是 6 ,[7,7,7...8,8,8...9,9,9...],10。

包括維護變量在內的事務處理對運行時產生巨大影響，在並行模式下，事務處理運行時間為 06:33 分鍾。

如果關閉exclusive - 標志大約需要 4:30 分鍾，但代價是數千個 OptimisticLockingExceptions。 Afaik 推薦的獲得真正並行性的方法是將任務 7、任務 8 和任務 9 移至單獨的進程並生成該進程的 1000 個實例。

如果您調整作業執行器設置和優先級，您可以影響執行順序， 請參見此處，但這似乎也需要獨占標志。 如果你這樣做，訂單將是 6,[7,7,7|8,9,8,9(隨機順序),...]10

重復 1000 次，順序，無事務

順序是 11,[12,13,14|12,13,14,...]15

這僅需 2 秒。

重復 1000 次，順序，有事務 順序如預期 16,[17,18,19|17,18,19|...],20

由於交易，這需要 02:45 分鍾。

我從大學聽說，只有在涉及長時間運行/阻塞的任務（如人工任務）時才應該使用並行 - 在順序模式下，只有一個人工任務，完成一項后，將創建另一個。 在並行模式下，您有 1000 個人工任務，這更有可能是所需的行為。 Camunda 8 中的並行性能似乎有所提高