CQRS事件存储分发器错误处理

Question

4

我看了两种情况：A是可以的，B不确定。

场景A：提交后模拟应用程序重启，在分发之前

1. 启动EventStore 2. 提交更改 3. 事件未被分发 4. 停止Event store 5. 再次启动Event store 在步骤5中重新发送已提交的事件。这很好地工作了，我也在调度程序代码中看到了这一点。

场景B：模拟总线错误

1. 启动EventStore 2. 提交更改1 3. 调度程序出现异常 4. 提交更改2 5. 分发成功

在这种情况下，我找不到这种行为，并且我也想知道它是否是一个有效的案例：只有在总线代码中存在错误时才会发生这种情况。

是否有触发器来重试分发，或者我需要编写代码来处理这个问题，还是我的推理有误？

- SvR

我很好奇你使用的模式是从哪里得到的。我没有听说过这些概念与CQRS有关。如果您能提供一些指引，我将不胜感激。谢谢！ - Erick T

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jonathan Oliver · Accepted Answer

您对方案A的评估是正确的。在失败情况下，例如应用程序或机器重新启动/进程终止时，当进程再次启动时，它将发现未分派的提交并将其推送到调度程序。

方案B有点棘手。问题在于EventStore不是总线，因此如何处理总线中的错误不是EventStore本身可以处理的问题。此外，由于有许多总线实现，我不想将EventStore与任何特定的实现耦合在一起。一些用户甚至可能不使用消息总线，而是决定使用RPC调用。

那么您真正需要考虑的问题是，应该如何处理总线故障-以及扩展到队列故障？EventStore具有一个接口IPublishCommits。当事件被提交后，它会被推送到调度程序。调度程序只负责在实现IPublishCommits的正确和成功处理事件之后将事件标记为已分派。

处理瞬态总线和队列故障的最佳方法是在您的IPublishCommits实现中实现断路器模式，重试直到事情再次开始工作。对于更大的问题，例如序列化故障，您可能需要记录某种关键故障，以立即通知管理员。再次提醒的是，在所有这些问题中，黏性问题在于EventStore无法了解您情况的所有细节。