是否有人使用ElasticSearch構建CQRS方法中的讀取模型?我有一些與此類解決方案相關的問題:CQRS和ElasticSearch - 使用ElasticSearch構建讀取模型
- 你在哪裏存儲域名 事件?在JDBC數據庫中?在 ElasticSearch?
- 您是否通過處理域事件或使用ElasticSearch River功能的事件處理程序構建索引?
- 如何處理視圖模型的完整重建 - 例如視圖損壞的情況下?你是否處理所有事件以重建視圖?
是否有人使用ElasticSearch構建CQRS方法中的讀取模型?我有一些與此類解決方案相關的問題:CQRS和ElasticSearch - 使用ElasticSearch構建讀取模型
您的域名事件的權威存儲庫所在的位置是實施細節。例如,您可以將序列化版本存儲在S3或CouchDB上或任何其他數量的存儲實現中。如果你剛剛入門,最簡單的就是關係數據庫。
通常人們使用事件處理程序來理解每條消息背後的業務意圖,然後可以將消息正確地非規範化爲適合您的視圖需求的讀取模型結構。
如果視圖模型是不斷損壞,或者也許你在一個視圖模型處理程序中的錯誤,有幾個簡單的步驟修復該錯誤後,遵循:
暫時排隊的事件流到達來自域 - 這些是在您的域正在開展工作時發佈的典型消息。我們仍然需要這些消息,但還不夠。這可以通過關閉任何消息總線來完成,或者如果使用的話,可以不連接到排隊基礎設施。
閱讀事件存儲的所有事件。當每個事件都被接收到時(這可以通過簡單的數據庫查詢來完成),通過適當的消息處理程序運行每條消息。確保您跟蹤處理的所有消息的最後10,000個(或更多)標識符。
現在重新連接到您的隊列並正常開始處理。如果消息的標識符已被查看,請刪除該消息。否則,請正常處理。
跟蹤標識符的原因是爲了避免競爭情況,即從事件存儲中獲取所有事件但消息隊列中會傳入相同的消息。
另一種高度相關的技術,但涉及跟蹤所有消息標識符可以在這裏找到:http://blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit.html