首页 文章

EventStore:学习如何使用

提问于
浏览 868
2

我正在尝试学习EventStore,我喜欢这个概念但是当我尝试在实践中应用时,我会陷入同样的困境 . 我们来看看代码:

foreach (var k in stream.CommittedEvents)
{ 
   //handling events
}

两个问题:

  • 当应用程序在某些维护后启动时,我们如何以安全的方式书签哪些事件开始读取?有使用的模式吗?

  • 一旦事件全部被消耗,循环结束......消息到达运行时间怎么样?我希望呼叫阻塞,直到一些新消息到达(当然需要在一个线程中处理)或具有类似BeginRead EndRead的东西 .

我是否必须绑定ESB来处理运行时事件,或者EventSore是否提供了一些工具来执行此操作?

I try to better explain with an example 假设汇总是一个金融投资组合,该应用程序是一个向交易者显示该投资组合的应用程序 . 假设交易者连接到Web应用程序,他会查看自己的投资组合 . 当前状态将是整个历史记录,因此我必须阅读大量记录才能重现状态 . 我想这可以通过一个所谓的快照完成,但是谁完全错误,将相同的事件流作为新事件的来源 new long position ,否则我有两条路径处理同一聚合的状态 . 我想知道这是策略应该如何工作,即使我觉得有两个州代理有点棘手,可能会重叠 . 只是为了澄清我如何担心重叠:

  • 我知道事件必须是幂等的,所以我知道它一定不是问题,

  • 但是让我们考虑以下几点:

我订阅事件总线 before 流媒体事件以更新投资组合的状态 . 一些"open position event"出现在总线上:我必须处理它们,但也许组合处于正确的状态来处理它,因为尚未实现 . 即使我能够处理这些事件,我也会在阅读流时再次找到它们 .

更阴险:我打开流,我读了所有事件,我创建了一个状态 . 然后我订阅了总线:总线上的一些消息发生在steram读取结束和订阅开始之间的中间:这些事件丢失且聚合未处于正确状态 .

请耐心等待,我的英语很差,争论很棘手,希望我设法分享我的疑问:)

1 回答

  • 10

    目前的状态将是整个历史,所以我必须阅读很多记录来重现状态 . 我想这可以通过一个所谓的快照完成,但谁负责创建它?

    在CQRS和事件源中,查询由projections提供,这些查询是由聚合发出的事件生成的 . 您不使用从事件存储重构的聚合实例来显示信息 .

    术语快照特指事件存储的优化,它允许重建聚合而不重放所有事件 .

    预测本质上是事件处理程序,它维护聚合的非规范化视图 . 从聚合中发出的事件可能在带外发布,并且投影订阅并处理这些事件 . 例如,如果存在显示摘要信息的要求,则投影可以组合多个聚合 . 在交易应用程序的情况下,每个视图通常包含来自各种聚合的数据 . 预测是以消费者驱动的方式设计的 - 应用程序需求决定了所需底层数据的不同视图 .

    使用此类工作流程,您必须在整个应用程序中拥抱最终的一致性 . 例如,如果最终用户正在查看他们的投资组合并启动新交易,则UI必须订阅更新以反映更新的投影以异步方式 .

    请查看here,了解CQRS和事件采购的概述 .

相关问题