尽管我已经深入了解了NEventStore上的事务完整性，但我无法理解当NEventStore的许多实例连线时NEventStore如何真正扩展。
总结一下我的理解，一个事件被添加到未提供的提交，然后它发布给调度员，然后标记为已调度。
同时，无论何时连接NEventStore，它都会查找未分配的事件，然后调度它们并将事件标记为已分派。
但是，当新事件存储的连接将看到即将被分派的未分配事件（来自其他商店）时，必须有一个短时间跨度。新的事件存储将再次发送事件。
想想这个架构：
Client -> Command Bus -> Command Handler -> EventStore persist -> Dispatch to Event Handlers
如果我们有很多Command Handlers来处理我们的负载，我们也会坚持许多事件。
如果我们经常处置或创建Command Handlers，那么许多EventStore将被连线并导致调度已经发送的事件。
我知道调度员的消费者应该是幂等的，这不是我的问题。我的问题是我们是否会在高负载情况下为命令处理程序的消费者提供不必要的负载量？
答案 0 :(得分：2)
这个问题真的很老了，但是当我偶然发现它时，我会加上我的两分钱：我不认为你应该为每一个新的NEventStore实例连接起来命令处理程序的实例。 NEventStore对象是无状态的，因此您可以在整个过程中使用单个实例（或AppDomain）。
所以，当然，如果你有多个进程，每个进程都会连接一个新的NEventStore，你的场景可能会成为现实。但是，效果可能非常小，并且不会过多地妨碍可扩展性。
答案 1 :(得分：0)
在我看来，可以接受的是，在这种情况下，会多次发送消息。实际上基于this doc：
在故障情况下有一小部分可能性很小 可以发送事件但尚未标记为事件。这可能会导致 在重新分配的同一组消息中。以消息为导向 系统，至少一次交付的概念总是如此 应该考虑，这种情况也不例外。信息 消费者应该是幂等的（可能通过跟踪列表 以前的消息）以避免重复的传入消息。
所以，是的，消费者最终可以多次收到相同的消息。
但正如Fabian Schmied所说，我认为你应该为每个应用程序实例创建（连接）neventstore一次，而不是每个命令处理程序。