5

尽管我已经深入了解了 NEventStore 上的事务完整性，但我无法理解在连接了许多 NEventStore 实例时 NEventStore 将如何真正扩展。

总结一下我的理解，一个事件被添加到提交中作为未调度，然后它发布到调度程序，然后标记为已调度。

同时，每当您连接 NEventStore 时，它​​都会查找未分派的事件，然后分派它们并将事件标记为已分派。

但是必须有很短的时间跨度，新事件存储的连接将看到即将（从其他存储）分派的未分派事件。新的事件存储将再次分派事件。

想想这个架构：

Client -> Command Bus -> Command Handler -> EventStore persist -> Dispatch to Event Handlers

如果我们有很多Command Handlers来处理我们的负载，我们也将持久化许多事件。

如果我们经常处理或创建Command Handlers，那么许多 EventStore 将被连接起来，并导致调度已经被调度的事件。

我知道调度程序的消费者应该是幂等的，这不是我的问题。我的问题是，在高负载情况下，我们是否会在命令处理程序的消费者上提供不必要的负载？

4

2 回答 2

3

这个问题真的很老，但是当我偶然发现它时，我会加两分钱：我认为您不应该为命令处理程序的每个实例连接一个新的 NEventStore 实例。AppDomainNEventStore 对象是无状态的，因此您可以为整个过程（或）使用单个实例。

所以，当然，如果你有多个进程，每个进程都会连接一个新的 NEventStore，你的场景可能会成为现实。但是，影响可能非常小，并且不会过多地妨碍可扩展性。

于 2016-03-28T17:24:29.070 回答
0

在我看来，在这种情况下消息被多次发送是可以接受的。事实上基于这个文档：

在失败场景中，可能会分派一组事件但尚未标记为此类事件的可能性很小。这可能会导致重新分派同一组消息。在面向消息的系统中，至少一次传递的概念总是应该考虑的，这种情况也不例外。消息消费者应该是幂等的（可能通过跟踪先前消息的列表）以避免重复的传入消息。

所以是的，消费者最终可以多次收到相同的消息。

但正如 Fabian Schmied 所说，我认为您应该只为每个应用程序实例创建（连接）一次 neventstore，而不是为每个命令处理程序。

于 2016-05-13T16:08:17.353 回答