本文重點探討一下camunda框架，主要從camunda工作流框架的性能和可伸縮性，以及camunda框架如何處理高吞吐兩個維度來說明。
持久化策略
Camunda框架可以運行在許多不同的關係數據庫上（請參考：）。
Camunda使用這些數據庫儘可能高效的執行sql，大概有如下幾個概念：
緊湊型表格
Camunda使用緊湊的數據模型和複雜的算法，從而使數據庫中存儲流程實例狀態所需的行數達到最小化。 這通過減少需要存儲的行數來加快執行速度。 在最好的情況下，當流程實例從一個活動前進到下一個活動時，只需要更新一行。而不是activiti、Flowable等框架使用的n行。
死鎖避免
Camunda使用 樂觀併發控制 來支持高級別的併發性，同時最大限度地降低死鎖的風險。 在用戶思考期間，鎖永遠不會被保留。 對數據庫狀態的所有修改都是在事務結束時批量刷新，同時使用智能SQL語句排序來避免循環等待。關於批量刷新也就是會話緩存，可以參考Activiti權威指南章節。
控制保存點
到實例到達保存點時，內存狀態與數據庫需要同步以確保容錯。 Camunda提供了對保存點放置的精細控制，因此可以更好地平衡容錯和性能。 例如，您可以在單個事務中批量執行多個活動，這樣可以減少數據庫同步點的數量。camunda框架提供了一些閾值設置參數可以讓用戶決定當一個會話緩存的容量達到一定的體量之後，自動刷新到數據庫表並釋放內存。
智能緩存
通過在後續事務中重用第一級緩存來支持只寫保存點。 這大大減少了使用中間保存點執行活動序列所需的SELECT語句數。 這在實現JSON或XML有效負載轉換等數據繁重的流程時最有效。
併發
併發令牌表示爲數據庫中的各個行。 此模型允許真正的進程內實例併發，因爲可以同時更新單獨的行。
集羣
我們可以在集羣中運行Camunda，以實現負載平衡和/或高可用性。
多個節點，共享數據庫
爲了提供負載平衡或故障轉移功能，可以將流程引擎分發到集羣中的不同節點。 然後，每個流程引擎實例將連接到共享數據庫。
各個流程引擎實例不會跨事務維護會話狀態。 只要流程引擎運行事務，就會將完整狀態刷新到共享數據庫。 這使得可以將在同一流程實例中工作的後續請求路由到不同的羣集節點。 此模型非常簡單易懂，在部署羣集安裝時可能會受到限制。 就流程引擎而言，負載平衡設置和故障轉移設置之間也沒有區別（因爲流程引擎在事務之間不保持會話狀態）。
流程引擎作業執行程序也是羣集的，並在每個節點上運行。 對流程引擎而言沒有單點故障的問題。 作業執行者可以在兩者中運行。
資源分配最少原則
由於流程引擎是無狀態的，因此每個節點分配最少量的RAM內存（通常小於10 MB）。 基本上，您可以在數據庫中保留數十億個流程實例，而不會對每個節點的資源分配產生必要的影響。 這也意味着您可以爲每個節點運行許多流程引擎實例。
運行時與歷史設計
運行時數據是Camunda流程引擎爲了進行異步而需要持久保存的最小數據量 。
-例如 當流程引擎等待用戶交互（用戶任務），傳入消息（消息事件）或時間跨度（計時器事件）時，存在異步服務交互（服務任務）時等場景。
歷史數據不是執行所必需的，但可以爲了審計，報告等而記錄。 它們允許您檢查運行和已完成流程實例的完整審計跟蹤，包括其有效負載。
Camunda將運行時數據與歷史數據分離，這是一種非常強大的性能優化架構概念。
架構圖如下：
歷史事件流
除了維護運行時狀態之外，流程引擎還會創建一個審計日誌，提供有關已執行流程實例的審計信息。 我們將此事件流稱爲歷史事件流。 組成此事件流的各個子事件稱爲歷史事件，包含有關已執行流程實例，活動實例，已更改流程變量等的數據。 在默認配置中，流程引擎將簡單地將此事件流寫入Camunda歷史數據庫。camunda提供了 HistoryService API查詢此數據。
可配置的日誌級別
流程引擎通過歷史級別控制，進而對歷史事件流提供數據量進行精細控制。 許多設置都是開箱即用的，比如"full" 或者"none".當然這個級別我們也可以自定義。
大數據
用戶可以將歷史事件流重新路由到自己喜歡的任何目標，包括隊列以及您想要使用的大數據解決方案。 這是可能的，因爲Camunda Process Engine組件不會從歷史數據庫中讀取任何狀態。常用的目標有es等。