CQRS 和ElasticSearch - 使用ElasticSearch构建读取模型
有人使用 ElasticSearch 在 CQRS 方法中构建读取模型吗？我有一些与此类解决方案相关的问题：
- 您在哪里存储您的域名 事件？在 JDBC 数据库中？在 弹性搜索？
- 您是否通过处理域事件的事件处理程序或使用 ElasticSearch River 功能来构建索引？
- 如何处理视图模型的完全重建 - 例如，当视图损坏时？您是否处理所有事件以重建视图？
Does anyone use ElasticSearch for building read model in CQRS approach? I have some questions related to such solution:
- Where do you store your domain
events? In JDBC database? In
ElasticSearch? - Do you build indexes by event handlers that processes domain events or using ElasticSearch River functionality?
- How do you handle complete rebuild of view model - for example in case when view is corrupted? Do you process all events to rebuid view?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
领域事件的权威存储库所在的位置是实现细节。例如，您可以在 S3 或 CouchDB 或任何其他数量的存储实现上存储序列化版本。如果您刚刚入门，最简单的是关系数据库。
通常，人们使用事件处理程序来了解每条消息背后的业务意图，然后可以将消息正确地非规范化为适合视图需求的读取模型结构。
如果视图模型曾经损坏或者视图模型处理程序中可能存在错误，则修复错误后需要遵循几个简单的步骤：
暂时将来自域的事件流排入队列 - 这些是当您的域运行时发布的典型消息。我们仍然想要这些消息，但不是现在。这可以通过关闭任何消息总线或不连接到您的队列基础设施（如果您使用队列基础设施）来完成。
从事件存储中读取所有事件。收到每个事件后（这可以通过简单的数据库查询来完成），通过适当的消息处理程序运行每条消息。确保跟踪所有已处理消息的最后 10,000 个（左右）标识符。
现在重新连接到您的队列并开始正常处理。如果已看到消息的标识符，则删除该消息。否则，正常处理。
跟踪标识符的原因是为了避免竞争条件，即您从事件存储中获取所有事件，但通过消息队列传递相同的消息。
另一种高度相关但涉及跟踪所有消息标识符的技术可以在这里找到：http://blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit.html
Where the authoritative repository for your domain event is located is an implementation detail. For example, you could store serialized versions on S3 or CouchDB or any other number of storage implementations. The easiest if you're just getting started is a relational database.
Typically people use event handlers that understand the business intent behind each message and can then properly denormalize the message into the read model structure appropriate for the needs of your views.
If the view model is ever corrupted or perhaps you have a bug in a view model handler, there are a few simple steps to follow after fixing the bug:
Temporarily enqueue the flow of events arriving from the domain--these are the typical messages that are being published as your domain is doing work. We still want these messages, but not just yet. This could be done by turning off any message bus or not connecting to your queuing infrastructure if you use one.
Read all events from event storage. As each event is received (this can be done through a simple DB query), run each message through the appropriate message handler. Make sure that you keep track of the last 10,000 (or so) identifiers for all messages processed.
Now reconnect to your queues and start processing normally. If the identifier for the message has been seen, drop the message. Otherwise, process it normally.
The reason for tracking identifiers is to avoid a race condition where you're getting all events from the event store but the same message is coming across through the message queue.
Another technique that's highly related, but involves keeping track of all message identifiers can be found here: http://blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit.html