【问题标题】:CQRS & ElasticSearch - using ElasticSearch to build read modelCQRS & ElasticSearch - 使用 ElasticSearch 构建读取模型
【发布时间】:2011-03-20 13:24:28
【问题描述】:

有人使用 ElasticSearch 在 CQRS 方法中构建读取模型吗?我有一些与此类解决方案相关的问题:

  1. 您将域存储在哪里 事件?在 JDBC 数据库中?在 弹性搜索?
  2. 您是通过处理域事件的事件处理程序还是使用 ElasticSearch River 功能来构建索引?
  3. 如何处理视图模型的完全重建 - 例如,当视图损坏时?您是否处理所有事件以重建视图?

【问题讨论】:

    标签: cqrs elasticsearch


    【解决方案1】:

    您的领域事件的权威存储库所在的位置是一个实现细节。例如,您可以在 S3 或 CouchDB 或任何其他数量的存储实现上存储序列化版本。如果您刚刚开始,最简单的方法是关系数据库。

    通常人们使用了解每条消息背后的业务意图的事件处理程序,然后可以将消息正确地反规范化为适合您的视图需求的读取模型结构。

    如果视图模型曾经损坏或者您的视图模型处理程序中存在错误,则在修复错误后可以执行几个简单的步骤:

    1. 暂时将来自域的事件流排入队列 - 这些是在您的域工作时发布的典型消息。我们仍然想要这些信息,但还不是现在。这可以通过关闭任何消息总线或不连接到您的队列基础设施(如果您使用一个)来完成。

    2. 从事件存储中读取所有事件。接收到每个事件后(这可以通过简单的 DB 查询来完成),通过适当的消息处理程序运行每个消息。确保跟踪所有已处理消息的最后 10,000 个(左右)标识符。

    3. 现在重新连接到您的队列并开始正常处理。如果已看到消息的标识符,则丢弃该消息。否则,正常处理。

    跟踪标识符的原因是为了避免竞争条件,即您从事件存储中获取所有事件,但同一条消息正在通过消息队列。

    另一种高度相关但涉及跟踪所有消息标识符的技术可以在这里找到:http://blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit.html

    【讨论】:

      猜你喜欢
      • 2018-05-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-11-16
      • 1970-01-01
      • 1970-01-01
      • 2012-09-15
      • 2017-12-10
      相关资源
      最近更新 更多