使用EventStoreDB實現事件溯源的Java開源專案

• 騎手可以在指定價格的路線上下訂單。
• 司機可以接受並完成訂單。
• 訂單可以在完成前取消。

事件溯源
事件溯源將實體的狀態儲存為一系列不可變的狀態更改事件。

每當實體的狀態發生變化時，都會將新事件附加到事件列表中。

可以透過重放其所有事件來恢復實體的當前狀態。
事件溯源最適合事件總數相對較少的短期實體（如訂單）。
透過重放其所有事件來恢復短期實體的狀態不會對效能產生任何影響。因此，短期實體不需要恢復狀態的最佳化。
對於具有數千個事件的無休止儲存的實體（如使用者或銀行賬戶），透過重播所有事件來恢復狀態並不是最佳的，應該考慮快照。
快照是一種最佳化技術，其中還儲存了聚合狀態的快照，因此應用程式可以從快照中恢復聚合的當前狀態，而不是從頭開始。

事件溯源中的實體也被稱為聚合。
同一聚合的一系列事件也被稱為流。

Event Store的要求

• 永久儲存。永久儲存事件。
• 樂觀併發控制。防止丟失更新異常（寫-寫衝突）。
• 載入當前狀態。從事件儲存中載入特定聚合 ID 的所有先前事件。
• 按聚合型別訂閱所有事件。而不是訂閱代表聚合的單個事件流。
• 檢查站。處理後儲存事件偏移量（流中的位置）。在應用程式重新啟動後，從最後一個已知位置訂閱，而不是從流開始。

解決方案架構
EventStoreDB原生支援追加事件、併發控制、讀取事件、事件的持久化訂閱。

該解決方案的重要部分是EventStoreDB的永續性訂閱。

永續性訂閱的目的是向連線的訂閱者實時提供事件，並由伺服器維護。永續性訂閱保留了訂閱者在伺服器上開始獲取事件的最後已知位置。

永續性訂閱可以是負載平衡的，並且可以並行處理事件。為了使伺服器能夠平衡訂閱者的負載，它使用了消費者組的概念。

有一個Pinned消費者策略，旨在與索引投影（如系統$by_category投影）一起使用。

事件流id被雜湊到分配給單個客戶的1024個桶中的一個。當一個客戶端斷開連線時，它的桶被分配給其他客戶端。當一個客戶端連線時，它被分配到一些現有的桶中。這樣做的目的是為了保持工作負載的平衡。

Pinned消費者策略的主要目的是減少併發和排序問題的可能性，同時保持負載平衡。這並不是一種保證，你應該處理通常的排序和併發問題。