我正在尝试学习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 回答
在CQRS和事件源中，查询由projections提供，这些查询是由聚合发出的事件生成的 . 您不使用从事件存储重构的聚合实例来显示信息 .
术语快照特指事件存储的优化，它允许重建聚合而不重放所有事件 .
预测本质上是事件处理程序，它维护聚合的非规范化视图 . 从聚合中发出的事件可能在带外发布，并且投影订阅并处理这些事件 . 例如，如果存在显示摘要信息的要求，则投影可以组合多个聚合 . 在交易应用程序的情况下，每个视图通常包含来自各种聚合的数据 . 预测是以消费者驱动的方式设计的 - 应用程序需求决定了所需底层数据的不同视图 .
使用此类工作流程，您必须在整个应用程序中拥抱最终的一致性 . 例如，如果最终用户正在查看他们的投资组合并启动新交易，则UI必须订阅更新以反映更新的投影以异步方式 .
请查看here，了解CQRS和事件采购的概述 .