尽管我已经深入阅读了NEventStore上的事务完整性，但当连接了许多NEventStore实例时，我无法理解NEventStore将如何真正扩展。
为了总结我的理解，一个事件被添加到提交中作为未调度，然后它发布到调度器，然后标记为已调度。
同时，无论何时连接NEventStore，它都会查找未修补的事件，然后分派它们并将事件标记为已分派。
但是，当一个新事件存储的连接将看到即将（从其他存储）调度的未修补事件时，必须有一个短的时间跨度。新的事件存储将再次调度事件。
想想这个架构：
Client -> Command Bus -> Command Handler -> EventStore persist -> Dispatch to Event Handlers
如果我们有许多Command Handlers来处理我们的负载，那么我们也将持久化许多事件。
如果我们经常处理或创建Command Handlers，那么许多EventStore将被连接起来，并导致调度已经被调度的事件。
我理解调度器的消费者应该是幂等的，这不是我的问题。我的问题是，在高负载情况下，我们是否会在使用者（命令处理程序）上提供不必要的负载量？
这个问题确实很老，但由于我刚刚偶然发现了它，我将加上我的两分钱：我不认为你应该为命令处理程序的每个实例连接一个新的NEventStore实例。NEventStore对象是无状态的，因此您可以在整个过程中使用单个实例（或AppDomain）。
所以，当然，如果你有多个流程，每个流程都会连接一个新的NEventStore，你的场景可能会成为现实。然而，影响可能很小，不会对可扩展性造成太大阻碍。
在我看来，在这种情况下，多次发送消息是可以接受的。事实上，基于此文档：
在故障场景中事件可以被调度，但还没有被标记为这样。这可能导致在被重新修补的同一组消息中。以消息为导向系统，至少一次交付的概念总是应该考虑，这种情况也不例外。消息消费者应该是幂等的（可能是通过跟踪以前的消息），以避免重复的传入消息。
因此，是的，消费者最终可以多次收到相同的信息。
但正如Fabian Schmied所说，我认为您应该为每个应用程序实例只创建（连接）neventstore一次，而不是为每个命令处理程序创建。