我在看 2 个场景：A 没问题，B 不确定。
场景 A：在提交后、分派前模拟应用程序重启
在第 5 步中再次发送提交的事件。这工作正常，我在调度程序代码中也看到了这一点。
场景 B：模拟总线错误
在这种情况下，我找不到该行为，并且想知道它是否是一个有效的案例：只有在总线代码中存在错误时才会发生这种情况。
是否存在将重试调度的触发器，或者我是否需要编写代码来处理这个问题，或者我的推理有问题？
您对场景 A 的评估是正确的，在应用程序或机器重新启动/进程终止等故障情况下，当进程再次启动时，它将发现未调度的提交并将它们推送到调度程序。
场景 B 有点棘手。问题在于 EventStore 不是总线，因此如何处理总线中的错误的问题不是 EventStore 本身无法处理的问题。此外，由于有许多总线实现，我不想将 EventStore 耦合到任何特定实现。有些用户甚至可能不使用消息总线；他们可能决定改用 RPC 调用。
那么你真正遇到的问题是，应该如何处理总线故障——以及扩展的队列故障——应该如何处理？EventStore 有一个接口 IPublishCommits。当一个事件被提交时，它会被推送到一个调度程序。一旦 IPublishCommits 的实现正确且成功地处理了一个事件，调度程序只负责将其标记为已调度。
处理瞬时总线和队列故障的最佳方法是在您的 IPublishCommits 实现中实现断路器模式，该模式会重试直到事情再次开始工作。对于更大的问题，例如序列化失败，您可能希望记录某种会立即通知管理员的严重故障。同样，所有这一切的棘手问题是 EventStore 无法了解您的情况的所有细节。