CQRS +微服務處理事件的回滾

我們正在使用使用的NodeJS微服務，CQRS，事件存儲CQRS域，一切就像一個魅力和典型的流程是這樣：CQRS +微服務處理事件的回滾

REST-> 2。服務 - > 3。命令驗證 - > 4。命令 - > 5。聚集物> 6。事件 - > 7。事件庫（事務數據） - > 8。返回聚合ID-> 9.存儲在微服務本地數據庫（本質上是讀數據庫） - > 10.發佈事件到隊列

上面的流程的問題是，由於事務數據保存，即持久性到事件存儲和存儲到微服務的讀取數據發生在不同的事務上下文中，如果在步驟9有任何失敗，我應該如何處理已經傳播到事件存儲的事件和已經更新的聚合？

任何建議將不勝感激。

來源

2017-09-13 vaibhav

究竟是什麼「9.存儲在微服務本地數據庫（本質上是讀數據庫）」？ –

它是讀取數據庫的讀取數據庫，像GET，GETALL等發生的那樣。 – vaibhav

它看起來像是將數據庫中的聚合狀態保存在數據庫中？什麼是第8步？ –

內您的活動的商店，你可以跟蹤是否讀端複製成功。只要步驟9結束，您可以將事件標記爲「已複製」。

這樣的話，你可能會引入留意無重複事件，並觸發第9步您也可以跟蹤複製是否失敗多次的組件。

更新讀出側（步驟9），並作爲複製應該一致地發生flagigng的事件。你可以在這裏使用傳奇模式。

來源

2017-09-13 11:11:48 mbnx

事件存儲是僅附加的，並且事件不應該知道它們的使用位置。我會說它是readmodel應該知道有多少事件已經應用到它，並且事件庫應該能夠分辨出流中的任何特定事件具有哪個「序列號」。因此，如果您的readmodel應用了120個事件並接收到事件＃122，它應該向事件庫 –

請求丟失事件。謝謝，這確實是更清晰的方法。 – mbnx

我正在使用的活動商店對已發送和未發放的活動進行了明確區分，這些活動完全遺漏了，我相信這就是問題的答案所在。我信任的佐賀模式更多的是關於不同集合的服務如何處理它們之間的業務依賴關係，而不是我信任的東西是在這種情況下使用的模式。。 – vaibhav

上述流程的問題是，由於事務數據保存即事件存儲和存儲到微服務的讀數據的持久性發生在不同的事務上下文中，如果在步驟9有任何失敗，應該如何處理已經傳播到事件存儲的事件和已更新的聚合？

您稍後重試。

的「記錄書」是事件商店。下游視圖（「發佈的事件」，閱讀模型）來自記錄簿。它們通常落後於時間記錄簿（eventual consistency），並且通常不會彼此同步。

所以，你可能有，在某個時間點，105個事件上寫本書的記錄，但只有100發佈到隊列，並在服務數據庫中表示只從98

更新一個構建視圖通常以兩種方式之一完成。當然，您可以從全新的表現開始，並在每次更新中重播所有事件。或者，您可以追蹤視圖的元數據中的事件歷史記錄，並使用該信息確定事件歷史記錄的下一次讀取開始的位置。

來源

2017-09-13 11:16:04 VoiceOfUnreason

這幾乎可以回答它，實際上我缺少的是派遣和未分派的事件。在這種情況下，無論它在讀取的數據塊上寫什麼，這裏的事件都會生成，但它們的區別在於它會在未發送的事件表中出現。 – vaibhav

我想我現在已經更好地理解它了。 Aggregate仍然會被創建，答案是任何類型的一致性的所有驗證都應該在我的聚合被構造之前發生，這是在代碼的權限範圍內發生故障的情況下，在更新讀取側數據庫時存在故障需要處理的微服務。因此，在理想情況下會創建聚合，但是相關的事件將保持未分配狀態，除非更新所有讀取依賴關係，否則將保持未分配狀態並且可以單獨處理。活動商店仍將保留所有活動，並保持最終一致性。

來源

2017-09-15 07:19:44 vaibhav

當您有多個讀取邊時，您如何處理這些（未分派的）事件？（具有自動故障轉移和負載平衡，基於服務器負載啓動和停止實例）。活動商店如何確定有多少活動消費者必須說「是」？ –

CQRS +微服務處理事件的回滾

回答

相關問題