當使用聚合事件採購作爲交易範圍時，您顯然希望在單臺計算機上擁有該聚合。但是，如果您還想構建高度可用且水平可伸縮的系統，則還需要在不同數據庫上的許多計算機上覆制此狀態。事件採購多方面寫？
如果在任何給定時刻只允許在該網絡中的一臺機器上有一個寫入側，其他機器最終可以是一致的讀取側。但爲了最大限度地提高寫入性能，我想最好是同時允許多個寫入端。但是，像這樣的系統如何處理一致性和共識？
當兩臺或多臺機器想要同時更新通用但已複製的狀態時，如何確保命令由所有寫入端以相同順序處理，以便生成的事件完全相同，並且還具有同樣的順序？ Lamport時鐘是解決方案的一部分嗎？
但是爲了最大限度地提高寫入性能，我想最好允許 多個寫入同時進行。但是如何在這樣的系統中處理一致性和共識？
在事件源系統中，寫入側的一致性總是很強。這通過使用樂觀鎖定由聚合和Event store強制執行：在併發寫入的情況下（實際上事件僅附加到商店），則重試孔命令。這是可能的，因爲聚合命令方法是純粹的（無副作用）方法。只要事件沒有持續下去，命令就可以重試。
當兩臺或多臺計算機在同一時間更新狀態（ 一個選擇和堅持它？）
兩個。第一個（總是有第一個）命令生成持久存儲到該商店的事件。 secons命令由於低級別的conception異常而失敗。然後通過加載+應用所有以前的事件重試，包括由第一個命令生成的事件。然後，第二個命令會生成也會持續存在的事件事件，如果新狀態不允許處理第二個命令，則會引發異常。
您必須注意，第二個命令至少執行兩次，但每次前面的事件（因此狀態）都不相同。
基礎架構將聚合版本附加到每個聚合流。每個事件附加增加此版本。聚合ID和版本有一個唯一的約束。這可能是所有活動商店的實施方式。
當一臺機器行爲不端（不知不覺，或故意），並傳播 故障事件給網絡的其餘部分（如何檢測呢？）
我不明白這是怎麼發生，但如果它正在發生，那麼它真的取決於你對故障事件的理解。您可以讓一些Sagas/Process經理分析事件並觸發一些發送給某種監督員的電子郵件。
我在Shuttle上處理的方式。回憶（無恥插件）ES的實現是在聚合ID 和上構建事件存儲中版本的唯一聚集索引。通過這種方式，在同一個AR上的多次寫入不會重疊，並且兩個中的一個將「失去」。當然，這隻能使用中央數據存儲，但也許你的實現有一個類似的機制可用。
有多少客戶端可以同時寫入事件存儲沒有限制。然而，投影處理具有在單個機器上的每個命名投影爲單個線程，因爲事件排序非常敏感。那麼，我猜可以在不同的機器上處理不同的預測。
感謝您的回答。我看到如何使用樂觀鎖定，當有一個單一的寫入端。但是如果在不同的機器上有多個寫方（沒有一個公共數據庫），他們會以某種方式必須同意要處理的命令。樂觀鎖定可以在一臺機器上併發寫入，但是如何處理擴展系統中的併發寫入？ –
@AndreasZita沒有一個共同的數據庫，我不認爲這是可能的。但是，使用通用數據庫，您可以使用「Aggregate ID」進行分片。通過這種方式，您可以最小化共同寫入的概率。 –