2

NEventStore：5.1
简单设置：WebApp (Asp.NET 4.5) == 命令端

我正在寻找不丢失命令的“正确”方法，着眼于 sagas/process-managers，它们可能会无休止地等待从实际上从未处理过的命令产生的事件。

旧：调度员

我最初使用同步命令，但着眼于sagas/process-managers，我认为首先存储它们然后通过 SyncDispatcher (或 AsyncDispatcher) 获取它们会更安全。否则，我担心的是，如果 saga 尝试发送命令并且由于app-crash/powerloss/...导致命令未完成，它将丢失并且没人会知道。

所以我创建了一个命令流并将每个命令附加到它上面。如果该IsDispatched命令已被处理，则显示。
那行得通。

PollingClient 和 Command-Stream

现在调度程序已经过时，我切换到PollingClient. 我丢失的是Dispatched信息。

出现了一个启动问题：
我天真地从当前最新的检查点开始轮询，但是当应用程序重新启动时，有可能在崩溃之前存储了命令但没有执行，因此丢失了（这实际上发生了）。

我刚刚想到了这个想法：
将命令的基本结果作为（非域）事件存储在另一个流中。
此流将包含CommandSucceeded和CommandFailed事件。
每当应用程序启动最新的 command-id 或 command-checkpoint-number 时，就会提取用于在该命令之后立即加载命令...

问题

  • 我担心的是，同步命令处理会导致丢失传奇生成的命令的危险，错了吗？如果是，为什么？
  • 这通常是一个好主意：一个大的命令流吗？
  • 这通常是一个好主意：将通用命令结果事件存储在流中吗？
4

2 回答 2

4

你可以：

  1. 将您的命令存储在命令队列中 | 持久性日志
  2. 使用命令 id (guid) 作为 NEventStore 上的 Commit Id
  3. 将您的命令标记为在您的命令处理程序中执行 | 管道挂钩 | 轮询客户端

NEventStore 在相同的 AggregateId (streamid) + CommitId 上为您提供幂等性，因此如果您的应用在命令被标记为已处理之前崩溃并且您重播命令，NES 会自动丢弃生成的提交。

于 2015-02-16T15:12:16.833 回答
0

Afaik NEventStore 旨在成为事件源的存储，即将域对象存储为事件流。命令和传奇与它无关。您的服务总线应该负责持久性和传奇管理。

就个人而言，我将事件存储简单地视为存储库详细信息。应用程序服务（命令处理程序）将在生成的事件被持久化后调度它们。

如果应用程序崩溃并且服务总线是持久的（不是内存总线），那么事件/命令将再次自动处理，因为服务总线应该检测消息是否未成功处理。当然，出于这个原因，您的消息处理程序应该是幂等的。

于 2015-02-11T16:25:09.453 回答