前段時間著手分散式事務,初布研究方向是基於訊息匯流排事件資料一致性方案,訊息匯流排考慮到之前應用的rabbitMQ,但想到分散式事務鎖機制zookeeper有很好的實現,同時Kafka也是基於zookeeper實現的訊息佇列機制,最近正好看到這相關博文,特此引薦,以觀後效.

Eventuate是建立高擴充套件的事件溯源event sourcing和使用因果一致性建立事件協助的開源服務框架。基於事件驅動和事件溯源的服務能夠給予因果順序的事件流通訊，服務可位於單個伺服器本地也可以分佈到全球規模，使用因果一致性複製，保持網路分割槽之間的寫操作高可用性。

Eventuate有Java和Scala兩個API，基於Akka編寫。

具體特性如下：
1.提供建立有態事件溯源服務、持久化和記憶體查詢資料庫和事件處理管道。
2.啟用服務通過一個可靠分割槽冗餘事件匯流排通訊，該匯流排基於因果事件順序，可分佈到大型分散式系統。
3.支援使用因果一致性進行有態服務複製，使用自動和互動的衝突解決方案實現當前狀態更新。
4.提供基於操作的CRDTs(Conflict-free replicated data types )實現。
5.允許服務跨多個區域分佈開發執行
6.支援用於更新查詢資料庫的分散式服務的事件聚合
7.提供適配第三方流處理框架用於事件流分析。

基於操作的CRDTs

CRDTs是免衝突複製資料型別Conflict-free replicated data types 的簡稱。是一種可複製的資料型別，在發生更新時，所有資料型別最終會收斂到相同狀態。一個CRDT在更新時無需進行復制協調，因此節約了協調成本，提高效率。這使得CRDT對於寫操作高可用，CRDT能夠被分類成基於狀態的CRDTs和基於操作的CRDTs，簡稱CvRDTs和CmRDTs。基於狀態的CRDTs是於傳播狀態的複製，而基於操作的CRDTs則是傳播操作。

如果操作是通過一個可靠的因果（RCB）中介軟體廣播傳播就會保證Cmrdt複製最終一致收斂，他們設計用於並行操作交換。

CvRDTs不需要對底層訊息中介軟體有特別要求，但是狀態傳播需要增加頻寬或降低狀態大小。

CmRDT操作分為兩個階段：prepare和effect，prepare在本地節點上執行。它著眼於操作和（可選）當前狀態，併產生一個代表操作的訊息，然後分發給所有的其他節點。effect適用於所有節點上的傳播操作。

與事件溯源有關

CmRDT兩個更新階段：prepare和effect和事件溯源實體的更新階段（命令處理和事件處理）有關：

1.在命令處理中，傳入命令（可選）對實體的當前狀態進行了驗證，如果驗證成功，則表示代表該命令效果的事件可被寫入事件日誌中。這相當於在cmrdt的prepare階段產生的操作。

2.在事件處理中，寫入事件日誌中的寫入事件被拿出使用，用於更新實體的當前狀態。這相當於將產生cmrdt的effect效果。

Eventuate提供 EventsourcedActor實現定製命令和事件處理。

可靠的因果廣播
大多數CmRDT需要更新操作的因果傳輸順序，因果傳輸可通過事件日誌提供的前後順序輕鬆完成，但是，如果事件日誌本身被複制（例如在Kafka叢集中的一個分割槽topic），或它一點也不復制的，這樣的事件日誌的可用性是有限的，因為它必須協調所有複製備份的更新。

因此，讓cmrdts共享一個完全有序的事件日誌會受限制於底層的事件日誌的可用性，這不是我們想要的。

我們需要的是將cmrdt複製跨分佈地理位置（或可用性區域）分佈，每個本地都有其自己的本地事件日誌，仍然保持可以寫入，即使與其他地方分割槽分開來。在一個本地寫入的事件通過非同步和可靠地複製到其他位置。能夠在這樣一個網路複製本地事件日誌以達到最強的全域性秩序才滿足的cmrdts規定的因果關係。

在Eventuate 中本地事件日誌稱為可複製的event log，可複製的event lg中因果跟蹤通過向量時鐘實現，向量時鐘是作為潛在的因果關係代表，是一種部分順序。

CRDT服務框架

之前介紹瞭如何將CmRDT繼承到Eventuate的事件溯源和事件協調底層設施，為了解放CmRDT開發者，Eventuate提供CmRDT服務開發框架隱藏了這些底層細節。

詳細原理見：https://krasserm.github.io/2016/10/19/operation-based-crdt-framework/

Eventuate專案：
GitHub - RBMHTechnology/eventuate: Global-scale ev