事件採購：在更新模型之前或之後編寫事件

Question

我是關於事件採購的推理，並且經常遇到雞和雞蛋問題。對於如何解釋這個問題的一些提示會感激不盡。

如果我執行所有I/O綁定處理異步（即寫入事件日誌），那麼如何處理或者有時甚至檢測到失敗？

我正在使用Akka Actor，因此處理對於每個事件/消息都是連續的。我目前沒有任何數據庫，而是將所有事件保存在事件日誌中，然後保存存儲在內存中的模型中的所有事件的聚合狀態。查詢都是針對這個模型的，你可以認爲它是一個緩存。

例

創建一個新用戶：

1. 驗證的用戶沒有在模型
2. 堅持事件存在雜誌
3. 更新模型（在內存中）

如果第3步休息，我仍然堅持我的事件，以便我可以在以後重播。如果第2步休息，我可以很好地處理。

這是好的，但由於第2步是I/O密集型我想，我應該做的I/O在一個單獨的演員騰出查詢第一男主角：

更新用戶在允許查詢（A0 =前端/ GUI角色，A1 =處理器角色，A2 = IO角色，E =事件總線）。

1. （A0-> E-> A1）發佈事件以更新用戶'U1'。驗證用戶 'U1' 存在於模型
2. （A1-> A2）堅持事件日誌（單獨的演員）
3. （A0-> E-> A1-> A0）的查詢爲用戶 'U1' 輪廓
4. （A2-> A1）事件現在持續不斷地更新模型
5. （A0-> E-> A1-> A0）的查詢爲用戶 'U1' 剖面（現在返回新鮮數據）

這是有吸引力的，因爲查詢可以在I/O按照自己的步調攪動時進行處理。

但是現在我可以導致自己出現各種各樣的問題，我可以在事件日誌中保留兩條不兼容的命令（刪除然後更新），並在以後重播時自動崩潰，因爲我進行了驗證然後再堅持事件並更新模型。

我的目標是圍繞我的模型做一個簡單的推理（因爲Actor按順序處理單個線程的消息），但在查詢時不會等待I/O綁定的更新。我感覺我正在模擬一個數據庫，這本身可能是一個問題。

如果事情不清楚請寫評論。

Answer 1

異步I/O可以與事務更新共存。如果您在命令後發送「ACK」或「NACK」，則可以瞭解它是否發生。在分佈式或真正異步的模型中，「NACK」很可能來自明確的失敗和超時。